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
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
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.
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
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
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
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
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
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
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
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.
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.