Modern authentication
for the cloud era
Morgan Simonsen
Morgan Simonsen
•
•
•
•
•
•
•
•
•

“Billionaire, playboy, philanthropist, occasional bad boy”
Worked in IT since 1998
Certified MCT, MCSE+Internet, MCSA
MVP Directory Services since 2012
Email: morgan@simonsen.bz
Twitter: @msimonsen
Blog: morgansimonsen.wordpress.com
Blog: www.cloudpower.no
Have met Steve Ballmer!
What I’ll cover
• An introduction to identity, authentication and
authorization
• Claims based identity
• On premise (ADFS)
• Cloud (WAAD)

• Scenarios for claims based identity
• OAuth and OpenID
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
Realities of the cloud
• The Cloud is about the app
• Web apps
• App portability

• The building blocks of the web enable the cloud
•
•
•
•
•

HTTP
SOAP
Web services/Web APIs (open)
Browsers
REST

• Software + service
Anatomy of a cloud app
Internet

Service Provider

Smart phone/tablet App

HTTP Web Service
Web APIs

DB

Other service provider

DB

Web Server

Web Browsers
Traditional authentication mechanisms
• Anonymous

• Not technically client authentication

• Basic

• Part of HTTP 1.0 spec
• Ubiquitous support
• Server knows the username/password

• NTLM/Kerberos (WIA)

• Cannot traverse firewalls or proxies

• Forms based AuthN

• Authentication happens independent of transfer protocol
• Authentication implemented in the application
• Occurs after IIS authentication
Traditional authentication mechanisms
• Anonymous

• Not technically client authentication

• Basic

• Part of HTTP 1.0 spec
• Ubiquitous support
• Server knows the username/password

• NTLM/Kerberos (WIA)

• Cannot traverse firewalls or proxies

• Forms based AuthN

• Authentication happens independent of transfer protocol
• Authentication implemented in the application
• Occurs after IIS authentication
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
How do we solve the problem of
authentication?
“All problems in computer science
can be solved by another level of
indirection.”
David Wheeler
CLAIMS BASED IDENTITY
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
Claims based identity terminology
• Identity Provider (IP): Knows about subjects;
typically a user store (like AD)
• Relying Party (RP): any service that needs to
authenticate and authorize subjects aka.
service provider (web site/service)
• Security Token Service (STS): A web service
that issues tokens (ADFS)
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-*
WS-*
• WS-* tackles all major aspects of
communication:
•
•
•
•

WS-Security
WS-Trust
WS-Addressing
WS-SecurityPolicy
Etc.

• WS-Security has received the most focus…
WS-* and Identity
• WS-Trust
• Defines the STS and the messages used for
requesting, issuing and renewing security tokens

• WS-Federation
• Defines how to use the WS-* protocols to address
specific scenarios like:
• Give access to resources across security realms
• Distributed sign-out
• Etc.
• Synonymous with passive AuthN and AuthZ (browser)
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
Claims based authentication example

Subject
Claims based authentication example

Subject
Policy

Relying party
Claims based authentication example

Subject

1
Policy

Relying party
Claims based authentication example
Identity provider

Policy

STS

Subject

1
Policy

Relying party
Claims based authentication example
Identity provider

2

Policy

STS

Subject

1
Policy

Relying party
Claims based authentication example
Identity provider

2

Policy

3

Subject

Security
Token

STS

1
Policy

Relying party
Claims based authentication example
Identity provider

2

Policy

3

Security
Token

STS

4
Subject

1
Policy

Relying party
Claims based authentication example
Identity provider

2

Policy

5
3

Security
Token

STS

4
Subject

1
Policy

Relying party
WS-* on Windows
• Several products make up the WS-* «stack»
on Windows:
• Active Directory: IP/IdP
• Active Directory Federation Services (ADFS): STS
• Windows Identity Foundation (WIF): Extensions for
ASP.NET (IIS) and WCF to make them RPs

• Windows Azure also includes WIF
How to set up claims based authentication
with ADFS/WIF
1. Enable/install Windows Identity Foundation on
RP
•

WIF fully integrated into .NET as of v4.5

2. Configure RP for outsourced authN
•
•

•

Manually through web.config
Semi-manually through FedUtil.exe
•
Part of the WIF SDK (install it with WebPI)
•
C:Program Files (x86)Windows Identity
Foundation SDKv4.0FedUtil.exe
Visual Studio

