Current State

As of this writing, the Overlord projects currently utilize a picketlink based SAML approach to SSO (single sign on).  The web applications all leverage a SAML IDP web application, which handles user logins.  The IDP then redirects the user back to the originating web application.  This is a very common approach to web application SSO and it works for us.  The picketlink code that we use for this integrates with JAAS, and the IDP is responsible for passing back a set of roles along with the user principal.

Once the user has logged into the web application, they will perform various actions and retrieve data that the UI gets from back-end REST services.  The calls to the back end REST services must also be authenticated, and they must be performed on behalf of the user who logged into the web application.  This is accomplished by using SAML bearer tokens.  Each time the UI (e.g. the S-RAMP browser) invokes a back end API (e.g. the S-RAMP Repository via its Atom API) it must create a SAML bearer token, which it includes in the request to the API.  The back end system accepts the SAML bearer token (which includes the user principal and all roles) as valid login credentials.

Likely Future State

We are considering moving from SAML as a default authentication mechanism to Keycloak - JBoss Community.  We believe that Keycloak solves all of the authentication problems we currently have (in similar ways) while also offering additional functionality that we would like but don't currently have (e.g. self-registration, social login, etc...).  However, even more importantly, the Keycloak project is not as DIY as picketlink - it can be deployed without a lot of customizing, and it includes a nice admin UI to manage realms and users.  Using Keycloak would, for example, allow us to retire the SAML IDP and various SAML based authentication modules from the overlord-commons project.