Reg : Unable to Redirect Unauthorized Users to error page.

[Anon Anon]

Hello,

 

    The requirement I have is to redirect the user to an error page when the user is unauthorized. Here the case is like.., the userX is authorized to access application1 but not application2. So when the userX is already logged into application1 and is trying to access application2...instead of the login.fcc page being displayed.. I want to redirect the userX to an error page..saying.., YOU are not AUTHORIZED to Access this application.

 

So what I did is : created a rule on Authorization Events    : Action [OnAccessReject]    ; Deny Access[Enabled].

 

And in the response part what I did is : selected the WebAgent-OnReject-Redirect    ;    Attribute Kind : Static    ;    Variable Value : AuthFailure/AuthFailure.htm

 

But, it is still not happening. Could you please tell me the steps in should follow?

 

P.S. : I am not using SPS|Federation.

[Legacy User]

Did you create a separate Policy for Reject and Allow?

 

The Reject Policy should have the OnAccessReject Rule, mapped to Reject Redirect Response - with "All" in Users.

 

 

Regards

 

Hubert

[Anon Anon]

Hi Hubert, What do you mean by separate policy here?

Is it like for a single webagent we need to have two different policies? One for accept conditions, and the other for reject conditions?

Could you kindly explain me, what do I need to do in order to redirect users on authorization as well as authentication failures?

[Legacy User]

I was referring to a Policy Object within a Policy Domain (WebAgent is linked to Realms within the Policy Domain). See below an example where we have a single accept policy defined.

 

Create another policy called 'azreject_policy_policydomainName'. Add the AzReject Rule, map the AzRedirectResponse to AzReject Rule, within this Policy. In User's tab opt for 'ALL'. Repeat the same step for AuthReject Rule.

 

 

 

 

Regards

 

Hubert

[Anon Anon]

Hi Hubert, I also tried doing the same. But after rolling out the policy as suggested by you, the applications were also enabling access to unauthorized users, Since, under the users tab I selected [Add ALL].

 

What I have done till now is as follows :

Two applications on two different servers, one one IIS, the other one on OHS.

1) Initially I had two policies:

     i) In the policy for IIS - one realm containing the rule on web action[GET, POST] , I didn't have any rule set for redirect on Accept under Authentication or Authorization actions.

     ii) Similarly for OHS, one realm containing the rule on web action[GET, POST], I didn't have any rule set for the redirection on Accept condition for Authorization/Authentication..just as above.

 

Now as you suggested to have a different policy set for rejection, I created the policy and in the policy I created two rules : web Actions..as I did before.. and  OnAuthReject...both for Authentication and Authorization... and also created a response.. The response page remains the same for both the actions.. But the result I got is highly disappointing..

 

I don't understand the reason that why you asked me create a different policy for the same domain.

 

Can't two different set of rules remain under the same policy?

Is it necessary to have active rules/responses set up for the OnRejectRedirect thing to happen, wouldn't response containing static attribute type could work?

Also, can a global response be mapped to any rule..from any domain..so that the response could just be used anywhere?

 

Please try to clarify my queries.

[Legacy User]

Ahh in the reject policy we never add "ACCEPT/ALLOW/GET-POST-PUT rules". Read below, hopefully this should assist in understanding how rules should be grouped.

 

The reason we created different policies is to segregate accept/allow policy from reject/disallow policies. Am detailing how your configurations should look like. The thumb rule being all ACCEPT/ALLOW/GET-POST-PUT rules should be in one policy and REJECT/DENY/DISALLOW rules should be in a different policy.

 

Realms Under PolicyDomainA

 

Realm1 : /iisresource

