Basics of sessions in Content Management

Somewhat motivated by a post by Appu Nair I figured I'd write a small bit about LLCookie, OTCSTicket, and the database table inside of the Content Management database.

Long ago we had a model where user information was encoded into the cookie that was sent to the users browser. Then when that cookie was sent to the server it would decode that data leveraging the cookie encryption key and use this information to validate the user.

In Extended ECM 21.2 we reworked authentication and changed the behavior. Now the value that is returned to the client and stored as LLCookie or the OTCSTicket is a random string with no encoded data inside of it. All of the session information was stored server side and the value of the LLCookie or the OTCSTicket was only leveraged to look up the correct row in the database.

Digging Deeper

So how do we manage the actual session information? We store user sessions in the Content Management database. There we have a sessionid recorded. This actually isn't the value of the LLCookie or the OTCSTicket but rather the SHA512 hash of it. This is important as it prevents someone who may have access to the database from being able to imitate any other user in the system by passing in the stored sessionid as a OTCSTicket or LLCookie.

Another benefit of this system is that Content Management actually doesn't have a copy of any users LLCookie, or OTCSTicket value stored. Once it is generated and handed to the client that is the only copy, only a hash of that original ticket is stored in the system.

Additionally we store a blob associated with each session. This is actually an encrypted blob which is leveraging the cookie encryption key as defined on the Security Parameters page. The segmentblob is an encrypted copy of the users session information. The server decrypts this value and compares it to what is stored in the database and will detect any manipulation of the data. If there is a mismatch it will not authenticate the user.

Performance Performance Performance

Moving the session information to the database as presented some interesting side effects, mainly with automated solutions that are programmatically accessing the system. Historically they were able to get away with authenticating non-stop. Creating session, after session, after sessions with each operation. However in this new model each authentication is an interaction creating a new row in the database, which then could be flooded with new rows that are valid for the defined expiration window. Often creating a session valid for 8 or 12 hours, but using it for a few seconds at most.

Ideally applications that are performing this way should be updated to store their session and use it multiple times, for many operations rather than rapidly discarding them. We have plans to implement a cap on the number of total sessions that single user can have, however this is not yet in the product.

Back to post listing