OAM 11g session management

In OAM 10g and other products in the WAM space there is no actual tracking of a user's session. Usually in those products when a user logs in they are issued an encrypted cookie that tracks the login time, authentication level, the idle and maximum session times and a few other bits of information. If a user had such a cookie they were logged in, if they didn't they weren't. This sort of architecture was designed in a time when building massively scalable session tracking mechanisms wasn't really possible; in other words there was no way to build a million concurrent user SSO scheme deployed worldwide if you had to keep track of every active user session in a database or LDAP directory.
Times have changed.
OAM 11g takes advantage of a cool technology called Oracle Coherence. I'd tell you what Coherence does, but they do a pretty good job right there:
Coherence provides replicated and distributed (partitioned) data management and caching services on top of a reliable, highly scalable peer-to-peer clustering protocol. Coherence has no single points of failure; it automatically and transparently fails over and redistributes its clustered data management services when a server becomes inoperative or is disconnected from the network. When a new server is added, or when a failed server is restarted, it automatically joins the cluster and Coherence fails back services to it, transparently redistributing the cluster load. Coherence includes network-level fault tolerance features and transparent soft re-start capability to enable servers to self-heal

By plugging Coherence into the OAM architecture Oracle added the ability of the OAM Server to track all active users sessions without needing to go back to a massive central store (for example a database) and without needing to worry about building a replication strategy. Coherence hides all of that complexity and solves what is still a massive problem for some of our competitors. In the sequence diagram in my previous post I only drew the lines for HTTP traffic. I left out a bunch of stuff like the OAP communication from WebGate to OAM Server and the fact that the OAM Server will check that the session is active and legal before granting access. The more accurate, but still simplified, OAM architecture diagram looks more like this:
Each time the OAM WebGate talks to the OAM Server to ask "is the user authorized to see this resource?" the OAM Server checks the Coherence cache and will say "NO!" if the session has been deleted.
So if you want to terminate an user's session you can!

More Here



Post a Comment