Symantec Access Management

Hi There,

Could you please clarify me below doubts.

1. Could you please let me know the order in which SiteMinder rules gets triggered. As you know there are many rules like GET/POST rule, OnAuthAccept, OnAccessAccept,OnAuthAttempt,OnAuthReject,OnAccessReject etc. Could you please let me know the order in which these rules gets triggered ?

2. Are there any interdependancy between these rules ? or are these rules triggered individually ?. i.e, If GET/POST rule failes then will it try to execute other rules in the policy (for ex, OnAccessAccept)?

Thank you in advance for your help.

Here is what I think....

To Answer your first query

GET/POST rule is a primary rule. You need this if you need to protect a resource.

The other rules trigger in various phases and conditions surrounding the primary rule. I would call the other rules "Enablers" which allow handling of certain conditions e.g.

• Postive / Negative Conditions.
• Pre and Post Conditions.

Phases :

• Authentication Phase.
• Authorization Phase.

Authentication Phase. In order of Postive / Negative Condition and Pre / Post sequencing.

• OnAuthAttempt : Incorrect Username, therefore User does not exist in UserStore.
• OnAuthReject.: Correct Username, therefore User exist in UserStore. However wrong Password.
• OnAuthAccept.: Username and Password match, do I need to do something before I move into Authorization Phase. E.g. Certain Headers are available on successful authentication event, they may not be available during any other event. Use this rule to trigger those headers.

Authorization Phase. In order of Postive / Negative Condition and Pre / Post sequencing.

• OnAccessAccept : Authorization is successful. User is present in Policy and allowed to Access. Do I need to do something as soon as Authorization event is successful E.g. Redirect to some place OR set a Header?
• OnAccessReject : Authorization is not successful. User is not present in Policy and  therefore not allowed to Access. Do I need to do something as soon as Authorization event is not successful E.g. Redirect to some place OR set a Header?

Hope these sequences help.

To Answer your second query

There is no interdependence between these rule. You could set these rule as needed OR not have them. However you still need one single rule i.e. GET/POST rule to protect and access successfully. Therefore GET/POST is the mandatory rule. All these rules are explicitly triggered / actioned individually, if they are configured one after the other, as request passes through each phases. If these "Enabler" rules are not defined the request still goes through these phases but it does a standard coded path without a checkpoint. The "Enabler" rules act like a checkpoint in code, where it would say "OK event1/rule1 triggered, so now what to do?".

Regards

Hubert

Hi Hubert,

Thank you very much for your time on this. I am primarily trying to find a solution for the below scenario. Could you please have a look at the below scenario and let you know your thoughts on it.

Scenario :

Assume that I have a user1 in Group 1, user 2 and in Group2 and user 3 in neither of the two groups (might be in any other group).

If the user1 logs in then I need to redirct the user 1 to URL1 (as the user in Group1).

If the user2 longs in then I need to redirect the user 2 to URL 2 (as the user in Group2).

And if the user3 logs then I need to redirect the user to URL 3 (ERROR page) as user 3 doesnt belong to Group1 & Group2.

Here is what I have tried so far :

I have created a rule for GET/POST web agent action rule and a response which redirects to URL1. Then I have created
a policy, added Group1 in the policy. Associated GET/POST rule to the response which redirects to URL1.

I have created one more rule for OnAccessAccept action and a response which redirects to URL2. Then I have created
a policy, added Group2 in the policy. Associated OnAccessAccept rule with the response which redirects to URL2.

I have created one more rule for OnAccessReject action and a response which redirects to URL 3 (ERROR PAGE).
Then I have created a policy, added the whole user base and EXCLUDED Group1 & Group2 in the policy. Associated
OnAccessReject rule with the response which redirects to URL3 (ERROR PAGE).

I have created other rules for OnAuthAccept, OnAuthReject and OnAuthAttept and apppriate responses and policies. I
have added the whole user base for these polcies. (no specific configuration for these three rules)

findings :

1. When user1 logs in to the system then it is redirecting to URL1 (success!!)

2. And It is not working for other scenarios. It is not working fine when user 2 logs in.

It would be a great help if you could shed some light on this. Please feel free to ask me any questions if I am not clear on explaining the scenario.

I am able to find a solution for this. thanks for your help.

Hi Hubert,

First of all, GET/POST s not a Rule, It's the Web-Agent Action.  Secondly OnAuthAttempt  --> Doesn't mean that User doesn't exists in the database. It doesn't really check the User Name is valid or not.

OnAuthAttempt checks only that Authentication Attempt has been made by this user. This Authentication Event will fire always if configured for the condition, If User is valid and Exist in the database.

OnAuthReject doesn't really mean that only password s incorrect,  It occurs if authentication failed for a user that is bound to a policy containing an On-Auth-Reject rule. This event may be used to redirect the user after a failed authentication.  If the user is not bound to Policy, this Event will not fire.

Thanks a lot.

~Sandeep Khurana

Thank You Sandeep

GET/POST s not a Rule, It's the Web-Agent Action.
[HUBERT] Correct words. However it is still called a WebAgent Actions Rule and in general / often used terminology refered to in layman terms as GET,POST,PUT rule. Thanks for putting the words correct.

Regarding the OnAuthAttempt and OnAuthReject, I was suggesting an example that how it could be used and is often used.

<SNIP>

The other rules trigger in various phases and conditions surrounding the primary rule. I would call the other rules "Enablers" which allow handling of certain conditions e.g.

• Postive / Negative Conditions.
• Pre and Post Conditions.

<SNIP>

No one controls how these rules would be configured. It is upto the end person configuring these based on desired accomplishments. However there is an % estimate we often see under what conditions these rules are used the most. I merely used the most highly configured ones as examples to help understand.

Thanks for adding on, different perspectives are welcomed.

Regards

Hubert