Ordered list of blogs will go here with a widget
While all web communication is stateless, there are times where some state needs to be retained. Sometimes it is for user preferences. Other times it is to provide a bootstrap mechanism between two different applications. Lastly, there are the kinds that are used as a session token for determining who you are and what resources within the website you would have access to.
The work that I have been doing over the last year consisted mainly of the last part by integrating an identity access management (IAM) system from my client to one of their customers. Solutions may vary, but all focus on taking a user's credentials at the time of login and returning some kind unique session token that has a known lifetime. However an IAM system is not just a matter of authenticating a user and providing a token to ascertain that a user is actively using a website. They track other pieces of information such as what part of a website the user could have access to, and even inject some data as a part of the user's request to provide the underlying web application additional data such as the user's name or other identifying information.
For me in particular, the work with my client and their customer consisted of some reverse engineering to maintain backwards compatibility with their previous IAM solution ranging from how the authorization policies are put into place, how the requests and responses are treated, and even how to ensure that the session is refreshed.
With all of this in mind, this is the story of IBM's Tivoli suite of IAM products (which have since been renamed to IBM Security Access Manager), and what I've been able to reverse engineer integrating it with NGINX as the web proxying frontend, and CloudEntity's OrchIS Suite to provide the authorization, session and token management. This is not meant to be a comprehensive guide on the entire ecosystem, but more of some observations that have been made along the way of trying to retain state. Most of my information is based on Tivoli's WebSEAL version 6, which I know is quite old.
When you access any webapp for the first time, one of two things will happen:
Item 2 may require a little more information. The cookie will resemble something
along the lines of JSESSIONID being included in your browser, which is used by
a Java based web application to maintain user session state specific to that
application. For CloudEntity, they have a generic name for the cookie called
token which consists of a uuid string. In the case of IBM's WebSEAL
(their web proxying product), they use a cookie called the PD-S-SESSION-ID.
Unlike most other session cookies I've come across, this one consists of
several base64 encoded binary parts concatenated together to provide a single
mutable token.
The first thing that was discovered during our porting process was that the
PD-S-SESSION-ID token was mutable, but it took a while to figure out the how
and why. Looking at a single token:
uYFjw3G7P2i2PNiw8kE4+e5buEGkAoaAE+fyquLolGwGLuzqvi0=_AAAAAAE=_0EYoxtctnYeZEUV5czFTdy7Ej24=
One can break the token down into three components with the _ as the
separator:
For sessions that are unauthenticated, only the first part is present. The other two are added once a user has logged in. The second part is a bas64 encoded counter that gets updated after a given interval or if there is a major event that requires action on the user's part to indicate that said action was complete. Think of it as a timer where, given a timestamp of when the session was authenticated, one can determine how fresh or stale the token is from the last time it was refreshed, and WebSEAL can quickly determine if the session is still valid without having to query some kind of session cache or backing store. In addition, from what I can tell with the third component, this is where details such if a user needs to change their password are stored and when the session was created.
Think of the case when you log in, and then you are prompted to change your
password. WebSEAL needs a mechanism to pass a flag to indicate that you need
to be redirected from the login page to the change password page. This is
where the third part of the PD-S-SESSION-ID comes in, and why it is bound
with the freshness token. Once you change your password, that state attribute
needs to be updated, and for it to get picked up, the freshness token is
incremented outside of the normal heartbeat interval. This means if you have
something that is caching the older session token, and it doesn't pick up that
change from WebSEAL, then the user will forever be redirected to change their
password.
In my case, I was working with bridging another IAM product into the WebSEAL environment, and had to maintain some backward compatibility. One of which is to ensure that the WebSEAL session token is not only consistent, but also kept up to date, especially when the user's browser ceases interacting with applications protected by WebSEAL. Among some of my observations:
One can artificially advance the freshness token and as long as they send it to the same WebSEAL host the session was last updated from, then WebSEAL will be sure to send the correct/most recent session token.
If it is an older token, then WebSEAL will send you the most recent session token provided the delta from when it was created and the last update doesn't exceed the session length.
When going between different WebSEAL hosts backed by the same Tivoli Access Manager stack, the underlying component, Policy Director, will crash resulting in a 500 error being sent back to the browser. I'm not sure if this is meant as a protective mechanism for WebSEAL when it gets into an unsupported state, or if this is an underlying bug. The version I was using was quite old at the time though.
This is just one of many different Identity Access Management products out there, but does show that things such as cookies and session tokens can never be assumed to be static, unless you explicitly know what they are being set to and used for.
Tune in for my next posting on the wonders that are cookies and some things to keep in mind when making use of a reverse HTTP proxy.