Have you ever stopped to consider
the number of systems you access with a username and password? I have a
wonderful password management system to take the
headache out of remembering multiple passwords, and it tells me that I
have accounts on at least 93 different web sites. Imagine if every one
of these systems used a different username and password set . . . many
of them do! The OpenID Foundation saw this as an issue in 2005, when it
produced a new standard—the OpenID standard—for identifying users by
more than a username and password.
OpenID is a standard that
describes how users may authenticate with a system in a decentralized
manner, eliminating the need for systems to maintain their own
credentials and authentication mechanisms. OpenID also describes user
identities as consisting of sets of attributes, or claims, rather than
a username specific to an authentication scenario.
As OpenID gained rapid adoption from 2005,
Microsoft, and other system implementation vendors, adopted OpenID
standards in its products and systems. Microsoft first introduced
Windows Card Space as the solution to avoiding usernames and passwords,
and instead managing a set of claims about a person with a
given card. SharePoint 2010 includes Claims-Based-Authentication to
fully abstract authentication from the SharePoint platform and
identifies authenticated users via a set of augmented claims.
Identity Management
The principal idea of Identity Management is
that identities consist of a set of attributes in a given context
space. In simple terms, an identity for a given individual might
consist of several attributes, such as first name, last name, e-mail
address, social security number, etc. On its own, each attribute means
very little, but combined with other attributes constitutes the
identity. For example, my name is Rob Garrett; several other people in
the world have the same first name, and likely the same last name. My
first name, last name, or even both together do not uniquely identify
me as a person, so how is a system, like SharePoint, to know I am who I
claim to be? Add my e-mail into the mix and we begin to define my
identity, and not that of another Rob Garrett, since my e-mail is
unique to me. As we continue to add more attributes to my identity,
there is no doubt that the identity refers to me specifically, and not
some other fortunate person to share the name Rob Garrett.
Although I am one individual with one physical
presence, I can have multiple identities in the electronic world. My
bank might require my identity to have a large collection of
attributes, to ensure I am really who I claim to be, whereas a social
site might not need so many attributes because security is more
relaxed. Of course, when I refer to the attributes of my identity, what
I am really describing are “claims”—I claim my last name is Garrett, I
claim my first name is Robert, and I claim my twitter ID as @RGarrettPro. Figure 1shows
a graphical view of identities and attributes (claims) and how they map
to entities (people and objects) in the real world.
Identity Authentication
With an understanding of how identity works,
how does an entity (person) authenticate with a system that supports
digital identifiers? There is lots of information about this subject on
the Web, so I shall cover the process at a high level. To begin, the
following are the main components in an abstracted authentication
process:
- Identity: a set of attributes describing the user or other form of entity with secured access to a system.
- Relying Party: the system that requires authentication of an entity—the system itself, in our case—SharePoint.
- Claim: a piece of information
(attribute) of a given identity. A set of claims constitutes an
identity. We use the term “claim” rather than attribute because the
delivery of claims is such that an entity asserts a set of claims about
him/her, rather than looking up an attribute in a directory by the
Relying Party.
- Security Token: an encrypted piece of
information, consisting of a set of claims and request of a given
Relying Party. An Issuing Authority might encrypt a Security Token and
always signs it. The signature is very important because this ensures
that only the Issuing Authority created the token and not anyone else.
- Issuing Authority: the party
responsible for providing a set of claims about an entity. The Relying
Party passes the responsibility of authentication of an entity to one
or more Issuing Authorities, who provide a Security Token for an
authenticated entity. The Issuing Authority makes use of X509
certificates to sign Secure Tokens so that the Relying Party can
validate secured tokens as authentic.
- Secure Token Service (STS): a service
that issues Secure Tokens according to WS-Trust and WS-Federation
protocols. Examples of STS include Active Directory Federated Services
(ADFS) and the STS built into SharePoint 2010 and 2013.
- Client: typically a web browser and user looking to authenticate with a web application (Relying Party).
Figure 2 shows a basic authentication scenario, described as follows:
- Client sends a request to the Relying Party (RP) to access secured content.
- RP sends back policy for authentication—RP may send a selection of identity providers for user to choose.
- User selects an identity provider (if multiple providers)—the Secure Token Service (STS) of an Issuing Authority (IA).
- Client sends an authentication request to the STS of an IA.
- Assuming successful authentication with the IA, the STS sends an encrypted and signed token back to the RP.
- The STS sends the same token back to the client. The RP and client now have a common trust via a shared secure token.
Secure Tokens
Secure Tokens consist of an XML file
(typically encrypted) that includes a list of claims about an identity.
This XML file goes by the common name of Security Assertion Markup
Language (SAML) token.
The number of claims within a SAML
token and provided by a Secure Token Service depends on the policy of
an Issuing Authority and the policy of a Relying Party discovering a
set of claims about an entity. The SAML token is encrypted using the
public key of an RP (if encrypted) and signed using the private key of
an IA—this ensures that the RP can check that the token originated from
the IA and that only the RP can decrypt the secure token. Should
someone intercept a secure token in transit, the signature and
encryption ensure that a third party cannot read or modify the contents
of the token.
