End Impersonation Error Scenario

[Jim Lundell]

I'm looking for insight as to how Impersonation should work for the following scenario.

 

1. Impersonator logs in as themselves
2. Impersonator impersonates impersonatee successfully
3. Impersonator accesses a resource at some point during the
   flow that does not permit impersonation
4. Impersonator eventually attempts to end Impersonation
   session but sees error via endImp.unauth

 

 

 

From my observation, the problem occurred at step 3.  The browser (or server side call) was
redirected to an FCC to login again as Impersonation was not allowed.  On a trace, I can see the SiteMinder agent expires the SMSAVEDSESSION.

 

Thus, when the end Impersonation FCC in step 4 is invoked, there is no SMSAVEDSESSION and the
impersonator remains logged in as the impersonatee. 

 

Is there a best practice on how to handle this flow to make the Impersonator's experience better?

 

Cheers, Jim

[Ujwol]

Hi Jim,

 

So at step 3, if SMSAVEDSESSION is expiring, I would expect SMSESSION also to expire, when being prompted to login.fcc.

 

Is that not happening ?

If it isn't happening , one way would be to implement a logic in the login.fcc to clear SMSESSION cookies on the load of login.fcc ?

 

Regards,

Ujwol

[Jim Lundell]

Thanks for the reply!  Is there a setting in the web agent that determines whether or not the SMSAVEDSESSION gets expired for this condition.

 

For this application, if a user is not authorized we prefer to send them to an authorization error page vs. sending them to login again.  This behavior works properly when Impersonation is not occurring. I.e, they are redirected as expected to a URL associated with an OnAccessRject event.

 

However, if impersonation is not allowed as determined by the Impersonation rules then the user is challenged by the FCC associated with realm.  Before the user is sent to the standard login FCC, the agent expires the SMSAVEDSESSION. As this may be happening on a server-side call our impersonators are unaware of this behavior.  Thus, they are still able to view the permitted contents while Impersonating.   However, the end impersonation FCC fails as they do not have an SMSAVEDSESSOIN.

 

Should OnAccessReject fire when an Impersonator is not allowed access?  This is my real issue as I do not want the Impersonator to be challenged by the realm's auth scheme.

 

Cheers, Jim

[Jim Lundell]

Any suggestions on how to best handle this behavior?  Or is this a defect with the Impersonation architecture and therefore I should submit a request to get this fixed?

 

Cheers, Jim

[Ujwol]

Hi Jim,

 

My test suggest different result. It seems there is some configuration issues at you end.

 

Here is my test case :

 

1. Impersonator access impersonator resource /impersonator/index.asp and provides valid credential.

2. Once impersonator is logged in, he starts the impersonation and impersonates user - "impersonatee"

3. On successful impersonation, he is redirect to impersonatee resource /impersonatee/index.asp (note this realm has Impersonatioin related rules- impersonatestartuser & impersonationstart)

4. Now, the impersonator tries to access /impersonateeonly/ resource, i.e realm which doesn't have impersonation related rules - impersonatestartuser & impersonationstart) (Frame 10)

5. However, as the impersonation event/rule is not configured on /impersonateeonly/ realm, the impersonator user session is not valid and is thus redirected to the login page.

6. However, at this point unlike your test, neither of SMSAVEDSESSION or SMESSION is deleted (Frame 11)

7. Now, as the impersonator finds he doesn't have access to /impersonateeonly/ realm so he access the impersonatee resource which he has access to - /impersonatee/ (Frame 12)

8. From here, on he can now successfully end impersonation

 

So , as per my testing, there is no problem ending impersonatee session during error condition as well as no session is deleted.

 

I have attached the fiddler for your reference.

Please let me know if you questions.

 

Regards,

Ujwol

Attachment(s)

ImpersonationTest.saz.zip   48 KB 1 version

[Jim Lundell]

Ujwol,

 

Thank you for taking the time to test the above flow.  We are on R12 SP3 CR13 still and will be on R12.52 soon.

 

It is nice to know it is working with the latest version; thus, if I have still have problems on this version I'll keep researching my issue.

 

Again many thanks for your time!

 

Cheers,

Jim