OPAM Session Manager internals

Oracle Privileged Account Manager 11g R2 PS2 has the concept of Session Check Out which is supported for SSH based targets (as of now)

In case of a Session Check Out

• The end user does not obtain a password to connect to the SSH target as it would in case of a normal Password Check Out (where OPAM creates an OTP of sorts)
• OPAM masquerades as and takes over the role of a SSH server and orchestrates the whole process.

This functionality is made possible by the OPAM Session Manager – this itself is a dedicated web application deployed on the same managed server as the actual OPAM (server) application. The OPAM Session Manager starts acting as a gatekeeper (sort of) which intercepts SSH requests on a specific port (as per configuration)

Take a look at this diagram to get a feel of what really happens (at least from a high level perspective)

OPAM Session Manager: High Level overview

 

Now let’s take this step by step and try and figure out what’s happening.

1. In order to initiate a Session Check Out, the end user triggers a SSH connection on a pre-defined port (configured via OPAM Admin GUI) using appropriate tools e.g. Putty (my savior !)
2. As mentioned earlier, the OPAM Session Manager (a web application) acts as the gatekeeper and intercepts the requests (in the above diagram the port is 1222 – default OPAM configuration). It does so via listener threads which it spawns internally. Instead of the SSH server (target) password, the end user can just use his OPAM credentials itself (I hope you realize how critical this is! no more using target passwords at all) and OPAM Session Manager delegates the authentication to the Master – yes, its the OPAM Server. It does so via a simple REST call. Nice and easy so far !
3. The OPAM Server sends back the response of the authentication request back to the Session Manager.
4. There is no point talking about an unsuccessful authentication attempt. Right?! Of course the end user does not get access to the target! What’s more useful is to understand what happens if the user authenticates successfully. On a successful authentication attempt, the OPAM Session Manager internally opens up a channel to the actual target (SSH server) and forwards all requests via the end user to the target without exposing the target directly to the end user. This is extremely vital and is directly responsible for the Real Time Session Monitoring capability which OPAM provides. OPAM internally uses JSCH library to communicate with the SSH target.
5. All the commands executed by the end user via the SSH tool (Putty) are pushed to the OPAM Audit DB in real time
6. When the OPAM Admin logs into OPAM console to access the Session Monitoring feature and chooses a particular Privileged Account which he wants to monitor
7. A simple REST call is sent to via the UI layer to the OPAM Server (with specific session ID)
8. The OPAM server honors the REST request and core server logic invokes the backed DB layer to fetch the data
9. All that’s left is the data to show up in the UI itself ! There you go – real time (almost!) account activity monitoring, courtesy the OPAM Session Manager

For more on OPAM

• Official OPAM guide
• Previous blog entries on OPAM- here and here

Keep exploring and have fun.

Cheers!