3. Configure STS with new RP
Windows Azure AD
• Extension of Active
Directory into the cloud
• The platform for Microsoft
Cloud Apps
• Designed to meet the
needs of cloud
applications, scale an multitenancy
• Provides directory and
identity services: an
essential part of Platform
as a Service
• Your cloud directory for
your apps

Azure
Active Directory

Active Directory
How to set up claims based authentication
with WAAD/WIF
1. Enable/install Windows Identity Foundation on
RP
•

WIF fully integrated into .NET as of v4.5

2. Configure RP for outsourced authN
•
•

•

Manually through web.config
Semi-manually through FedUtil.exe
•
Part of the WIF SDK (install it with WebPI)
•
C:Program Files (x86)Windows Identity
Foundation SDKv4.0FedUtil.exe
Visual Studio

3. Configure WAAD with new RP
Access Control Service (ACS)
• ACS brokers authentication with popular identity
providers
•
•
•
•
•
•

Live ID
Google
Yahoo
Facebook
Windows AD via AD FS
Windows Azure AD

• Your AD FS server can trust ACS to authenticate users
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
3 Types of claims providers in SP claims mode authN
Windows

Forms Based
Auth

SAML
3 Types of claims providers in SP claims mode authN
Forms Based
Auth

Windows

Claim Type

Value

Nameidentifier

Contosogbadea

Primarysid

S-1-5-21-2564101533

Upn

g.badea@contoso.com

Userlogonname

Contosogbadea

IsAuthenticated

True

SAML
3 Types of claims providers in SP claims mode authN
Forms Based
Auth

Windows

Claim Type

Value

Nameidentifier

gbadea

Role

Readers

Role

Authors

Userlogonname

gbadea

IsAuthenticated

True

SAML
3 Types of claims providers in SP claims mode authN
Forms Based
Auth

Windows

Claim Type

Value

Nameidentifier

gbadea

Upn

g.badea@contoso.com

Audience

Sales Managers

Audience

Sales Team

IsAuthenticated

True

SAML
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
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
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
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
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
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

4.

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

Change SP web application to use SAML claims based
AuthN

1.
2.

Enable HTTPS for web application (Central Admin)
Configure permissions
OAUTH AND OPENID
OpenID
• OpenID is an open standard for
authentication
• Uses a similar architecture to WS-*
Relying Party (RP)
• OpenID Provider (OP)
• User-agent

• Identifies users by an URI
• Metadata is a XRDS (Yadis) document
• https://www.google.com/accounts/o8/id
OAuth
OAuth is an open standard for authorization
• Two versions OAuth 1.0 (RFC 5849) and OAuth 2.0 (OAuth
WRAP) (RFC 6749/RFC 6750), which are not compatible
• OAuth provides a method for clients to access server
resources on behalf of a resource owner
•

Access tokens (not security tokens)

•

Most common is the Web Server profile

•

Facebook, Twitter, Microsoft, Yammer, Yahoo!, Tumblr, PayPal, Netflix,
MySpace, Instragram, Google, Foursquare, Dropbox, Amazon

• OAuth defines profiles for various scenarios

• Wide adoption

• OAuth has no signing or encryption
•

It relies only on SSL for opacity
OAuth terminology
• Protected resource: any resource requiring access
restrictions
• Data
• Service

• Resource owner: the owner of protected resources
• Client: an entity that wants to access a protected resource
• Resource server: authorizes requests for protected
resources by processing access tokens
• Authorization server: server that issues authorization
tokens
• Token endpoints
• End user endpoints
OpenID Connect
• Mash up of OpenID and OAuth 2.0
• It is basically OAuth 2.0 with OpenID built in

• OpenID Connect is RESTful and its own API

