CIS13: Taking the Hyperspace Bypass: Controlling User Access to Other Worlds

1,245 views
977 views

Published on

Dale Olds, Senior Staff Engineer, VMware
If identity is the new perimeter, then users must be able to access applications anywhere: on premise, in the cloud or on partner sites. To enable this access we must take identity information into other worlds, and there is no Babel Fish. This session will explain how to enable access to distributed applications without making users feel like Marvin the Paranoid Android. We will cover topics like federated authentication, browser single sign-on and delegated authorization for cloud APIs. Standards in this area are essential, but SAML, OAuth2, SCIM and OpenID can sound like Vogon poetry. We'll touch on the standards, but keep the Vogon poetry to a minimum.

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
1,245
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CIS13: Taking the Hyperspace Bypass: Controlling User Access to Other Worlds

  1. 1. © 2010 VMware Inc. All rights reserved The Hitchhiker's Guide To Identity Taking the Hyperspace Bypass: Controlling User Access to Other Worlds Dale Olds, Sr. Staff Engineer, VMware Horizon Workspace Cloud Identity Summit, July 2013
  2. 2. Agenda l Crossing boundaries with identity information l Single sign-on and federated authentication l Provisioning user information across borders l Delegated authorization for distributed applications l Standards and Vogon poetry
  3. 3. Crossing Boundaries with Identity Information
  4. 4. The limits of embedded accounts and shared directory services It's a people problem l One account per application is killing us all – too many damn passwords l Initially easier for developers, but ultimately impossible for users as applications proliferate l Username and password is easy, change is hard. It's a management problem l Management domains (organizations) have different needs and control l Multiple apps can share a directory service such as Active Directory, but generally only within a management domain l The larger the management domain to more political and difficult to change – schema becomes concrete The solution is to enable the controlled transfer of identity information across management domains.
  5. 5. Think Facebook Connect. In the last few years Facebook may have accomplished more to promote the common understanding of federated identity than all the major enterprise vendors have in the last 20. Users now think of accounts as independent from applications. I have an account at Facebook. I can use it at other places.
  6. 6. Single Sign-on and Federated Authentication
  7. 7. Federated authentication Authentication is the act of confirming the truth of an attribute of a datum or entity... often involves verifying the validity of at least one form of identification. (wikipedia) Let's try that again. For our purposes: Authentication is the act of determining who is making a request. For apps with embedded user accounts, often called login. Using Federated Authentication, an app trusts an identity provider to authenticate the user. The app gets the user's identity information from the provider, but is not involved in the act of authentication. The identity provider may be in another management domain. This is not like multiple apps sharing a directory service, where the apps authenticate users independently using common data. SAML and OpenID Connect are protocols for federated authentication
  8. 8. Browser redirects New Documents Site Old Documents Site browser 1. Get me the Burning Man Survival Guide. 2. Document has moved, here is the new name and location. 3. Get me the new document. The vast majority of all federated authentication systems, including all versions of SAML, OpenID, and OAuth use browser redirects to separate the act of authentication from an app.
  9. 9. Federated authentication – solved for web applications sparklr photo sharing appfacespace identity provider (idp) browser printr photo printing app editr photo editing app 1. Joe starts at sparklr but he's not logged in, gets redirected to idp.2. Joe logs in with method known only to idp. Idp saves session with Joe, redirects back to sparklr with signed token that this is Joe. 3. Sparklr trusts token from idp, sets up session with Joe and grants access. 4. When joe accesses printr or editr, they redirect him to the idp – which already has a session with Joe so he is immediately redirected back with a token. Single Sign-on!
  10. 10. Advantages of federated authentication l Since an identity provider can authenticate users for many apps, there should be fewer (but more secure) authentication sources. l Identity providers can add better authentication methods with no change to connected applications l Major identity providers are already adding multifactor, continuous authentication – trending toward recognition. l Incentives are to let a few identity providers handle authentication, and web applications focus on features. l Consider the Gawker and LivingSocial crack. . If you connect to LivingSocial using Facebook Connect, your Facebook credentials were not compromised. Tim O’Shaughnessy, CEO of LivingSocial
  11. 11. Federated authentication – solved for web applications? Unfortunately solutions are a primary cause of problems (and there are some problems with this solution)
  12. 12. Federated authentication for web apps: downsides fake idp facespace identity provider (idp) browser printr photo printing app editr photo editing app Privacy concerns: the idp knows every site that joe accesses with this account. Other systems have been proposed, but involve significant changes and trust of the user's machine (see information cards, browserID). Phishing concerns: if sparklr is evil it could redirect to fake idp, which reads the real idps ui, presents it to the user and steals their credentials The problem with logout: what does it actually mean? Users are confused... if I logout of the app, I'm still logged in at the idp which gives me SSO with the app? If I log out of the idp, what should that mean for the apps? sparklr evil photo sharing app What about non-browser apps? I've heard that mobile apps may be important.
  13. 13. Federated authentication – the future SAML, OpenID Connect (with OAuth2) useful now for many use cases. We've made great progress, but there are many unresolved issues. Technological evolution and cultural change must continue. Work on OpenID Connect extensions for federated authentication for mobile applications is underway (see the AZA workshop). Advances in continuous authentication and recognition make authentication more convenient and more secure. Preventing phishing will be a longer, multi-component issue. Help from browsers is important and users may need to learn new expectations when interacting with sites.
  14. 14. Provisioning User Information across Borders
  15. 15. Provisioning Old fashioned provisioning: just get the sysadmins to copy the identity information across boundaries! Common questions: l If we have effective provisioning, do we need federated authentication? l If we have federated authentication, do we need provisioning? Classic, push, apriori, static provisioning l pros: forward references, less change, supports deprovisioning l cons: proliferates copies of identity information, hard to update, authentication issues Just in time (JIT) provisioning l pros: only create accounts when needed, no provisioning protocol or APIs needed (side effect of authentication). l cons: no forward references, no deprovisioning Provisioning standards: LDAP, SPML, SCIM
  16. 16. Delegated Authorization for Distributed Applications
  17. 17. Federated authentication: protecting the front door Federated authentication controls how users gain access to an app. This is like controlling who can come into the front door of a store.
  18. 18. But the loading dock is open... Modern apps aggregate information from other services, we need to control access to those services are well. Who's protecting the loading dock?
  19. 19. A modern web or cloud app uses external services sparklr photo sharing app facespace identity provider (idp) browser photo printing service map data service Joe needs to delegate authorization such that sparklr can access the services on his behalf. Enter OAuth2 photo storage service distributed app
  20. 20. But first, let's talk about what happens when selling a car
  21. 21. Illustration: selling a car Bank Sam Joe, used car broker Me, selling a rusty 2000 nissan pathfinder 1. Sam tells Joe he'll take the pathfinder. Joe replies that he'll need a cashiers check for the purchase price. 2. Sam authenticates and gets a cashier's check. 3. Sam gives the check (signed by the bank) to joe. 4. Joe gives the check to me in exchange for the car. I don't really care who Joe and Sam are, the check authorizes the transaction and it's guaranteed by the bank.
  22. 22. l issuing bank l check number l account and name l authorized amount l issued at date l expiration date l recipient l authorized signature Contents of a cashier's check
  23. 23. authorization server (bank) resource owner (user) client application (joe broker) resource server (me with pathfinder) 1. user accesses application but is not authorized. Application redirects user to the authorization server with instructions of what authorization to request. 2. user authenticates and approves release of token containing proof of authorization. 3. user is redirected back to the client app which gets the token. 4. client app presents token to resource server to authorize access to the resource. Same transaction in OAuth2 terms
  24. 24. l JWT is an IETF specification (pronounced 'jot') l Three parts: header, content, signature l While commonly used with OAuth2, OAuth2 does not require JWTs. l OpenID Connect does require JWTs for id_token Sample token content, with corresponding cashier's check fields: jwt meaning cashier's check JSON web token (JWT) – a check format for the web * commonly used, but not specified in JWT or Openid connect iss issuer issuing bank jti token ID check number sub subject account & name iat issued at issued at date exp expiration expiration date aud audience recipient azp OIDC authorized party *scope authorization authorized amount signatur e third part of the token authorized signature
  25. 25. authorization server resource owner via user agent (browser) client application resource server 1. user accesses application but is not authorized. application redirects user to the authorization server to request authorization. 2. user authenticates and approves release of token containing proof of authorization. 3. user is redirected back to the client app with an access token in location fragment 4. client app presents access token to resource server to authorize access. client app can use access token until it expires. l access token is exposed to user's agent. l access token lifetime is longest interval user cannot revoke access. l client id, redirect urls must be registered – no secret l generally a less secure and less convenient grant – avoid if possible Implicit grant
  26. 26. authorization server resource owner via user agent (browser) client application resource server 1. user accesses application but is not authorized. application redirects user to the authorization server to request authorization. 2. user authenticates and approves release of token containing proof of authorization. 3. user is redirected back to the client app with an authorization code. 5. client app presents access token to resource server to authorize access. client app can use refresh token to request new access token on expiration. 4. client redeems authorization code for access and refresh tokens. l access and refresh tokens aren't exposed to user's agent. l access token lifetime is longest interval user cannot revoke access. l refresh token lifetime is interval before user has to re-authenticate. l client id, secret, redirect urls must be registered Authorization code and refresh token grants
  27. 27. authorization server resource owner via native app resource server 1. user accesses cloud controller but is not authorized. application gets username and password 2. app posts user credentials to authenticate user and autoapprove release of token containing proof of authorization, requests password grant. 3. returns to the app with an access token and a refresh token 4. app presents access token to resource server to authorize access. app can use access token until it expires, but can get a new access token with the refresh token l access and refresh tokens are exposed to the user's machine. l access token lifetime is longest interval user cannot revoke access. l limited to user name and password. Resource owner password grant from native app
  28. 28. authorization server client application resource server 2. client app presents access token to resource server to authorize access. 1. client authenticates and gets an access token with all its registered authorizations. l access token cannot be revoked for it's lifetime. l client id, secret must be registered Client credentials grant
  29. 29. Standards and Vogon poetry
  30. 30. Standards landscape: federated authentication While Craig's statement was entertaining, my team respectfully disagrees. We continue to implement SAML because our business is to support valid customer use cases. For us, SAML isn't dead, it's done. It's complete. We can safely implement it. OpenID Connect is very promising. It's not dead, but it's not done. l OpenID Connect has been baking for over 3 years l It is implementable, useful now and fairly stable. l Combines very well with OAuth2 (delegated authorization) and SCIM (provisioning) for a mostly complete identity system. “There is no future for SAML. No one is putting money into SAML development. NO ONE is writing new SAML code. SAML is dead.” Craig Burton, CIS 2012
  31. 31. Standards landscape: provisioning and delegated authorization Provisioning l My bet is on the Simple Cloud Identity Management (SCIM 1.1) protocol produced by a group of interested individuals. l And my bet is on the IETF's System for Cross-domain Identity Management (SCIM 2.0) protocol. l SCIM 1.1 is implementable, stable, and combines well with OAuth2 l SCIM 2.0 is the first IETF spec and has been in development for just over a year. Delegated Authorization l OAuth2 rules and is becoming a family of specifications. l Personally, I like to use it with JWT – which is also becoming a family of specifications.
  32. 32. Questions?

×