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

“Billionaire, playboy, philanthropist, occasional bad boy”
Worked in IT since 1998
Cert...
What I’ll cover
• An introduction to identity, authentication and
authorization
• Claims based identity
• On premise (ADFS...
Terminology
•
•
•
•

•
•

Subject: anything that needs to be identified (authenticated) aka.
principal/user
Authentication...
Realities of the cloud
• The Cloud is about the app
• Web apps
• App portability

• The building blocks of the web enable ...
Anatomy of a cloud app
Internet

Service Provider

Smart phone/tablet App

HTTP Web Service
Web APIs

DB

Other service pr...
Traditional authentication mechanisms
• Anonymous

• Not technically client authentication

• Basic

• Part of HTTP 1.0 sp...
Traditional authentication mechanisms
• Anonymous

• Not technically client authentication

• Basic

• Part of HTTP 1.0 sp...
The problem with authentication
• Current technologies do not work well on the
Internet (NTLM, Kerberos etc.)

• Basic is ...
How do we solve the problem of
authentication?
“All problems in computer science
can be solved by another level of
indirec...
CLAIMS BASED IDENTITY
What is claims based identity?
•
•
•

Abstraction layer (indirection)
A claim is an authoritative statement about a subjec...
Claims based identity terminology
• Identity Provider (IP): Knows about subjects;
typically a user store (like AD)
• Relyi...
History sidebar
• 1995-2000: The widespread adoption of the
Internet brought with it increasingly distributed
and connecte...
WS-*
• WS-* tackles all major aspects of
communication:
•
•
•
•

WS-Security
WS-Trust
WS-Addressing
WS-SecurityPolicy
Etc....
WS-* and Identity
• WS-Trust
• Defines the STS and the messages used for
requesting, issuing and renewing security tokens
...
Policy and metadata
• Web Services usually have service
descriptions
• These come in the form of machine-readable
document...
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 par...
Claims based authentication example
Identity provider

2

Policy

5
3

Security
Token

STS

4
Subject

1
Policy

Relying p...
WS-* on Windows
• Several products make up the WS-* «stack»
on Windows:
• Active Directory: IP/IdP
• Active Directory Fede...
How to set up claims based authentication
with ADFS/WIF
1. Enable/install Windows Identity Foundation on
RP
•

WIF fully i...
Windows Azure AD
• Extension of Active
Directory into the cloud
• The platform for Microsoft
Cloud Apps
• Designed to meet...
How to set up claims based authentication
with WAAD/WIF
1. Enable/install Windows Identity Foundation on
RP
•

WIF fully i...
Access Control Service (ACS)
• ACS brokers authentication with popular identity
providers
•
•
•
•
•
•

Live ID
Google
Yaho...
Claims based authentication in
SharePoint 2013
• SP 2013 has its own STS implementation
• The SP 2013 Federation Metadata ...
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

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

Windows

Claim Type

Value

Nameidentifier

gbadea

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

Windows

Claim Type

Value

Nameidentifier

gbadea

...
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

Make sure SP is in claims based AuthN mo...
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

Make sure SP is in claims based AuthN mo...
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

Make sure SP is in claims based AuthN mo...
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

Make sure SP is in claims based AuthN mo...
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

Make sure SP is in claims based AuthN mo...
How to set up claims based authentication
for SharePoint 2013 with ADFS
1.
2.
3.

4.

Make sure SP is in claims based Auth...
OAUTH AND OPENID
OpenID
• OpenID is an open standard for
authentication
• Uses a similar architecture to WS-*
Relying Party (RP)
• OpenID P...
OAuth
OAuth is an open standard for authorization
• Two versions OAuth 1.0 (RFC 5849) and OAuth 2.0 (OAuth
WRAP) (RFC 6749...
OAuth terminology
• Protected resource: any resource requiring access
restrictions
• Data
• Service

• Resource owner: the...
OpenID Connect
• Mash up of OpenID and OAuth 2.0
• It is basically OAuth 2.0 with OpenID built in

• OpenID Connect is RES...
Upcoming SlideShare
Loading in …5
×

NIC 2014 Modern Authentication for the Cloud Era

908 views
634 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
908
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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<microsoft.identityModel><service saveBootstrapTokens ="true">
  • 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
  • NIC 2014 Modern Authentication for the Cloud Era

    1. 1. Modern authentication for the cloud era Morgan Simonsen
    2. 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. 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. 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
    5. 5. 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
    6. 6. 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
    7. 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. 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. 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. 10. How do we solve the problem of authentication? “All problems in computer science can be solved by another level of indirection.” David Wheeler
    11. 11. CLAIMS BASED IDENTITY
    12. 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
    13. 13. 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)
    14. 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. 15. WS-* • WS-* tackles all major aspects of communication: • • • • WS-Security WS-Trust WS-Addressing WS-SecurityPolicy Etc. • WS-Security has received the most focus…
    16. 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. 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. 18. Claims based authentication example Subject
    19. 19. Claims based authentication example Subject Policy Relying party
    20. 20. Claims based authentication example Subject 1 Policy Relying party
    21. 21. Claims based authentication example Identity provider Policy STS Subject 1 Policy Relying party
    22. 22. Claims based authentication example Identity provider 2 Policy STS Subject 1 Policy Relying party
    23. 23. Claims based authentication example Identity provider 2 Policy 3 Subject Security Token STS 1 Policy Relying party
    24. 24. Claims based authentication example Identity provider 2 Policy 3 Security Token STS 4 Subject 1 Policy Relying party
    25. 25. Claims based authentication example Identity provider 2 Policy 5 3 Security Token STS 4 Subject 1 Policy Relying party
    26. 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. 27. 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
    28. 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. 29. 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
    30. 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. 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
    32. 32. 3 Types of claims providers in SP claims mode authN Windows Forms Based Auth SAML
    33. 33. 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
    34. 34. 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
    35. 35. 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
    36. 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. 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. 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. 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. 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
    41. 41. 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
    42. 42. OAUTH AND OPENID
    43. 43. 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
    44. 44. 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
    45. 45. 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
    46. 46. 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

    ×