NIC 2014 Modern Authentication for the Cloud Era

  • 1.
    Modern authentication for thecloud era Morgan Simonsen
  • 2.
    Morgan Simonsen • • • • • • • • • “Billionaire, playboy,philanthropist, occasional bad boy” Worked in IT since 1998 Certified MCT, MCSE+Internet, MCSA MVP Directory Services since 2012 Email: morgan@simonsen.bz Twitter: @msimonsen Blog: morgansimonsen.wordpress.com Blog: www.cloudpower.no Have met Steve Ballmer!
  • 3.
    What I’ll cover •An introduction to identity, authentication and authorization • Claims based identity • On premise (ADFS) • Cloud (WAAD) • Scenarios for claims based identity • OAuth and OpenID
  • 4.
    Terminology • • • • • • Subject: anything thatneeds 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
  • 5.
    Realities of thecloud • The Cloud is about the app • Web apps • App portability • The building blocks of the web enable the cloud • • • • • HTTP SOAP Web services/Web APIs (open) Browsers REST • Software + service
  • 6.
    Anatomy of acloud app Internet Service Provider Smart phone/tablet App HTTP Web Service Web APIs DB Other service provider DB Web Server Web Browsers
  • 7.
    Traditional authentication mechanisms •Anonymous • Not technically client authentication • Basic • Part of HTTP 1.0 spec • Ubiquitous support • Server knows the username/password • NTLM/Kerberos (WIA) • Cannot traverse firewalls or proxies • Forms based AuthN • Authentication happens independent of transfer protocol • Authentication implemented in the application • Occurs after IIS authentication
  • 8.
    Traditional authentication mechanisms •Anonymous • Not technically client authentication • Basic • Part of HTTP 1.0 spec • Ubiquitous support • Server knows the username/password • NTLM/Kerberos (WIA) • Cannot traverse firewalls or proxies • Forms based AuthN • Authentication happens independent of transfer protocol • Authentication implemented in the application • Occurs after IIS authentication
  • 9.
    The problem withauthentication • 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 wesolve the problem of authentication? “All problems in computer science can be solved by another level of indirection.” David Wheeler
  • 11.
  • 12.
    What is claimsbased 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
  • 13.
    Claims based identityterminology • Identity Provider (IP): Knows about subjects; typically a user store (like AD) • Relying Party (RP): any service that needs to authenticate and authorize subjects aka. service provider (web site/service) • Security Token Service (STS): A web service that issues tokens (ADFS)
  • 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-*
  • 15.
    WS-* • WS-* tacklesall major aspects of communication: • • • • WS-Security WS-Trust WS-Addressing WS-SecurityPolicy Etc. • WS-Security has received the most focus…
  • 16.
    WS-* and Identity •WS-Trust • Defines the STS and the messages used for requesting, issuing and renewing security tokens • WS-Federation • Defines how to use the WS-* protocols to address specific scenarios like: • Give access to resources across security realms • Distributed sign-out • Etc. • Synonymous with passive AuthN and AuthZ (browser)
  • 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
  • 18.
  • 19.
    Claims based authenticationexample Subject Policy Relying party
  • 20.
    Claims based authenticationexample Subject 1 Policy Relying party
  • 21.
    Claims based authenticationexample Identity provider Policy STS Subject 1 Policy Relying party
  • 22.
    Claims based authenticationexample Identity provider 2 Policy STS Subject 1 Policy Relying party
  • 23.
    Claims based authenticationexample Identity provider 2 Policy 3 Subject Security Token STS 1 Policy Relying party
  • 24.
    Claims based authenticationexample Identity provider 2 Policy 3 Security Token STS 4 Subject 1 Policy Relying party
  • 25.
    Claims based authenticationexample Identity provider 2 Policy 5 3 Security Token STS 4 Subject 1 Policy Relying party
  • 26.
    WS-* on Windows •Several products make up the WS-* «stack» on Windows: • Active Directory: IP/IdP • Active Directory Federation Services (ADFS): STS • Windows Identity Foundation (WIF): Extensions for ASP.NET (IIS) and WCF to make them RPs • Windows Azure also includes WIF
  • 27.
    How to setup claims based authentication with ADFS/WIF 1. Enable/install Windows Identity Foundation on RP • WIF fully integrated into .NET as of v4.5 2. Configure RP for outsourced authN • • • Manually through web.config Semi-manually through FedUtil.exe • Part of the WIF SDK (install it with WebPI) • C:Program Files (x86)Windows Identity Foundation SDKv4.0FedUtil.exe Visual Studio 3. Configure STS with new RP
  • 28.
    Windows Azure AD •Extension of Active Directory into the cloud • The platform for Microsoft Cloud Apps • Designed to meet the needs of cloud applications, scale an multitenancy • Provides directory and identity services: an essential part of Platform as a Service • Your cloud directory for your apps Azure Active Directory Active Directory
  • 29.
    How to setup claims based authentication with WAAD/WIF 1. Enable/install Windows Identity Foundation on RP • WIF fully integrated into .NET as of v4.5 2. Configure RP for outsourced authN • • • Manually through web.config Semi-manually through FedUtil.exe • Part of the WIF SDK (install it with WebPI) • C:Program Files (x86)Windows Identity Foundation SDKv4.0FedUtil.exe Visual Studio 3. Configure WAAD with new RP
  • 30.
    Access Control Service(ACS) • ACS brokers authentication with popular identity providers • • • • • • Live ID Google Yahoo Facebook Windows AD via AD FS Windows Azure AD • Your AD FS server can trust ACS to authenticate users
  • 31.
    Claims based authenticationin 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
  • 32.
    3 Types ofclaims providers in SP claims mode authN Windows Forms Based Auth SAML
  • 33.
    3 Types ofclaims providers in SP claims mode authN Forms Based Auth Windows Claim Type Value Nameidentifier Contosogbadea Primarysid S-1-5-21-2564101533 Upn g.badea@contoso.com Userlogonname Contosogbadea IsAuthenticated True SAML
  • 34.
    3 Types ofclaims providers in SP claims mode authN Forms Based Auth Windows Claim Type Value Nameidentifier gbadea Role Readers Role Authors Userlogonname gbadea IsAuthenticated True SAML
  • 35.
    3 Types ofclaims providers in SP claims mode authN Forms Based Auth Windows Claim Type Value Nameidentifier gbadea Upn g.badea@contoso.com Audience Sales Managers Audience Sales Team IsAuthenticated True SAML
  • 36.
    How to setup 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 setup 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 setup 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 setup 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 setup 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
  • 41.
    How to setup claims based authentication for SharePoint 2013 with ADFS 1. 2. 3. 4. 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 Change SP web application to use SAML claims based AuthN 1. 2. Enable HTTPS for web application (Central Admin) Configure permissions
  • 42.
  • 43.
    OpenID • OpenID isan open standard for authentication • Uses a similar architecture to WS-* Relying Party (RP) • OpenID Provider (OP) • User-agent • Identifies users by an URI • Metadata is a XRDS (Yadis) document • https://www.google.com/accounts/o8/id
  • 44.
    OAuth OAuth is anopen standard for authorization • Two versions OAuth 1.0 (RFC 5849) and OAuth 2.0 (OAuth WRAP) (RFC 6749/RFC 6750), which are not compatible • OAuth provides a method for clients to access server resources on behalf of a resource owner • Access tokens (not security tokens) • Most common is the Web Server profile • Facebook, Twitter, Microsoft, Yammer, Yahoo!, Tumblr, PayPal, Netflix, MySpace, Instragram, Google, Foursquare, Dropbox, Amazon • OAuth defines profiles for various scenarios • Wide adoption • OAuth has no signing or encryption • It relies only on SSL for opacity
  • 45.
    OAuth terminology • Protectedresource: any resource requiring access restrictions • Data • Service • Resource owner: the owner of protected resources • Client: an entity that wants to access a protected resource • Resource server: authorizes requests for protected resources by processing access tokens • Authorization server: server that issues authorization tokens • Token endpoints • End user endpoints
  • 46.
    OpenID Connect • Mashup of OpenID and OAuth 2.0 • It is basically OAuth 2.0 with OpenID built in • OpenID Connect is RESTful and its own API

