Tag Archives: sso authentication

SAML SSO with Shibboleth

Original Source – SAML SSO with Shibboleth

How to benchmark OX for a large scale deployment

OX was designed from the ground up to support clustered deployments. The application is stateless: no HTTP sessions are ever used. Even in a two-step authentication, it is not assumed that step one and step two will be handled by the same server. For this reason, OX can be clustered with any load balancer algorithm, for example, round-robin or failover.

Authentication services are only as robust and performant as their underlying persistence mechanisms.

OX uses the LDAPv3 interface for persistence of configuration, user data, and session information. The best two open source LDAP servers are OpenDJ and OpenLDAP. The best non-open source LDAP server is UnboundID. UnboundID also offers an LDAP proxy. To maximize the performance of an LDAP server, the entire dataset must be stored in memory–including the data and the indexes. Even for write performance, keeping the dataset in memory (and proper indexing of course), is necessary.

For a large scale deployment, where the entire data set cannot be stored in one LDAP server’s memory, the best strategy is to split the data up in two servers. For example, store users with last name A-M in one set of servers, and last name N-Z in another set of servers. In this case, the UnboundID proxy can use a cross-sever “global” index to route requests to the respective server that holds the entry.

OpenID Connect and UMA offer many endpoints to benchmark.

The OpenID Connect endpoints are :

authorization_endpoint
token_endpoint
userinfo_endpoint
clientinfo_endpoint
check_session_iframe
end_session_endpoint
registration_endpoint
validate_token_endpoint

The UMA endpoints are :

dynamic_client_endpoint
token_endpoint
user_endpoint
introspection_endpoint
resource_set_registration_endpoint
permission_registration_endpoint
rpt_endpoint
authorization_request_endpoint
scope_endpoint

Furthermore, oxTrust provides SCIM endpoints, which can be used for identity and credential management, and provides additional interactive business logic.

One important consideration for scalability is logout. For example, millions of clients polling repeatedly to make sure their session is still valid is a waste of valuable server resources. OpenID Connect defines a javascript session management mechanism. In this schema, javascript is inserted into each web page, and this polls a local browser flag to find out if another tab has logged out.

The approach can be problematic if the tab is not present when the logout occurs (i.e. the application may not be notified of the logout). If this mechanism is deemed insufficient for the requirements, an alternate logout strategy will need to be devised. Normally this may include using a callback to the registered back-end applications either in serial or parallel.

Benchmarking is an interactive process where the results of one iteration are used to optimize the starting configuration of the next iteration. The components of the infrastructure need to be tested individually. It is then important that the tests try to replicate the expected usage patterns.

For the OX APIs, Gluu can assist in the creation of test data, generation of the load, monitoring of the JVM for memory and connection leaks, and reporting on the resulting throughput.

For LDAP, the SLAMD tool is available. This tool provides load generation, measurement, system performance, and throughput reporting. The tool can be customized to include the collection of custom metrics to enable correlation of performance to OX API usage. Another consideration is to run long lived tests to make sure that replication data does not bloat entry size and negatively effect performance.

To CAS or not to CAS

 

Is CAS the hidden gem of authentication API’s or should it be end-of-life? Unequivocally, Gluu’s position is the latter–CAS filled a needed gap at the time, but now application developers should be discouraged from expanding the use of CAS. Here is why…

Background

Developed at Yale in the early 2000’s, CAS is now hosted by Jasig, a consortium that fosters open source software projects for higher education. CAS version 2.0 was finalized in 2005 about two years before the iPhone was introduced. CAS is known for its developer friendly (easy) client API. There are lots of CAS libraries for different programming languages, and many plugins are available for other open source projects. Its also supported by some vendors. For even more background, Wikipedia gives an informative overview of CAS.

Why not use CAS?

There are a few reasons you should steer clear.

CAS does not support OAuth2, and it probably never will. Faceook, Google, and Yahoo use OAuth2 for authentication, which represents about 85% of consumer authentications according to Janrain (provider of a widely used uber-authentication-api). Large consumer IDPs that are using OAuth2 are likely to quickly adopt the “OpenID Connect” profile of OAuth2, which will incentivize a staggering number of websites to follow. This will overshadow all previous web SSO/federation standards like CAS, old versions of OpenID, old versions of OAuth, and even SAML.

If you compare CAS and OpenID Connect, you’ll see not only does CAS have less features for authentication, but it does not support many of the endpoints defined by Connect: dynamic client registration, discovery, user claims, client claims. So its not just a matter of a different protocol for authentication, but a lot of missing functionality.

Even SAML support is weak. Many institutions that want both CAS and idp SAML use a “Login Handler” in the Shibboleth SAML IDP software to validate the username/password creds against the CAS server. In this way, the person gets both a CAS token and a SAML token, and has SSO with both kinds of apps.

In CAS, its not that easy to implement new types of multi-step authentication. Most deployments of CAS are for username/password authentication.

While its easy for mobile applications to use the CAS API to validate credentials, the protocol does not lend itself to more complex authorization scenarios where the backend services have different levels of permissions.

Conclusion

Like the little ant, OpenID Connect has high hopes. Where possible, use it. Make sure developers understand the roadmap for your organization: your domain, like all the other domains on the Internet, will adopt OpenID Connect. Use SAML to fill in the gaps until all the OpenID Connect libraries and web server plugins are available. SAML is going to be around much longer than CAS, so its a better bridge solution. Use CAS only as a last resort. You should require products and software that supports the identity integration method that align with your roadmap. Be flexible…using CAS is better than the app storing its own passwords. However, realize that this application will probably never support the two factor authentication services available in OAuth2 and SAML. There are many “good” legacy SSO protocols, don’t forget Siteminder in the Enterprise world… however, if you’re faced with the situation… try NOT TO CAS.