Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Identity as a Matter of Public Safety
A Case Stu...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Who We Are
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
The Problem
Lots of Applications,
exposing Lots ...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Our Architecture
SIP
proxy
MSI
server
SIP
client...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
So Let’s take a step back …
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Get apps & APIs out of the password business …
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
… and into the token consumption business.
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Now we can distill our complex problem into 3 si...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
So Something Like This …
1.  Ask for a token
2. ...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Why Tokenizing APIs is Good
•  And why you shoul...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
The BIG question
Keeping in mind the requirement...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
We Looked at Kerberos
• (because it’s enterprise...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
So we set our eyes on SAML
• (because unlike Ker...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
What about WS-Trust?
• It is a standard way to g...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
And then there was OAuth …
•  OAuth is to REST A...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
The OAuth Access Token
•  OAuth doesn’t actually...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Hitting the Pause Button
OAuth is for Authorizat...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
OAuth is for Authorization, not Authentication!
...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
And the end user is the resource owner, right?
•...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
With that settled, time to flesh out the details...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Session Management
•  Exchanging a password for ...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
The SSO client
Identity
Server
App client 1 App ...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
But … How?
1.  HTTP cookies
•  Not secure
•  No ...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Session Mgmt Illustrated!
OAuthSSO clientUA
1. A...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Putting the token to work
•  New and Shiny RESTf...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Putting it all together …
OAuth AS WS-* STS
WS-*...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Tokens can be carried in SIP + RTSP just as well...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
So OAuth works well within a single security dom...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
… But what about accessing APIs across security ...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
A token that Travels: Taking OAuth on the Road
W...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
There are a number of options …
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Federated Authorization Server
Active Directory
...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
OAuth Assertion Profile
Resource
Server
STS
Reso...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
Federated authentication to Authorization Server...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
My Thoughts for the Identity Community ahead …
•...
IdentityasaMatterofPublicSafety
Cloud Identity Summit 2013 – API Workshop
And in Closing …
• Questions?
• Comments?
• Scru...
Upcoming SlideShare
Loading in …5
×

CIS13: Identity as a Matter of Public Safety: A Case Study in Secure API Access and SSO Across Security Domains

1,777 views

Published on

Adam Lewis, Office of the CTO, Motorola
RESTful APIs, WS-* / SOAP APIs, Proprietary APIs, protocols beyond APIs, OAuth for Authentication, Federated Authorization Servers across security domains, Token Translation between SAML and JWT, SSO across native applications, all running across Windows desktops and Android mobile computing platforms… and the glue to tie all that together? Are you kidding? Tune-in to this technical chat on a real-life case study of a small but dedicated band of engineers’ attempts to harmonize identity in a very un-harmonized world.

Published in: Technology
  • Be the first to comment

CIS13: Identity as a Matter of Public Safety: A Case Study in Secure API Access and SSO Across Security Domains

  1. 1. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Identity as a Matter of Public Safety A Case Study in Secure API Access and SSO Across Security Domains
  2. 2. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Who We Are
  3. 3. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop The Problem Lots of Applications, exposing Lots of APIs … Running on different servers … Communicating with clients on different computing devices … Lots of Passwords! ☹
  4. 4. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Our Architecture SIP proxy MSI server SIP client(s) MSI client WS-* STS WS-* server RTSP server RTSP client RESTful server RESTful client SIP registrar SIP server(s) Proprietary WS-Trust / SAML HTTP / RESTRTSPSIP Web Browser Web Server HTTP / WebSSO User Directory Identity Server AD LDAP client LDAP server LDAP bind w/password LDAP “relay” WS-* client Domain 2 (State or Regional IT) Domain 1 – Local Police Dept. Enterprise IT network Domain 3 WS-* client WS-* server WS-Trust Native & Web Apps Running on Android / Windows / iOS mobile LTE device Mounted in Trunk of Police Car Domain X – User might be a part of either domain 1 or 2 or 3 (or other)
  5. 5. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop So Let’s take a step back …
  6. 6. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Get apps & APIs out of the password business …
  7. 7. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop … and into the token consumption business.
  8. 8. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Now we can distill our complex problem into 3 simple steps … 1.  App client asks for a token 2.  App client sends token to App server 3.  App server consumes token API Client API ServerToken Server
  9. 9. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop So Something Like This … 1.  Ask for a token 2.  Receive the token 3.  Use the token Identity Token Issuer App.1 App.2 App.3 User Directory Authenticate with local credentials Ask for Identity token Use the Identity token Receive the Token
  10. 10. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Why Tokenizing APIs is Good •  And why you should want to tokenize yours … •  SSO •  Centralized Provisioning of credentials •  Better Security & Migration to Strong Authentication •  Federation
  11. 11. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop The BIG question Keeping in mind the requirements •  Native desktop clients •  Native clients running on Mobile computing platforms (iOS, Android, Win) •  Linux, Unix, Windows servers •  Must be able to send token across security domains •  Leverage industry dominant, open standards How does the API client get the Token ???
  12. 12. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop We Looked at Kerberos • (because it’s enterprise friendly) •  But it doesn’t cross security domains well •  And is tied to AD – and we want to be agnostic to the credential server (can’t dictate what customers use)
  13. 13. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop So we set our eyes on SAML • (because unlike Kerberos, it federates well) •  But SAML is really designed for WebSSO – uses lots of HTTP redirects – not the best fit for APIs
  14. 14. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop What about WS-Trust? • It is a standard way to get tokens for API access for SOAP-based web services • And the token type is SAML – which federates! • It’s actually not a bad idea in theory … … Except that in practice, we don’t see too many people deploying WS-* on Android/iOS (and we want to leverage industry trends)
  15. 15. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop And then there was OAuth … •  OAuth is to REST APIs what WS-Trust is to SOAP APIs •  A way to exchange a primary credential for a token, and a way to pass that token to the API provider •  And it’s mobile friendly •  And it’s shiny and new •  And it seems that everybody in the world is deploying it •  Google, Twitter, Facebook, Salesforce, etc. •  And we’re looking to leverage trends
  16. 16. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop The OAuth Access Token •  OAuth doesn’t actually define what the access token looks like •  Depending on who you ask, this is a good thing (or not) •  Advocates claim it provides flexibility •  Detractors say it hinders interoperability •  Regardless, it needs to be defined •  Several choices come to mind •  Unstructured •  Structured •  SAML •  JSON Web Token (JWT) Development teams were emphatical, they wanted to be able to validate the token WITHOUT having to call back to an introspection endpoint! JSON friendlier to development than XML – size more compact for RESTful APIs
  17. 17. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Hitting the Pause Button OAuth is for Authorization, not Authentication! And the end user is the resource owner, right? And besides, OAuth was designed for the social web, does it even have a place in the Enterprise?
  18. 18. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop OAuth is for Authorization, not Authentication! { "iss": "https://server.example.com", "sub": "alice@example.com", "aud": "https://protectedresource1.example.com", "azp": "mynativeapp.s6BhdRkqt3" "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "auth_time": 1311280969, "acr": “LOA4", } Q: Is this an OpenID Connect id_token, or an OAuth access_token? A: it’s an OAuth access_token, profiled to look like an OpenID Connect id_token, to enable OAuth- based authentication Not necessarily … OAuth CAN be used for API authentication (if profiled right)
  19. 19. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop And the end user is the resource owner, right? •  Classic “social” OAuth use case: •  Alice authorizes a third party client to access her protected resources •  But in the Enterprise world, resources, applications and services are owned by the enterprise, NOT the employee •  This is easily addressed … •  End user authenticates to the OAuth AS using enterprise-provisioned credentials … but the END USER DOES NOT AUTHORIZE ANYTHING •  OAuth AS issues an access token IDENTIFYING the end user (user id, method of authentication, time of authentication, etc.) •  Access token is presented to API servers where user is mapped to roles according to business logic, localized authorization is performed •  Alternatively, the OAuth AS could act as an enforcement point for coarse- grain authorization
  20. 20. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop With that settled, time to flesh out the details …
  21. 21. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Session Management •  Exchanging a password for a token is easy … •  But what about when you want a second token? •  Does the user have to provide their password again? •  Doesn’t that break SSO? •  So tokens alone don’t provide us with TRUE SSO •  Something MORE is needed: •  How can the Token server recognize that a user has already been authenticated across token requests, such that the user does NOT have to enter their password again (and again, and again)? •  The answer: SSO Client •  Manages the session with Token Server •  Expose simple API to native app clients •  Abstracts complexity of SSO protocol from app clients (much like Google Play) •  getToken()
  22. 22. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop The SSO client Identity Server App client 1 App client 2 App client 3 What is your name & password? What is your name & password? What is your name & password? App client 1 App client 2 App client 3 SSO client Identity Server Identity Protocol Identity Protocol Identity Protocol Identity Protocol API API API Without SSO client, each app will need to know protocol details and SSO is not possible SSO client – Identity Protocol complexity is hidden from app clients; SSO client manage session with Identity Server hence enabling Single Sign-On What is your name & password? (only ask ONCE)
  23. 23. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop But … How? 1.  HTTP cookies •  Not secure •  No way to revoke if device is compromised •  This is a non-starter! 2.  OAuth Refresh Tokens •  Could ask for a “master token” with all possible scopes, then use refresh token to “down-scope” the master token for individual scopes •  Master token can be used as the session token, is revocable (good!) •  But it requires tight coupling between SSO client, native apps; must know all scopes of all native apps a priori •  And it gets worse … some native apps might trigger strong authentication, even when the user doesn’t want it (bad experience) •  (So we keep looking) 3.  OAuth Assertion Grants •  Assertion profiles defined in the OAuth WG allow SAML or JWT assertion to be used as a grant type to obtain access tokens •  Enterprise friendly! •  No coupling between native app clients, SSO client •  Best standard ways to get SAML or JWT assertions are WS-Trust (SAML) or via OpenID Connect (JWT): get the JWT assertion, and then use JWT assertion to request scoped access tokens
  24. 24. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Session Mgmt Illustrated! OAuthSSO clientUA 1. Authorization Request (scope=openid, azp=SSOclient, aud=token_server) 4. Authorization Response (code) 6. Access Token Response (OIDC id_token) 7. Access Token Request (grant_type=jwt-bearer, id_token, scope=app.1) 2. HTML form requesting primary credentials What is your username & password? 8. Access Token Request (grant_type=jwt-bearer, id_token, scope=app.2) 9. Access Token Request (grant_type=jwt-bearer, id_token, scope=app.3) Use the JWT assertion as a grant to request API-scoped access_tokens … (sort of like a Kerberos TGT!) 3. HTML form submission Primary authentication & validation of primary credentials 5. Access Token Request (code, grant_type=code) Native Authorization Agent (AZA) https://groups.google.com/forum/#! forum/native-authorization-agent Note that client doesn’t actually see the password, the entire authentication process is transparent to the client!
  25. 25. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Putting the token to work •  New and Shiny RESTful APIs •  Legacy WS-* APIs •  Other •  Proprietary APIs •  SIP •  RTSP
  26. 26. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Putting it all together … OAuth AS WS-* STS WS-* API server 1. getToken() 2. Token Request (scope=App.1, grant_type=jwt-bearer) 3. JWT-structured OAuth access_token with scope=App.1 4. getToken (JWT-structured OAuth access_token) 5. RESTful API call (JWT-structured OAuth access_token) 6. getToken() 7. Token Request (scope=App.2, grant_type=jwt-bearer) 8. JWT-structured OAuth access_token 9. getToken (JWT-structured OAuth access_token) 10. WS-* RST (JWT-structured OAuth access_token) RESTful API server 11. WS-* RSTR (WS-* SAML assertion) 12. WS-* API call (SAML assertion) Make authorization / access control decision based on Identity asserted in token Claims communicated in token: user identity, possible roles, time of authentication, method of authentication User launches WS-* app WS-* App2 RESTful App1 SSO client User launches RESTful app OAuth-to-WS* token Translation happens here
  27. 27. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Tokens can be carried in SIP + RTSP just as well Identity Server RTSP server 1. getToken() 2. Token Request (scope=SIP.1, grant_type=jwt-bearer) 3. JWT-structured OAuth access_token with scope=SIP.1 4. getToken (JWT-structured OAuth access_token) 5. SIP message (JWT-structured OAuth access_token) 6. getToken() 7. Token Request (scope=RTSP.2, grant_type=jwt-bearer) 8. JWT-structured OAuth access_token with scope=RTSP.2 9. getToken (JWT-structured OAuth access_token) SIP server 10. RTSP message (JWT-structured OAuth access_token) User launches RTSP app RTSP app SIP app SSO client User launches SIP app OAuth token carried in SIP header OAuth token carried in RTSP header
  28. 28. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop So OAuth works well within a single security domain … OAuth AS RESTful API WS-* API Other APIs and Protocols SSO client Active Directory Authenticate with primary credentials Get OAuth access-token Use the OAuth access-token
  29. 29. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop … But what about accessing APIs across security domains?
  30. 30. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop A token that Travels: Taking OAuth on the Road What happens when the user of the API is part of security domain 1, but the provider of the API is part of security domain 2? Application APIs may be hosted in security domain different from the end-user •  Enterprise user accesses SaaS/cloud API •  Enterprise user access API exposed by a partner Enterprise •  City employee accesses API exposed by the State •  State employee accesses API exposed by the Federal Gov •  Google+ user accesses Facebook API What does this look like?
  31. 31. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop There are a number of options …
  32. 32. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Federated Authorization Server Active Directory OAuth AS Home Foreign Resource Server Foreign Resource Server Foreign Resource Server password JWT JWT JWT
  33. 33. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop OAuth Assertion Profile Resource Server STS Resource Server STS Active Directory Home STS password JWT JWT Foreign Resource Server STS Foreign Foreign JWT
  34. 34. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Federated authentication to Authorization Server Active Directory Home Resource Server STS Resource Server STS Resource Server STS SAML IdP password SAML SAML SAML
  35. 35. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop My Thoughts for the Identity Community ahead … •  An IETF informational RFC on usage of OAuth for Enterprise-style authentication would be nice •  Clear up some of the confusion of “it’s for authorization” and “the RO is the end-user” •  Looking forward to the AZA effort gaining traction •  JOSE … slow movement in the IETF JOSE WG is causing doubt •  Looking to the IETF to seal the deal on this and call it a day! •  A profile for a structured access token would be nice •  Can’t break existing deployments … … But could give guidance for new ones •  Holder of Key specifications – security beyond bearer tokens •  And if a structured access token is defined, will the future ever see a federated OAuth provider, the way we see SAML federation servers today? Finally, a personal rant … fix the power imbalance between Identity Providers & users!!!
  36. 36. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop And in Closing … • Questions? • Comments? • Scrutiny? • Thank you! :-) adam.lewis@motorolasolutions.com

×