Can anyone help me to understand how to achieve SSO using Web Services Authentication.
I have following queries.
1. How to achieve SSO using pure WebServices Authentication? i.e. SPS Java Agent.
For an example, as part of successful REST login event, Siteminder returns Login Response which contains SessionToken. Having this, how do we achieve SSO between multiple applications which uses only REST authentication.
2. How to achieve SSO between standard web agent and web services sps java agent?
For an example, I have a normal web agent based application and I wanted to achieve SSO with an application uses REST authentication. Applicable reverse vise scenario like SSO between Rest auth with standard web agent.
Just like any normal agent, the Auth/AZ web service authentication call also returns SMSESSION cookie.
To be able to SSO with other SPS Java agent or normal agent, you will need to just send this SMSESSION cookie in the request header.
Thanks Ujwal. From the below login Success response, <sessionToken> part contains session info. I believe it represent SMSESSION.. Is this correct?
Just to be clear: On the SSO part, for an example, application 1 uses REST authentication and SMSESSION send in xml response as part of login success. If an application app1 wants to SSO with another application app2, it can use the SMSESSION in request header. Here, how will application maintain the logged in user session? for an example normal web agent sets the cookie in browser, in web services authentication it is all about xml response and application has to capture the cookie and store it somewhere. Can you help me to understand this better? like where the cookie can be stored and how is it re-used to achieve SSO calls?
Similarly, app3 which is normal webagent and it need SSO with REST web services based application app1 & app2. In this scenario, if user has a valid smsession generated by the normal web agent, it needs to be passed in header request to achieve the SSO with web services application.
Is this correct?
Your understanding is correct.
The "sessionToken" returned from Auth/AZ web service call is nothing but SMSESSION cookie.
So, if you are going to do SSO with another SPS Auth/AZ java agent, you will basically need to send this token instead of username and password.
Similarly, if you are going to do SSO with another normal web agent, you will need to create an SMSESSION cookie with this sessionToken value and send this along with your request.
Here is how I tested this to verify :
1. First using SPS Auth/AZ web service and using username and password create the sessionToken
2. Next, for any consequent request, you can send this token and perform SSO instead of sending username and password again :
3. Next, to test the SSO with the normal web agent, in chrome browser using "EditThisCookie" plugin I manually created SMSESSION cookie using the sessionToken value returned from SPS Auth/AZ authentication call :
4. Then, in the same browser session , I was able to access the protected resource without any challenge. This confirms I was able to perform SSO to the normal web agent protected resource using the sessionToken generated by SPS Auth/AZ web service :
Hope this clarifies your question.
Ujwol's Single Sign-On Blog
Thanks Ujwol .. It helps a lot...