OpenAM, OpenId, REST API, In-House applications: how do I connect them all?

Question

I'm having trouble tying all of this together. Partially due to lack of understanding, and partially because I've not use OpenAM before.

I'm trying to implement Single Sign-on. Here are the players.

1. OpenAm. https://www.forgerock.com/en-us/products/access-management/
2. A 3rd party proprietary app that can use it's own username/password database, or authenticate against an SAML or OpenId provider.
3. Several In-house applications written in either angularjs or .net webforms.
4. An in-house REST API written in nodejs.

I need to be able to have a user sign-on/register in openam, and then they don't sign-in to any of the other applications. We see this all over the web, so the use-case is pretty normal, but I've never actually implemented it myself before.

See what I'm trying to do using the image below for starters.

Here's what I'm stuggling with:

For SSO purposes, OpenAM seems to store the authenticated user information in a cookie. How does my Proprietary app pick up this cookie and use it if it can only authenticate via openid or saml? It can't use the openam API by going through the /json/* endpoints.

With the in-house apps, I'm assuming I can just pass the cookie along and the appropriate parties can validate the cookie's session info or token and that's that. Is this correct, or am I looking at this wrong?

Can I have the user login to the OpenAm login page, and then use the /oauth2/* endpoints to validate the user's requests? I could see this working better, but am unsure if this is how it's supposed to happen.

Basically, I feel like I've scrambled my brain this last week trying to sort this out. I need some help to get some direction here. As I said above, a good portion of this is new. I've done front-end->rest api->database using a token, but this SSO scenario has given me a real headache.

Any help would be appreciated.

Answer 1

It sounds to me that you miss the "redirection" aspect of SAML SSO. I'll try to explain how it works in a nutshell:

Step 1:

When a user sends a request to one of your in house applications (call it the Service Provider, SP, from here), the SP detects that this is an unauthenticated request and redirects the browser to the OpenAM server (call it the Identity Provider, IdP, from here).

Step 2:

The IdP analyses the redirection request and expects to find a "SAML authnResponse", this is encoded XML metadata added in the redirection request by the SP. It finds out that your SP wants to authenticate a user. The IdP will respond to the request by showing a login page. Here the user can authenticate to the IdP. After the user succesfully authenticated to the IdP, it will redirect him back to the SP adding a "SAML authnResponse" to the request.

Step 3:

The SP will analyse this "SAML authnResponse", which is again just a form of XML metadata. If the validation of the signature is OK,find out which user successfully authenticated, create a session for him and redirect him to the resource he initially tried to access.

Remark 1:

In Step 2, if the user already authenticated to the IdP before, he will have an active session to the IdP. The IdP will not require him to login again but just inmediately redirect him back to the SP with a valid "SAML authnResponse". In this way the user will barely notice all these redirects and it will look like he 'seamlessly' got access to the SP.

Remark 2:

So don't worry to much about cookies, they're used by the IdP to recognize already authenticated user sessions etc. but you should only bother with redirects and analyzing the SAML Responses and Requests. Does this make sense?

Remark 3:

The way how the browser (GET 302 or JS POST) of the user will be redirected depends on your chosen "SAML Profile".