• Realm1-Rule1 : /*     WebAgent Actions : GET, POST, PUT.
• Realm1-Rule2 : /*     Authentication Events : OnAuthReject.
• Realm1-Rule3 : /*     Authorization Events : OnAzReject.

Realm2 : /ohsresource

• Realm2-Rule1 : /*     WebAgent Actions : GET, POST, PUT.
• Realm2-Rule2 : /*     Authentication Events : OnAuthReject.
• Realm2-Rule3 : /*     Authorization Events : OnAzReject.

Response Under PolicyDomainA

Accept_Response

• AttributeList
  • WebAgent-HTTP-Header-Variable : mail=<% userattr="mail" %>
  • WebAgent-HTTP-Header-Variable : name=<% userattr="givenName" %>

Reject_Response

• AttributeList
  • WebAgent-OnReject-Redirect (static) : https://FQDN/unauthorized.html

Policies Created Under PolicyDomainA

Accept_Policy_IIS : Only Users from cn=GroupA or ou=GroupA are allowed to access IIS Resource

• Users : ou=GroupA,ou=eBusiness,dc=company,dc=com
• Realm1-Rule1 <<<< map to >>>> Accept_Response.
  

Accept_Policy_OHS : Only Users from cn=GroupB or ou=GroupB are allowed to access OHS Resource

• Users : ou=GroupB,ou=eAdmins,dc=company,dc=com
• Realm2-Rule1 <<<< map to >>>> Accept_Response.
  

Reject_Policy :

• Users : ALL
• Realm1-Rule2 <<<< map to >>>> Reject_Response.
• Realm1-Rule3 <<<< map to >>>> Reject_Response.
• Realm2-Rule2 <<<< map to >>>> Reject_Response.
• Realm2-Rule3 <<<< map to >>>> Reject_Response.

Question : Can't two different set of rules remain under the same policy?

• Yes. There can be multiple rules under the same policy. However the rules should be defined correctly.
• For example : We cannot add Realm1-Rule1 and Realm1-Rule2/Rule3 in the same policy. Think it this way what we are saying is if Realm1-Rule2/Rule3 triggers then redirect is allowed for only users belonging to GroupA. However we are rejecting because User is not part of GroupA, as (Accept_Policy_IIS) Policy is mapped to allow access to GroupA.
• Here's Another Example : I can create a DENY rule for 'OHSResource' under Realm2. Then Add this DENY rule under (Accept_Policy_IIS) Policy. This would mean if users in GroupA access IISResource, they would be ALLOWED access. However if users in GroupA accessed OHS Resource, then they'd be denied access.
  

Question : Also, can a global response be mapped to any rule..from any domain..so that the response could just be used anywhere?

• Yes.
• If the Response Object is defined within a Policy Domain, it is restricted for use within the Policy Domain. If the Response Object is created as a Global Response. Then we could use this Global Reponse to be used with any Policy Domain which has “Global Policies [Check Box – selected]” at Domain Level. Global Responses need not be necessarily tied to Global Rules & Global Policy. Global Response could also be tied to normal rules within a Policy Domain. Hence we could define one Global Response and use it repetitively under different Policy Domain. The catch here is try not use the same Global Response within a GlobalRule-GlobalPolicy and NormalRule-NormalPolicy. Just being overly cautious, it could be done, but some level of segregation at some layer always helps. Therefore to summarize Global Response can be mapped to a Global Rule within a Global Policy OR it could be mapped to a Normal Rule within a Normal Policy defined within a Policy Domain.
  

Hope I have answered all your queries.

Regards

Hubert

[Anon Anon]

Hi Hubert, Thanks a lot for the explanation.

[Vipul Kaneriya]

Hi Hubert,

 

We are using Global Policy for OnAuthReject with Global Rule and Global Response and it is working fine as expected for federation partnership (protecting redirect jsp) and reverse proxy application (protecting SPS Agent). When unauthorized user try to access federation site very first time they are forwarded to an error page mentioned in global response BUT when same user try to access same federation site second time in the same browser he successfully gets in.

 

This behavior is pretty strange and difficult to caught. This is only happening with protected federation partnership and not with protected reverse proxy application( CA access gateway).

[Anon Anon]

Hi Hubert, I have got another issue right now. I am trying to enable the reset password option for the users once they login into the application. So what I did is, the the application page I have created an hyper link to the smpwservices.fcc page, just as below :

 

http://myserver.xyz.com/siteminderagent/forms/smpwservices.fcc?SMAUTHREASON=34&TARGET=http://myserver.xyz.com/changepassword/passwdchange.htm

And also in the password policies, I have created a policy enabling it on the whole directory and mentioned the redirection url as /siteminder/forms/smpwservices.fcc

 

Now when I enabled the password policy it's redirecting me to the authentication page, which I configured earlier. And also when I disabled the password policy it was redirecting into the application page, as well the smpwservices page was redirecting to the target page. But, the password was not getting changed.

 

Could you pls. help?

[Anon Anon]

Here, by authentication page I mean the error page in case of authentication failure.

[Legacy User]

I believe this thread Unable to enable the self password change option. has been initiated to discuss this issue, let us discuss there. It is good to open different discussion thread for different issue, rather than discuss all issues in one thread.

 

Regards

 

Hubert