Claims-based identity refers to establishing a user's identity outside of an application and injecting identity information into the application in a secure manner. It allows applications to obtain authenticated user information programmatically or declaratively. While it improves the user experience and development process, claims-based identity does not solve all identity and access management use cases and some platforms require more custom work to implement it.

1. Deciphering 'Claims-based Identity'
Oliver Pfaff
September 13, 2014

2. 2
Sept. 2014 - All rights reserved
Preface
▶'Claims-based identity' presents an important concept. It was introduced some years ago and is well-covered
–Just Google this term
–Most notably: A Guide To Claims-Based Identity And Access Control (Second Edition)
▶However software product owners, application architects and developers often are puzzling about it
–I happen to encounter the same questions again and again
–So this is what claims-based identity means to me

3. 3
Sept. 2014 - All rights reserved
Approach
▶Create applications so that identity gets established outside the application
–This refers to the identity of the current caller
▶The environment establishes and injects required identity information
–This has to happen in a secure way
Application
request.getName()=JohnDoe
Identity
This is: name=JohnDoe
Environment
John Doe

4. 4
Sept. 2014 - All rights reserved
Blueprint
Application
request.getName()= JohnDoe…
John Doe
Identity infrastructure service
<e.g. Web application>
Container
Identity
enabling
module
<e.g. filter>
Authentication request (without credentials)
Security token
Identity
info
User
agent
You – as product owner, architect, or developer
One of your users
Else
Initial
authentication

5. 5
Sept. 2014 - All rights reserved
Flavors
▶Claims-based identity comes in two flavors, economy/business – if you will
–Economy: applications tell the identity infrastructure service at registration-time about their demand e.g. “I need info about age, residential address and loyalty program membership”
•Provides authenticated information about the current user in push-style
•Registration changes are needed to alter the set of supplied information
–Business: applications tell the identity infrastructure service at runtime e.g. “I need info about marital status”
•Allows applications to obtain authenticated information about the current user in pull-style (programmatically or declaratively providing the instructions on to-be-supplied claim information)
•Altering the set of requested information to e.g. “Hey, I need info about marital status and the mail address” does not mandate registration changes

6. 6
Sept. 2014 - All rights reserved
Ingredients
▶In order to offer an economy solution it takes a security token object that supports application-specific contents in a versatile way
–This is: name=JohnDoe, age=37, maritalStatus=divorced….
▶To offer a business solution it also takes an authentication request object that can express application-defined instructions
–I need: info about name, age, maritalStatus…

7. 7
Sept. 2014 - All rights reserved
Protocols
▶This addresses the question ‘which protocols bear the concept of claims-based identity’ for Web applications i.e. anything that relies on HTTP
▶It requires HTTP request/response exchanges that encompass a security token object capturing an event of authentication. So the shortlist is
–Kerberos: specified by IETF (RFC 4559); uses Kerberos tickets as security token form-factor
–SAML: specified by OASIS, uses SAML assertions
–WS-Federation (passive profile): specified by OASIS; supports various security token formats
–OpenID Connect: specified by OpenID Foundation; uses JSON Web Tokens
–OAuth UA4C: elaborated at IETF (work-in-progress); uses JSON Web Tokens

8. 8
Sept. 2014 - All rights reserved
Fluency
Economy
Business
Kerberos
Security token is not versatile: Kerberos tickets only inform about the PrincipalName of the requestor
Authentication request absent
SAML
Security token (saml:Assertion) is versatile
Authentication request present in SAML 2.0 but does not define the expression of to- be-supplied claims information*
Authentication request absent in SAML 1.x
WS-Federation (passive profile)
Security token can be versatile e.g. saml:Assertion**
Authentication request present and supports the expression of to-be-supplied claims information: child element wst:Claims
in wst:RequestSecurityToken
OpenID Connect
Security token (JSON Web Token) is versatile
Authentication request present and supports two ways of expressing to-be- supplied claims information: - OAuth Scope values - OpenID Connect request object claims
OAuth UA4C
Security token (JSON Web Token) is versatile
Authentication request present but does not define the expression of to-be-supplied claims information***
*: Its ‘any’ –type child element samlp:Extension supports custom content but things become proprietary
**: WS-Federation does not specify security token formats. It also supports non-versatile objects e.g. Kerberos
***: OAuth Scope values might be used but UA4C does not specify their use for providing such instructions

