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

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

Who We Are

The Problem
Lots of Applications,
exposing Lots of APIs …
Running on different servers …
Communicating with clients
on different computing devices …
Lots of Passwords! ☹

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)

So Let’s take a step back …

Get apps & APIs out of the password business …

… and into the token consumption business.

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

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

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

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
???

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)

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

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)

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

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

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?

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)

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

With that settled, time to flesh out the details …

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()

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)

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

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?
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!

Putting the token to work
•  New and Shiny RESTful APIs
•  Legacy WS-* APIs
•  Other
•  Proprietary APIs
•  SIP
•  RTSP

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
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

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
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
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

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

… But what about accessing APIs across security domains?

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?

There are a number of options …

Federated Authorization Server
Active Directory
OAuth
AS
Home
Foreign
Resource Server
Foreign
Resource Server
Foreign
Resource Server
password
JWT
JWT
JWT

OAuth Assertion Profile
Resource
Server
STS
Resource
Server
STS
Active Directory
Home
STS
password
JWT
JWT
Foreign
Resource
Server
STS
Foreign
Foreign
JWT

Federated authentication to Authorization Server
Active Directory
Home
Resource
Server
STS
Resource
Server
STS
Resource
Server
STS
SAML
IdP
password
SAML
SAML
SAML

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!!!

And in Closing …
• Questions?
• Comments?
• Scrutiny?
• Thank you! :-)
adam.lewis@motorolasolutions.com

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

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

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

More from CloudIDSummit

More from CloudIDSummit (20)

Recently uploaded

Recently uploaded (20)

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