An important part of your overall Information Technology security strategy needs to account for how your application will handle user identity. Specifically user identity, in the digital sense, encompasses information about a user made available for applications to use. The term user here is slightly misleading. A user doesn't have to be an actual person, but can also be another device or application. Not all strategies are equal in terms of flexibility and choice when it comes to extensibility and interoperability. In this article, I will discuss claims-based identity as a strategy for addressing user and device identity within and outside of your organization.
Traditionally, users have presented their proof of identity, in the form of a username and password, to an application. An application, using one of many possible means, then verifies that the user is who they say they are through a process called authentication (AuthN). The next step is often to acquire additional information about the user, such as their assigned roles, in order to check whether or not the user has access to particular application functionality.
This process is called authorization (AuthZ). Once a user is authenticated and authorized, the application can continue to use any other available information about the user in order to perform its intended functionality. For example, an application may send e-mail notifications to a user if it knows the e-mail address, or may personalize a home page by displaying the logged in user's name.
Deciding the right user identity strategy
Most business applications require some form of digital user identity. In deciding the right technology to convey user identities within a particular application, you have to consider how the application will be used and where it will be located, what identity information it requires, and what the impact would be on your IT infrastructure and staff.
For applications which will be made available only within your company's intranet and accessed solely by employees within the same security boundary or domain, the solution may seem straightforward at first. Technologies such as directory services make it easy to provide a single sign-on experience across applications located within your company's internal network. Applications can simply query the directory service for any additional information not provided when the user first signed in.
For solely Internet-facing applications, the solution might be to simply use forms-based authentication and store user names and passwords, securely, within a database, along with perhaps some personalization information as part of the user's profile.
Heraclitus of Ephesus believed that "nothing endures but change." Another, more familiar, term is "change is the only constant." It can be said that this is certainly true of the technology industry.
Modern applications can no longer be expected to simply provide integration points through batch data extracts and imports. For today's user, applications need to support near real-time integration capabilities. Applications are expected to provide APIs in addition to user interfaces for consuming entities. But this talks to how an application could be used. Where an application runs and who uses it are also subject to change.
Applications and their endpoints should be secured in a manner that can not only serve the needs of users today, but also the users of tomorrow as the business landscape changes. IT must be prepared or risk falling behind in its ability to support the pace of business.
For instance, what if your company undergoes a merger or acquisition or forms a partnership with another organization and now needs to extend access to your internal applications to this new organization? How will you share identities if your organization uses Windows and your partner uses Linux or Macs? What if your senior management decided to incorporate software as a service (SaaS) as a business strategy? How will your customers access the software? How will your customer's customers access the software? What if a Product Manager decides that your applications should also support Facebook accounts? What if your CXO decides to execute a long-term strategy of moving your internal applications to the cloud?
Let us assume for a moment that the aforementioned scenarios turn into real requests for an unprepared IT organization. Without a flexible identity strategy in place, the organization scrambles to accommodate. Perhaps it begins by first modifying the impacted applications to support the new identity scenarios demanded by the business.
It soon realizes that the existing applications were built on top of platform-based security features which have been tightly coupled to the application code and are not so easily extensible. Perhaps a custom security authentication approach is concocted as a short-term "workaround" by development where multiple authentication mechanisms are hacked together in a non-standard manner.
These workarounds can lead to unintended security holes, much to the dismay of the company security team. Production also has to be supported while this new security infrastructure is put in place so tack on a data migration effort. Custom security implementations which are not based on well-known and well-tested industry standards and protocols tend to not be extensible or interoperable. Such implementations lead to supportability nightmares and hamper IT productivity.
Data governance, as it relates to identity information, is often an afterthought amidst schedule pressures. Users may find that they have to deal with multiple account stores and identity fragmentation proliferates. These custom security approaches can lead to identity stores which are invisible to identity management products. Ultimately, precious time is taken away from developing and releasing new application features that add business value.
Cross-cutting concerns such as security require involvement and participation from IT infrastructure, operations and development groups. Thoughtful consideration should be given towards formulating a cohesive strategy behind how your applications will handle user identity and some investment in the appropriate infrastructure should be made.
An oft-requested feature for applications, the term "single sign-on" conveniently abstracts away non-trivial challenges and the effort to implement is often underestimated. There are many ways to implement single sign-on, but you cannot assume that you will always have control over the applications that your users will demand single sign-on to, nor can you assume that your applications will always run within your network environment.
Making the case for claims-based identity
So then, what sort of strategy can you put in place so that your IT infrastructure and applications remain flexible when it comes to user identity and can change at a pace that will still provide the desired business value, on-time and on-budget? Is there an option that works for every situation (on-premise, inter-organization, or the cloud)? What would get us closer to this identity utopia so that the harmony between Business and IT can remain in balance in the face of such challenges?
One approach is to incorporate an identity strategy for your applications that is based on widely recognized industry standards designed to inter-operate across platform and organizational boundaries. These standards also have broad and wide vendor support in terms of product implementations.
With such a strategy, organizations can benefit from the momentum and convergence, particularly when it comes to infrastructure "goo" like security, and can easily capitalize on the investments made in this space by others. This is called progress.
This is where claims-based identity comes in.
In general, claims-based identity refers to a set of abstractions and a consistent approach over identity and access control which can help address some of the challenges faced by modern applications, such as supporting single sign-on between multiple organizations, whether the application is hosted on-premise, in the cloud, or some hybrid hosting model.
A central concept is the notion of a claim is:
- A statement that one subject, such as a person
or organization, makes about it or another subject.
- A representation of something about a user, such as e-mail, role membership, or favorite ice cream.
- Issued by a claims provider, also known as issuer for short. An identity provider (IdP) is a type of claims provider that can validate user credentials and issue claims.
How claims-based identity works
Claims-based identity relies on explicit trust relationships to first be established between those making the claims and any relying parties. Relying party (RP) is a term that refers to an application or device which relies on claims for user identity and access control. The only way a relying party will accept claims about some user identity from an issuer is if it trusts the issuer, or another issuer in the chain of trust.
Claims are sent to relying parties in the form of a security token, which can be represented in any number of formats, such as the XML-based Security Assertion Markup Language (SAML) or Simple Web Token (SWT). Software known as a security token service (STS), usually a software component of an issuer or owned by an issuer, is responsible for processing token requests from relying parties.
An STS packages one or more claims into a security token, cryptographically signs it, and sends it to a relying party encrypted on-the-wire. When a relying party receives the token, it verifies the token signature and if valid, proceeds to use the claims for any additional decision-making it might need to perform, such as authorization checks or personalization.
But what causes a relying party to request a security token to begin with?
With a claims-based approach, applications, or relying parties, no longer have to worry about taking on the responsibility of authenticating users, maintaining passwords, providing password reset mechanisms, etc. Many of these responsibilities are outsourced to an external entity, such as a claims provider.
Here's a typical flow for how a user gets authenticated in a claims-enabled Web application:
- A user attempts to access a claims-enabled Web application using a browser.
- The application checks for the presence of a special HTTP cookie. If it doesn't find it, the user's browser will be redirected, using well-known protocols, to its trusted issuer to handle the authentication details.
- Depending on the authentication mechanisms configured and the specifics of the authentication request, the issuer will automatically authenticate against some identity store, prompt the user for a home realm, or prompt the user for their credentials.
- Once the user has been authenticated by the respective issuer, the issuer creates a security token with a set of claims about the user.
- Using the client's browser, the issuer posts the security token to the application.
- The application validates the token and, because it trusts the issuer, assumes the user is authentic and establishes a session with the client browser. Note that, it is still up to the application to perform any additional authorization checks against the claims presented, to decide if the user has access to certain functionality (e.g., checking for a "Manager" role claim).
Once a user has acquired a security token from an issuer, they can leverage the security token for access to any other relying party applications which trust the issuer, achieving a single sign-on experience. I mentioned an issuer chain of trust earlier.
This is pretty powerful in that, even if the relying party doesn't trust the issuer of the security token directly, as long as it trusts an issuer which trusts the issuer of that security token, it will all still work. This is what is known as identity federation and it's how single sign-on can be achieved across realms, representing different organizations and security boundaries.
Your issuer can not only issue security tokens, but can also accept tokens from other issuers it trusts.
The way this works is that the issuer redirects remote users to first authenticate with their own issuer. Once the browser has received a token from their home realm, their token is presented to your issuer who accepts the token and in turn issues a new token for your application to use. This token exchange often involves transforming one set of claims into the set of claims your relying party expects. Your trusted issuer becomes what's known as a federation provider under this type of scenario.
This is how you federate security across organizational
boundaries. For example, by simply
establishing a trusted relationship between your applications' issuer and your
partner's issuer, you can easily enable access to your application to your
partner's user base. The application
does not have to change at all, simply a little configuration at the
infrastructure level based on some agreed-upon security policy.
By making applications claims-aware, moving the responsibility of authenticating users out of applications, and setting up just a tiny bit of supporting IT infrastructure, we wind up with:
- Application security architectures which are highly flexible, configurable and friendly to the changing needs of the business
- Simplified application architectures due to applications no longer having to deal with custom authentication mechanisms or having to maintain custom identity stores
- Applications which do not need to be modified, at the code level, in order to support additional user bases as a result of M&A or newly formed partnerships
- Happier users because users no longer have to remember multiple passwords or have to re-enter information in multiple applications
- Interoperable security based on widely recognized standards
- Application architectures which are cloud-ready when it comes to digital identity, and which can be easily extended to support online identity providers
Organizations interested in taking steps towards claims-based identity and whose business strategy will require the flexibility around user identity discussed in this article can choose to start taking incremental steps towards claims-based identity. For instance, new application development efforts can start taking advantage of claims-based APIs (which are backwards compatible with existing authentication mechanisms) until it is ready to shift its identity infrastructure to accommodate federated identity scenarios in the future. Changes to existing systems should be evaluated for return on investment, taking into consideration the specific organizational circumstances around new feature requests vs. cost of support and maintenance of non-standard security mechanisms.
By Michael Papasevastos
Michael is a Sr. Architect with Geneca, a custom software development company based in Chicago. He has over 17 years of experience working in the IT industry.