Pragmatic Approach, Practical Designs, Secure Implementations

We at Clarionics were recently involved in a few significant implementations of IAM technologies where the main requirement was to provide integration with existing enterprise security services like user authentication and authorization.

Enterprise Identity & Access Management (IAM) technologies have been gaining a lot of momentum in the last few years mostly due to their ability to simplify regulatory compliance and promise to reduce the amount of development effort spent by delivery teams on application security.

Since one of the big drivers pushing for  the use of centralized security services is lower integration costs with third party systems like CRM and ERP, we decided to look at standards based technologies like SAML to acomplish the task.

Issues to be solved revolved around providing user single-sign-on (SSO) functionality to web and client server applications, providing downstream applications with custom authorization attributes/roles which were available from enterprise user store and also providing  security layer for SOAP/HTTP based web services.

By using a standards-based approach, organizations can lower security integration costs because they can reuse existing products or libraries/components which in a proprietary scenario will have to be developed from scratch. Most developers are not well versed in security technologies and tight delivery timelines will usually lead to security problems down the road.

One of the big application security integration problems is lack of standards around handling of user security context and application security sessions. If we want to authenticate user at application A and communicate this information to application B it has usually meant custom development which cannot be reused outside of the implemented solution.

The SAML set of technologies changed this by introducing a standard way to carry not only user authentication information, but custom attributes and potentially authorization statements using XACML. But before declaring that SAML can solve all the problems, let's look at what is really needed to make it work within the enterprise.

Ability to generate SAML tokens

The SAML standard does not specify exact authentication mechanisms which can be used to produce SAML assertion, but the key point here is that to be able to produce a usefull SAML token, well managed enterprise identity services are a must. Users must exist in some type of centralized store, typically an enterprise directory with the necessary provisioning and deprovisioning processes. This is especially important if user level as opposed to system-to-system SAML tokens are required.

Since SAML is just a standards based statement representing an existing user identity in the enterprise, it cannot be expected to carry correct and reliable information if the user identity source it uses is not consistent and well-managed.

We also found that the SAML token generation service must be flexible enough in its ability to include custom attributes from a variety of existing systems; just to name a few common sources, they can be available as Active Directory user object attributes, Active Directory security and distribution group memberships, enterpise LDAP directory object attributes and group memberships, database fields, or content of custom HTTP headers.

Also for web applications, if user authentication is handled by enterprise web security gateway products like Oracle Access Manager, Tivoli Access Manager, Siteminder or similar, it will be necessary to be able to use a web gateway session as an identity source for SAML generation in order to provide a seamless user experience.

Support for SAML Web SSO Profiles

SAML standard includes a few web application SSO profiles which outline the authentication flow that can be supported. The main components are Identity Provider (IdP) and Service Provider (SP). The simplest scenario will involve a user agent (browser) accessing a specific application resource on IdP and after successful authentication, the user will be redirected to the SP resource location where he will present the SAML token with necessary information.

A slightly more complicated scenario will involve a user agent accessing a protected resource on SP where he will be redirected to IdP location to create an SAML token. On successfull creation of a SAML token the user will be redirected back to the SP location and will be allowed to access requested resource based on SAML token.

The key point here is to watch for specific SAML profile support within the products chosen to implement a solution. The good thing about SAML is that it uses standard functionality of common web browsers so nothing needs to be done on the client side.

Service provider (SP) considerations

As mentioned in the section above, depending on the SSO profile chosen, the SP will need to be able to handle initial communication/redirection to receive an SAML token from the client. After the user agent presents the SAML token to SP application, it needs to be processed, validated, and necessary context information must be extracted and passed to downstream business applications.

Most commercial SAML solutions come with SP side component for J2E architectures to support SAML SSO profiles which can be installed in the containers with no custom development. The thing to watch here is support for different SAML versions. Some products do not support all SAML 2.0 profiles, just SAML 1.1. It is not a huge limitation because application security designers usually have the freedom to steer application authentication flow towards the supported SSO profile with little impact to users.

When it comes to processing SAML tokens, you may look at processing them on the container layer (J2E, ASP.NET) or passing them to the application. Generally there is no reason why you even want to see SAML tokens within the application because the whole point of using SAML is to treat it as a security layer outside of the application core so it does not need to be developed and supported as part of core application functionality.

Identity Provider (IdP) considerations

If you need to establish SAML identity provider functionality within the organization, you can use a number of existing products to address your needs, but it is very important to understand that IdP must be looked at as a security service which must be available across the enterprise and over the Internet, if federation with external partners is desired.

Even if you are implementing IdP functionality to satisfy the needs of specific project, you will benefit greatly by building it to satisfy enterprise security services requirements.


SAML is a complex technology, but by selecting the proper mix of products it can be implemented in a supportable manner and will provide significant benefits to organizations.

SAML technologies should be implemented as part of enterprise security services with clear use patterns. Integration components can be reused by partners and internal application delivery teams without the need to understand details of security implementation (lower implementation and support costs).

SAML provides a secure standard mechanism for propagation of user identity and custom attribute information in one transaction between applications using only standard browsers.

Solid enterprise IAM is a key to success of SAML implementation.

SAML SSO profile support and SAML token consumption must be addressed by SP applications.

Having multiple SAML providers should be avoided (one internal and one external should be enough), but it's not a big deal as long as they are tied to the same identity backend.