cis13: identity as a matter of public safety: a case study in secure api access and sso across...

Identity as a Matter of P

ublic Safety

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


ublic Safety


Who We Are


ublic Safety


The Problem

Lots of Applications, exposing Lots of APIs …

Running on different servers …

Communicating with clients on different computing devices …

Lots of Passwords! ☹


ublic Safety


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 / REST RTSP SIP

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)


ublic Safety


So Let’s take a step back …


ublic Safety


Get apps & APIs out of the password business …


ublic Safety


… and into the token consumption business.


ublic Safety


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


ublic Safety


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

1

3

Receive the Token 2


ublic Safety


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


ublic Safety


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


ublic Safety


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)


ublic Safety


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


ublic Safety


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)


ublic Safety


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


ublic Safety


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


ublic Safety


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?


ublic Safety


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)


ublic Safety


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


ublic Safety


With that settled, time to flesh out the details …


ublic Safety


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


ublic Safety


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)


ublic Safety


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


ublic Safety


Session Mgmt Illustrated!

OAuth SSO client UA

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!


ublic Safety


Putting the token to work

•  New and Shiny RESTful APIs •  Legacy WS-* APIs •  Other

•  Proprietary APIs •  SIP •  RTSP


ublic Safety


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


ublic Safety


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


ublic Safety


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

1

2


ublic Safety


… But what about accessing APIs across security domains?


ublic Safety


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?


ublic Safety


There are a number of options …


ublic Safety


Federated Authorization Server

Active Directory OAuth AS

Home

Foreign

Resource Server

Foreign

Resource Server

Foreign

Resource Server

password

JWT

JWT

JWT


ublic Safety


OAuth Assertion Profile

Resource Server STS

Resource Server STS

Active Directory

Home

STS

password

JWT

JWT

Foreign

Resource Server STS

Foreign

Foreign

JWT


ublic Safety


Federated authentication to Authorization Server

Active Directory

Home

Resource Server STS

Resource Server STS

Resource Server STS

SAML IdP

password

SAML

SAML

SAML


ublic Safety


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


ublic Safety


And in Closing …

• Questions? • Comments? • Scrutiny?

• Thank you! :-)

[email protected]

cis13: identity as a matter of public safety: a case study in secure api access and sso across...

Technology