Single Sign On
The Gluu Server stack includes both a SAML and OpenID Connect Identity Provider which can be configured for single sign-on to any SAML 2.0 or OpenID Connect protected application. In addition, the Gluu Server now also support the Central Authentication Service, or “CAS”, protocol.
B2B or B2C
Organizations frequently have different requirements to authenticate employees and customers. Usability is not quite as important to an employer — use our security or there is the door! For customers, usability is more important — sometimes the best authentication for customers is the one they never even see. Through the use of custom interception scripts, the Gluu Server can support any authentication logic or mechanism you can script.
During installation of the Gluu Server you can deploy a component called Passport.js to support social login. With over 300 existing “strategies”, Passport provides a crowd-sourced approach to offering your users social login at popular consumer IDPs. Passport not only normalizes authentication, it also provides a standard mapping for user claims to enable dynamic registration in your Gluu Server IDP. Read the docs
SSO Across Protocols
When a person logs into an app via your Gluu Server, they receive an SSO session for all other apps that rely on Gluu for login regardless of protocol. So someone could log into a SAML app and then have SSO to an OpenID Connect app, and vice versa. This ensures a seamless user experience across homegrown, off-the-shelf, and SaaS applications.
For customers who need to support inbound SAML authentication for partners or other organizations, the Asimba SAML proxy can be deployed. Websites can point to a single Asimba IDP and enable SSO to a number of trusted IDP’s.
SAML SP & OIDC RP Software
In order to complete the single sign-on (SSO) transaction your target application must be secured with either SAML or OpenID Connect. Many commercial applications ship with support for one of the two protocols. In general, there are two ways to secure an application that does not already support federation in order to leverage a centralized access management platform like the Gluu Server:
1) Use a Web Server Filter / Reverse Proxy;
2) Leverage the protocol directly in your application.
Which approach to pick depends on the trade-off between easier devops (approach 1), and deeper integration of centralized security policies in your application (approach 2).
If you decide to use the Web Server Filter / Reserve Proxy approach, we recommend using the Shibboleth SAML SP or the Mod Auth OpenIDC module. If you prefer to leverage the federation protocol directly in your application, check out our client software called oxd.