OAM SSO integration question:How can I get a user identity from ObSSOCookie

Question

We are building an OAM SSO solution. The App server is both on OAS and WLS. My question is that, after I get the ObSSOCookie from httprequest.
I need to verify whether the ObSSOCookie is a valid one, and I also need to get user identity from the cookie and pass it to login module to populate user principal
Of course, one way of doing that is to install access manager SDK and go from there. But we support multiple OS, it's a pain to add Access manager SDK to different installer for different OS.
I am trying to use IdentityXML Functions which is a SOAP based webservice so that I don't need to worry about the OS platform. But I can't find a webService which returns user identity based on a valid ObSSOCookie. It seems that I can invoke webService with valide ObSSOCookie, but there is no way to get the user identity back. Am I missing something?
Hope someone can help me out.
Thanks.
-Wei

Answer 1

Ok. Sounds like you are a vendor trying to play well in an SSO environment.
Here is what I tell OAM customers when they are evaluating software to see if it will cooperate with a system like OAM.
Can the software's native authentication scheme be explicitly turned off (usually a configuration in a file)?
Can the software be configured to accept a token of identity in the form of a Cookie or HeaderVar (also configurable in a file)?
If the answer to both is yes, then the system is capable of 'third party trust' for authentication.
From your perspective, your logic for login should be something like:
Is my native authN turned off?
If yes, can I find the cookie or header that I should be looking for?
If yes, take the value and proceed to create user session for this identity per usual (except that you never evaluated the authN - you trust that it was done).
If no, present the native AuthN scheme anyway.
If you follow this pattern, you are in the good company of folks like PeopleSoft and Plumtree who had these types of integrations working long ago.
Yes, there are other ways to do this but, in my humble opinion, this remains the most stable and effective pattern we see.
What you ask for as the identity token value is up to you. It is often the login ID value that you would have used in your own authN procedure. There's nothing particularly sensitive about having a webgate set headers - they are only available to the server and not to the client. Cookie of course could be seen but can't be spoofed as the webgate has the final word on it's content.
Mark