Editor's Notes

  • #3 A typicalarchitecture is evolving, muchofwhat I sayabout eg. Claims is transferrable to otherauthN and authZtechnologies
  • #4 Forms basedauthveryimportant!
  • #5 Forms basedauthveryimportant!
  • #6 If youonlydid Windows thatwas OK, but…
  • #7 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
  • #8 Solvesthe problems; outsourced and supports different systemsRemeberthatthiswayofthoughtapplies to eg. OAuth as well
  • #9 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!!
  • #10 SAML/SAML-P
  • #11 a client that is WS-* capable defined as active, whereas one that is not WS-* capable is known as passive.
  • #12 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.
  • #13 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.
  • #14 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.
  • #15 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.
  • #16 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.
  • #17 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.
  • #18 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.
  • #19 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.
  • #20 Show ADFS
  • #21 This is if you’re on Windows of course<microsoft.identityModel><service saveBootstrapTokens ="true">
  • #30 This is if you’re on Windows of course
  • #31 http://sp2010classicmodevsclaimsbased.blogspot.no/
  • #32 http://shojeeb.com/projects/spfedutil/
  • #33 http://shojeeb.com/projects/spfedutil/
  • #34 http://shojeeb.com/projects/spfedutil/
  • #35 http://shojeeb.com/projects/spfedutil/
  • #42 Whenyouallowsomeapp to accessyour Facebook or Twitteraccountsyouareusing OAuthOAuth is not OpenID. OAuth can be used with OpenID, butalsomanyothersThe valetkeyofthe Internet