Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a NIC 2014 Modern Authentication for the Cloud Era
Semelhante a NIC 2014 Modern Authentication for the Cloud Era (20)
Mais de Morgan Simonsen
Mais de Morgan Simonsen (15)
Último
Último (20)
NIC 2014 Modern Authentication for the Cloud Era
- 1. Modern authentication for the cloud 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 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. 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. 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. 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 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
- 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. 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-* tackles all 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. Claims based authentication example Subject
- 19. Claims based authentication example Subject Policy Relying party
- 20. Claims based authentication example Subject 1 Policy Relying party
- 21. Claims based authentication example Identity provider Policy STS Subject 1 Policy Relying party
- 22. Claims based authentication example Identity provider 2 Policy STS Subject 1 Policy Relying party
- 23. Claims based authentication example Identity provider 2 Policy 3 Subject Security Token STS 1 Policy Relying party
- 24. Claims based authentication example Identity provider 2 Policy 3 Security Token STS 4 Subject 1 Policy Relying party
- 25. Claims based authentication example 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 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. 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 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. 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 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. 3 Types of claims providers in SP claims mode authN Windows Forms Based Auth SAML
- 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. 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. 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. 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
- 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. OAUTH AND OPENID
- 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. 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. 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. 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
Notas do Editor
- 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