Introduction

I recently worked with a customer who needed to do some OAM session manipulation via custom code in order to implement a complex use case. While the focus of this post is not to go into details about a specific implementation, I did want to share some advice on a very necessary building block needed to do “out of band” session manipulation: retrieving the OAM Session ID.

What is the Session ID (used for)?

OAM 11g supports the concept of a server-side session (unlike previous versions where the only session state was represented by a browser cookie) and this architecture allows for a far richer set of functionality, including the ability to manipulate the server-side session through the addition of attribute values that can be considered during the evaluation of an OAM policy. Each session stored in the server session store (shared across the cluster using Coherence) is identified by a unique GUID known as the Session ID – that’s the long number you see in the folllowing screenshot, taken from the OAM Admin Console:

The reason this identifier is useful, though, comes when you start to look at the API Docs for the OAM Access SDK, which is the component you’ll need to use in order to do things like session manipulation from custom code. Looking specifically at the UserSession class, you’ll note that many of the constructors and utility methods require that you pass the SessionID as argument; this is a mandatory step in order to obtain a reference to an existing session in order to manipulate it. In this scenario, you don’t want to be using the UserSession class to create a brand new session.

Just a clarification at this point. Please do not interpret this post as a blanket endorsement of writing a custom Access Client as the solution to any and all problems. As always, work with your chosen OAM architect to carefully weigh up the pro’s and cons and various options available, with a strong preference for using out-of-the-box functionality, before concluding that custom code is the best way to solve your particular problem.

Assuming we’ve complied with the above caveat, done the necessary homework and concluded that the custom Access Client solution is what we have to do, what we then need is a way to obtain the Session ID from an existing authenticated user session in order to pass it to our custom code.

Using Identity Assertion to obtain the Session ID

Step 1 here is (perhaps obviously) to ensure that we place a WebGate in front of our custom code in order to ensure that there is actually a session in place and that we can use an authorization policy response to transfer information to that code via headers (the usual OAM approach). Now, for a number of very good reasons, the Session ID (a sensitive piece of information that needs to be protected) is not available as a direct policy response, in the same way that the user id, profile attributes or session attributes would be. As is perhaps clear from reading the AccessSDK documentation, you can do a lot of harm with this SessionID in your hands and, as such, it behoves you as an organization to take appropriate steps to protect this data within your code and over your network.

Treat the SessionID, in other words, just as you would a password. Do not write it into log files, do not send it over network links in clear text and take the necessary precautions to ensure that headers sent from your web tier to your app tier cannot be tampered with or spoofed. All the usual rules regarding safe and secure identity propagation apply, in other words.

With caveats and good practice advice out of the way, let’s talk about how to get this magical nugget of info into your custom code. The answer is to enable Identity Propagation for the Authorization policy protecting the URL, as per the following screenshot.

Once you do this, you will find that a SAML assertion is sent from the WebGate to your app in a header called “OAM_IDENTITY_ASSERTION”. There’s a lot of info inside this assertion, but you’re looking for the following snippet within the XML body.

<saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xs=”http://www.w3.org/2001/XMLSchema” Version=”2.0″ ID=”6714fd68-596c-4cfa-af61-91b43a5ecd2a” IssueInstant=”2015-10-23T09:34:23Z”>
<saml:Issuer>OAM User Assertion Issuer</saml:Issuer>
…..
<saml:AttributeStatement>
<saml:Attribute NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” Name=”urn:oasis:names:tc:SAML:2.0:profiles:session:sessionId”>
<saml:AttributeValue xsi:type=”xs:string”>d8ccd738-522f-4700-a91c-fd630b70ff61|S+kAgs+tqO+Rblq6abFwllAo5J4=</saml:AttributeValue>
</saml:Attribute>
……
</saml:AttributeStatement>
</saml:Assertion>

Right there, in the bolded text, is your Session ID. Use it wisely – keep it secret, keep it safe.

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission