Your SlideShare is downloading. ×
CIS13: Identity as a Matter of Public Safety: A Case Study in Secure API Access and SSO Across Security Domains
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,167
views

Published on

Adam Lewis, Office of the CTO, Motorola …

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,167
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Who We Are
  • 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. 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. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop So Let’s take a step back …
  • 6. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop Get apps & APIs out of the password business …
  • 7. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop … and into the token consumption business.
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop With that settled, time to flesh out the details …
  • 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. 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. 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. 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. 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. 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. 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. 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. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop … But what about accessing APIs across security domains?
  • 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. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop There are a number of options …
  • 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. 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. 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. 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. IdentityasaMatterofPublicSafety Cloud Identity Summit 2013 – API Workshop And in Closing … • Questions? • Comments? • Scrutiny? • Thank you! :-) adam.lewis@motorolasolutions.com

×