Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

A typicalarchitecture is evolving, muchofwhat I sayabout eg. Claims is transferrable to otherauthN and authZtechnologies

Forms basedauthveryimportant!

Forms basedauthveryimportant!

If youonlydid Windows thatwas OK, but…

David John Wheeler FRS (9 February 1927 – 13 December 2004) was a computer scientist at the University of Cambridge.What this means is that we need to remove the handling of authentication from application code. Think of the printer driver

Solvesthe problems; outsourced and supports different systemsRemeberthatthiswayofthoughtapplies to eg. OAuth as well

Whatwecollectivelycall“claims-basedidentity”provides that layer of abstraction and helps you avoid the shortcomings of traditional solutions. Claims-based identitymakes it possible tohavetechnologiessuchasWindows Identity Foundation,whichenablesyouto secure systemswithout beingrequired to understandthefinedetailsofthesecuritymechanisms involved.A Kerberos ticket only contains what is defined in Kerberos; SIDs. A token can contain anything. We can send an LDAP attribute as a claim! If not our app would have to query AD for every user. Kvalitetslosen example!!

SAML/SAML-P

a client that is WS-* capable defined as active, whereas one that is not WS-* capable is known as passive.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

The subject wants to access the RP application. It does that via an agent of some sort (a browser, a rich client, and so on). The subject begins by reading the RP policy. In so doing, it learns which identity providers the RP trusts, which kind of claims are required, and which security protocols should be used.The subject chooses one of the IPs that the RP trust and inspects its policy to find out which security protocol is required. Then it sends a request to the IP to issue a token that matches the RP requirements. This process is the equivalent of going to the DOL and asking for a document containing a birth date. In so doing, the subject is required to provide some credentials in order to be recognized by the IP. The details of the protocol used are described in the IP policy.The IP processes the request; if it finds the request to be satisfactory, it retrieves the values of the requested claims, sending them back to the subject in the form of a security token.The subject receives the security token from the IP and sends it together with his first request to the RP application.The RP application examines the incoming token and verifies that it matches all the requirements (coming from one trusted IP, in the expected format, not having been tampered with, containing the right set of claims, and so on). If everything looks as expected, the RP grants access to the subject.

Show ADFS

This is if you’re on Windows of course&lt;microsoft.identityModel&gt;&lt;service saveBootstrapTokens =&quot;true&quot;&gt;

This is if you’re on Windows of course

http://sp2010classicmodevsclaimsbased.blogspot.no/

http://shojeeb.com/projects/spfedutil/

http://shojeeb.com/projects/spfedutil/

http://shojeeb.com/projects/spfedutil/

http://shojeeb.com/projects/spfedutil/

Whenyouallowsomeapp to accessyour Facebook or Twitteraccountsyouareusing OAuthOAuth is not OpenID. OAuth can be used with OpenID, butalsomanyothersThe valetkeyofthe Internet

4.
Terminology
•
•
•
•
•
•
Subject: anything that needs to be identified (authenticated) aka.
principal/user
Authentication (AuthN): The process of establishing
identity, preferably mutual. This requires proof, usually in the form
of credentials.
Authorization (AuthZ): Determining, and granting or denying
access to resources for subject
Impersonation: A service can act as the user while performing an
action on the same server the service is hosted on
Delegation: A service can act as the user while performing an
action hosted on another server
Profile store: Service/app profile information with an immutable
ID for each subject

9.
The problem with authentication
• Current technologies do not work well on the
Internet (NTLM, Kerberos etc.)
• Basic is the only authentication mechanism that was
part of HTTP (1.0), all the others are bolted on
• Several and different user stores (AD, LDAP, eDir)
• Relies on your particular platform
• Authentication had to be handled and understood
by the developers whose time is better spent
developing the application
• Each new authentication scheme required
changing the code

10.
How do we solve the problem of
authentication?
“All problems in computer science
can be solved by another level of
indirection.”
David Wheeler

12.
What is claims based identity?
•
•
•
Abstraction layer (indirection)
A claim is an authoritative statement about a subject made by an entity
A claim can be anything (not just security information) that can be associated with a
subject
•
•
•
•
•
•
•
•
XML or binary fragments constructed according to some security standard
Digitally signed
•
•
•
•
•
•
Name
Age
Group membership
Role
SAML (Security Assertion Markup Language)
JWT (JSON Web Token)
SWT (Simple Web Token)
•
Usually implemented with digital certificates
A claim is always associated with the entity that issued it
There are several claim standards
Claims are stored and transmitted in security tokens
There are several token formats
Claims based identity requires a trust model

14.
History sidebar
• 1995-2000: The widespread adoption of the
Internet brought with it increasingly distributed
and connected systems. Communicating across
silos became more and more difficult.
• 2001: Key industry players started the
development of a set of communication protocols
and languages to ensure easy interoperability
across platforms. The result was a set of
protocols and languages based on the Simple
Object Access Protocol (SOAP) Web
services, known collectively as WS-*

17.
Policy and metadata
• Web Services usually have service
descriptions
• These come in the form of machine-readable
documents (typically XML)
• They establish requirements and intended
usage up front
• In WS-* this is know as federation metadata

31.
Claims based authentication in
SharePoint 2013
• SP 2013 has its own STS implementation
• The SP 2013 Federation Metadata is in JSON, not
XML
• Both Classic authentication mode (WIA) and
claims mode (WIA/FBA/SAML) is supported, but
claims mode is the default
• In claims mode every form of AuthN is
transformed to a SAML token

36.
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.
Make sure SP is in claims based AuthN mode
•
Default setting for SP 2013
Configure ADFS with SP as a new RP and configure claims
Configure SP to trust ADFS as an IP
1.
Import the entire ADFS token signing cert chain into SP
•
SP has its own certificate stores
2. Add claim mappings
3. Add authentication provider

37.
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.
Make sure SP is in claims based AuthN mode
•
Default setting for SP 2013
Configure ADFS with SP as a new RP and configure claims
Configure SP to trust ADFS as an IP
1.
Import the entire ADFS token signing cert chain into SP
•
SP has its own certificate stores
2. Add claim mappings
3. Add authentication provider

38.
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.
Make sure SP is in claims based AuthN mode
•
Default setting for SP 2013
Configure ADFS with SP as a new RP and configure claims
Configure SP to trust ADFS as an IP
1.
Import the entire ADFS token signing cert chain into SP
•
SP has its own certificate stores
2. Add claim mappings
3. Add authentication provider

39.
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.
Make sure SP is in claims based AuthN mode
•
Default setting for SP 2013
Configure ADFS with SP as a new RP and configure claims
Configure SP to trust ADFS as an IP
1.
Import the entire ADFS token signing cert chain into SP
•
SP has its own certificate stores
2. Add claim mappings
3. Add authentication provider

40.
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.
Make sure SP is in claims based AuthN mode
•
Default setting for SP 2013
Configure ADFS with SP as a new RP and configure claims
Configure SP to trust ADFS as an IP
1.
Import the entire ADFS token signing cert chain into SP
•
SP has its own certificate stores
2. Add claim mappings
3. Add authentication provider