identity as a matter of public safety
TRANSCRIPT
1
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
3
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
Our Architecture
SIP proxy
MSIserver
SIP client(s)
MSIclient
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
LDAPclient
LDAPserver
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-* clientWS-*
server WS-Trust Native & Web Apps Running on Android / Windows / iOS mobile LTE device
Mounted in Trunkof Police Car
Domain X – User might be a part of either domain 1 or 2 or 3 (or other)
5
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
So Let’s take a step back …
6
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
Get apps & APIs out of the password business …
7
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
… and into the token consumption business.
8
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
Now we can distill our complex problem into 3 simple steps …
1) App client asks for a token2) App client sends token to App server3) App server consumes token
API Client
API ServerToken Server
9
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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 credentialsAsk for Identity token
Use the Identity token
1
3
Receive the Token2
10
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
OAuth is for Authorization, not Authentication!
{ "iss": "https://server.example.com", "sub": "[email protected]", "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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
With that settled, time to flesh out the details …
21
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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 yourname &
password?(only ask ONCE)
23
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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 grantto 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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
Putting it all together …
OAuth AS WS-* STSWS-* 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-* App2RESTful
App1SSO client
User launches RESTful app
OAuth-to-WS* token Translation happens here
27
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
So OAuth works well within a single security domain …
OAuth AS RESTful API WS-* APIOther APIs
and Protocols
SSO client
Active Directory
Authenticate with primary credentialsGet OAuth access-token
Use the OAuth access-token
1
2
29
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
… But what about accessing APIs across security domains?
30
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
There are a number of options …
32
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
Federated Authorization Server
Active DirectoryOAuth
AS
Home
Foreign
Resource Server
Foreign
Resource Server
Foreign
Resource Server
password
JWT
JWT
JWT
33
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
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
Ide
ntity a
s a M
atte
r of P
ub
lic Sa
fety
Cloud Identity Summit 2013 – API Workshop
And in Closing …
• Questions? • Comments?• Scrutiny?
• Thank you! :-)[email protected]