The document provides an overview of claims-based authentication, including: - Claims-based authentication allows centralized authentication and sharing of identity information across applications through the use of claims in tokens. - A claim is a name-value pair that describes an aspect of a user's identity, like name, email, groups. Claims are held in tokens that applications can validate. - The authentication flow involves a user authenticating with an identity provider who issues a token with claims to the relying party application, which validates the token before granting access. - Common implementations of claims-based authentication include SharePoint, Azure ACS, and ADFS. An identity provider STS authenticates users and issues tokens,

1. UNDERSTANDING
CLAIMS AUTHENTICATION

2. INTRODUCTION
This presentation will give you short and not very technical
overview about claims-based authentication.
The claims-based authentication will be the way to almost
all Microsoft web-based platforms around. It is more
complex than old username-password method but also
more secure and general.

3. REMEMBER THE HISTORY
We were depending on AD, SQL Tables.
Text fields, ASP.NET Membership Provider.

4. Traditional Authentication

5. Traditional Authentication

6. Traditional Authentication

7. CLAIMS TO THE RESCUE
Reuse across applications: Centralized Standards Conformant
Centralize “Who Am I” logic, allow applications to focus on What can I
do” Consuming applications never know your password
Allows for B2B Collaboration w/o AD trust
Allows for B2C Collaboration without managing user identities
The cloud demands it

8. What are claims?
Claim is piece of information that describes given identity on some
aspect. Take claim as name-value pair. Claims are held in authentication
token that may have also signature so you can be sure that token is
not tampered on its way from remote machine to your system. You can
think of token as envelop that contains claims about user.
• Token may contain different claims:
• username or user ID in remote system,
• full name of user,
• e-mail address,
• membership in security groups,
• phone number,
• color of eyes.

9. EXAMPLES
Security Token Signed XML document containing claims
SAML Standard token language, popular in enterprise, self
contained spec 1.1 and 2.0
OAuth Another claims standard, more popular on consumer applications
Open ID
JWT (JSON web Token) Open ID method of exchanging tokens
WS* WS-Trust, WS-Federation, WS-Security Policy

10. Claims-based authentication
Claims-based authentication is more
general authentication mechanism that
allows users to authenticate on external
systems that provide asking system with
claims about user.

11. The Claims-based authentication
flow
• User makes request to some
application.
• System redirects user to
authentication page of external
system (it may also happen after
system lets user to select external
system where he or she wants to
log in).
• After successful authentication
external system redirects user back
with some information.
• Application makes request to
external system to validate user.
• If user is valid then user gets access
to application.

12. Claims-based authentication in
practice
Claims-based authentication can be found from many
applications:
• Microsoft SharePoint 2010 and 2013,
• Windows Azure Access Control Services (ACS),
• Active Directory Federation Services (ADFS),
• Applications using Windows Identity Foundation
(WIF)

13. What is an IP-STS and what is a RP-
STS?
There are two kinds of STS: an Identity Provider STS (IP-STS) and a Relying Party
STS(RP-STS).
• An IP-STS authenticates a client using, for example, Windows integrated
authentication. It creates a SAML token based on the claims provided by the
client, and might add its own claims. A Relying Party application (RP) receives the
SAML token and uses the claims inside to decide whether to grant the client
access to the requested resource.
• An RP-STS does not authenticate the client, but relies on a SAML token provided
by an IP-STS that is trusts. Typically, an IP-STS is found in the client’s domain,
whereas an RP-STS is found in the RP’s domain. This is shown the following
diagram.

14. What is an IP-STS and what is a RP-
STS?

15. NOTE #1
The STS is super important, because it offers the
addressable endpoint through which I can interact
with the IP via the negotiation & encapsulation
protocol, it is from where I can get the certificate
that asserts the IP identity in a cryptographically
strong way; but the identity provider is more than
that, it is the set of identities it knows about, its
reputation, its capability of issuing cards (which are
NOT tokens, even if they are signed)

16. NOTE #2
• Sometimes the RP will accept only tokens from a special kind of STS,
the authorization STS,

17. A relying party (RP) is a computer term used to
refer to a server providing access to a secure
software application.
WHAT IS RP?

18. What is RP
• Claims-based applications, where a claim is a statement an
entity makes about itself in order to establish access, are also
called relying party (RP) applications. RPs can also be called
“claims aware applications” and “claims-based applications”, and
web applications and services can both be RPs.
• With a Security Token Service (STS), the RP is redirected to an
STS, which authenticates the RP and issues a security token
granting access, instead of the application authenticating the RP
directly. The claims are extracted from the tokens and used for
identity related tasks.

19. LET’S MAKE IT COMPLICATED
what it you need to establish multiple identity sources within one application?
• Configure your application to allow anonymous users to select their
authentication source (SharePoint does this method)
• Allow for a "Hub" approach where a core IP-STS is also a RP-STS with
additional trusted claims provides (ADFS and ACS do this)