9. 9
Sept. 2014 - All rights reserved
Stacks
▶The following addresses the question 'which stacks encompass identity enabling modules/infrastructure services for claims-based identity’ for Java (Java SE/EE) and .NET

10. 10
Sept. 2014 - All rights reserved
Fitness
Economy
Business
Java
Servlet API allows Java Web applications to access authenticated information about the current requestor (request.getRemoteUser()/ getUserPrincipal()) which is supplied by container/application extension modules.
This does not specify rich representations of identity. Additional modules (IAM enabling) and custom conventions (between them and applications) are needed to supply caller identity in rich representations.
Additional modules (IAM enabling) and custom conventions (between them and applications) to provide authentication requests with instructions on to-be-supplied claims.
.NET
Natively supported:
• Identity enabling modules: WS-Federation Authentication Module (part of Windows Identity Foundation)
• Identity infrastructure services: Active Directory Federation Services (on-premises), Azure Active Directory Access Control (Cloud)
Natively supported (see left): instructions on to be supplied claims may be provided programmatically or declaratively

11. 11
Sept. 2014 - All rights reserved
Caveats
▶It takes two to tango: fluency of the protocol and ability of the stack
–Protocols:
•Economy: most shortlisted protocols are capable of doing the basic trick
•Business: not all shortlisted protocols do the advanced trick
–Stacks:
•DIY needed for Java
oNo identity enabling module for doing the trick comes off-the-shelf with Java SE/EE
oCurrent servlet API does not specify the supply of caller identity in rich representations
•Straight-forward with .NET
oOff-the-shelf components and default recipes do exist

12. 12
Sept. 2014 - All rights reserved
Limitations
▶Claims-based identity does not solve all IAM-related use cases
–Edge case: logged-in users perform operations which depend on information about other users (colleagues, buddies…)
•Claims-based identity is able to cover the first part: who is the 'logged- in user’ (identifier, properties) possibly including: who are the other users (list of references)
•But not the second part: what are the identities of 'other users' (their identifiers, properties). Packaging such information into security tokens issued for the primary user and binding that to an application session over-stretches typical boundary conditions
–Cf. Provisioning scenarios in identity federations for more background
▶Claims-based identity does not automatically result in good IAM practices:
–Applications can always come up with mySpecialUserPropertyYouDidNotAnticipateAndIRegardMandatory
–Care is needed in allocating such information as well as the functionality for its maintenance in an overall IT-system

13. 13
Sept. 2014 - All rights reserved
Benefits
▶Improve user experience: facilitate consistent identity and login experience across network applications
▶Foster re-use: externalize the concern of user resp. requestor authentication, re-use its implementation across multiple applications
▶Facilitate agility: introduce new security features e.g. new authentication schemes or adaptive, context-based login without touching each individual application
▶Support new deployment models: applications that internalize initial authentication are tedious to move to the Cloud (here: IaaS, PaaS)
▶Scale application development: the number of development resources who are literate in security/IAM is out-scaled by the number of applications in need of authenticated information for their current requestor

14. 14
Sept. 2014 - All rights reserved
Conclusions
▶Claims-based identity is about the design of applications: it refers to a dependency injection concept for the ‘last mile‘ in authentication systems
▶Claims-based identity is one term for this concept: other solutions trading identity in its post-authentication form may comply with the concept without using this term
▶Claims-based identity is no one-stop-shop: IAM use cases do exist which are not covered by claims-based identity
▶Claims-based identity comes in some flavors: there is no single, one-size-fits- all approach – pull/push modes are to be distinguished
▶Claims-based identity is an unevenly distributed asset: in Java you’ll have to DIY, with .NET most stuff comes included

15. 15
Sept. 2014 - All rights reserved
Author
▶oliver.frank.pfaff@gmail.com