User Management Request for Information (RFI)

In an effort to help others with similar questions, from time to time we publish the RFI’s we receive with our corresponding answers (of course stripped of any sensitive and/or organization specific information). We received the following RFI a few days ago from a colleague at a large organization that is evaluating a user management/SSO project.

The content with asterisks are the questions we received and below is our response. If you have similar or additional questions, feel free to schedule a call with us to discuss.

Thanks, and happy reading!

Questions & Answers

* As a user, I want to be able to authenticate with single sign-on (SSO) so that I can access protected resources (data and some web services).

SSO is the main use case for the Gluu Server. It provides standard API’s (SAML/OpenID Connect) that enable SSO.

* As a user, I want to be able to use an external token so that I can access resources (data and some web services).

The Gluu Server is an OAuth authorization server. The common pattern is for a client to obtain an access token, and then pass it to a backend API (via POST, not GET!)

* A web page for registering users with pre-defined attributes that we should be able to customize (user id, password, role, etc.).

The registration features of oxTrust are for small deployments. For large deployments, we don’t recommend that oxTrust should be Internet facing (because it has powerful administrative capabilities).

You probably want to build your own user registration system, or use an off the shelf identity management platform, like Evolveum Midpoint. If you write your own registration app, you get the ability to customize the look and feel and workflow to your exact requirements. Then you can push the user information to the Gluu Server via the SCIM REST API’s (i.e. POST to the /user endpoint). The Gluu Server also supports LDAP synchronization.

* An OpenID Provider (OP) for storing user credentials and information.

The Gluu Server is one of the most comprehensive implementations of an OpenID Connect Provider.

* We would need redundancy for high availability.

The Gluu Server can be clustered across multiple servers to achieve redundancy and HA.

* We have several external Relying Party (RP) providing web services. We need a set of OpenID Connect Client libraries or methods to help integration of applications in order to minimize the development effort at external companies.

Gluu supports many OpenID Connect clients:

  1. Web filters (apache / nginx);
  2. Server side web applications (check out our OpenID Connect client software, oxd);
  3. Javascript browser-only applications;
  4. Mobile applications (iOS, Android).

* We need a scalable solution for a large number of users and authentication requests.

You can scale the Gluu Server to handle millions of users and the corresponding authentication traffic.

* Integration of social network login.

Through our passport module you can support social login to over 300 sites, including Facebook, Github, and more.

* Integration of other SSO systems to provide a federation. Those systems could be based on OpenID Connect or SAML 2.

The Gluu Server is also a SAML IDP. We also have a SAML proxy component (called Asimba) if you need to accept a partner’s SAML credentials.

* All the software should be open source.

The Gluu Server is 100% open source, as are the binaries (.deb and .rpm). There is a lot of client software out there. Some of it is open source, and some of it is commercial. You end up paying for convenience in some cases.

Have your own questions? Just schedule a call.

Use our calendar to schedule a call with us. Upon choosing a day and time, a calendar invite with GoToMeeting details will be sent to your email.