© 2010 VMware Inc. All rights reserved

The Hitchhiker's Guide To Identity

Taking the Hyperspace Bypass: Controlling User Access to Other Worlds

Dale Olds, Sr. Staff Engineer, VMware Horizon WorkspaceCloud Identity Summit, July 2013

Agenda

l Crossing boundaries with identity information l Single sign-on and federated authenticationl Provisioning user information across bordersl Delegated authorization for distributed applicationsl Standards and Vogon poetry

Crossing Boundaries with Identity Information

The limits of embedded accounts and shared directory services

It's a people probleml One account per application is killing us all – too many damn passwordsl Initially easier for developers, but ultimately impossible for users as

applications proliferatel Username and password is easy, change is hard.

It's a management probleml Management domains (organizations) have different needs and controll Multiple apps can share a directory service such as Active Directory, but

generally only within a management domainl The larger the management domain to more political and difficult to

change – schema becomes concrete

The solution is to enable the controlled transfer of identity information across management domains.

Think Facebook Connect.

In the last few years Facebook may have accomplished more to promote the common understanding of federated identity than all the major enterprise vendors have in the last 20.

Users now think of accounts as independent from applications.

I have an account at Facebook. I can use it at other places.

Single Sign-on and Federated Authentication

Federated authentication

Authentication is the act of confirming the truth of an attribute of a datum or entity... often involves verifying the validity of at least one form of identification. (wikipedia)

Let's try that again. For our purposes:

Authentication is the act of determining who is making a request. For apps with embedded user accounts, often called login.

Using Federated Authentication, an app trusts an identity provider to authenticate the user. The app gets the user's identity information from the provider, but is not involved in the act of authentication. The identity provider may be in another management domain.

This is not like multiple apps sharing a directory service, where the apps authenticate users independently using common data.

SAML and OpenID Connect are protocols for federated authentication

Browser redirects

New Documents Site

Old Documents Site

browser

1. Get me the Burning Man Survival Guide.

2. Document has moved, here is the new name and location.

3. Get me the new document.

The vast majority of all federated authentication systems, including all versions of SAML, OpenID, and OAuth use browser redirects to separate the act of authentication from an app.

Federated authentication – solved for web applications

sparklrphoto sharing

appfacespaceidentity provider

(idp)

browser

printrphoto printing

app

editrphoto editing

app

1. Joe starts at sparklr but he's not logged in, gets redirected to idp.2. Joe logs in with method

known only to idp. Idp saves session with Joe, redirects back to sparklr with signed token that this is Joe.

3. Sparklr trusts token from idp, sets up session with Joe and grants access.

4. When joe accesses printr or editr, they redirect him to the idp – which already has a session with Joe so he is immediately redirected back with a token. Single Sign-on!

Advantages of federated authentication

l Since an identity provider can authenticate users for many apps, there should be fewer (but more secure) authentication sources.

l Identity providers can add better authentication methods with no change to connected applications

l Major identity providers are already adding multifactor, continuous authentication – trending toward recognition.

l Incentives are to let a few identity providers handle authentication, and web applications focus on features.

l Consider the Gawker and LivingSocial crack.

.If you connect to LivingSocial using Facebook Connect,

your Facebook credentials were not compromised. Tim O’Shaughnessy, CEO of LivingSocial

Federated authentication – solved for web applications?

Unfortunately solutions are a primary cause of problems

(and there are some problems with this solution)

Federated authentication for web apps: downsides

fake idpfacespace

identity provider (idp)

browser

printrphoto printing

app

editrphoto editing

app

Privacy concerns: the idp knows every site that joe accesses with this account.

Other systems have been proposed, but involve significant changes and trust of the user's machine (see information cards, browserID).

Phishing concerns: if sparklr is evil it could redirect to fake idp, which reads the real idps ui, presents it to the user and steals their credentials

The problem with logout: what does it actually mean? Users are confused... if I logout of the app, I'm still logged in at the idp which gives me SSO with the app? If I log out of the idp, what should that mean for the apps?

sparklrevil photo

sharing app

What about non-browser apps? I've heard that mobile apps may be important.

Federated authentication – the future

SAML, OpenID Connect (with OAuth2) useful now for many use cases.

We've made great progress, but there are many unresolved issues. Technological evolution and cultural change must continue.

Work on OpenID Connect extensions for federated authentication for mobile applications is underway (see the AZA workshop).

Advances in continuous authentication and recognition make authentication more convenient and more secure.

Preventing phishing will be a longer, multi-component issue. Help from browsers is important and users may need to learn new expectations when interacting with sites.

Provisioning User Information across Borders

Provisioning

Old fashioned provisioning: just get the sysadmins to copy the identity information across boundaries!

Common questions:l If we have effective provisioning, do we need federated authentication?l If we have federated authentication, do we need provisioning?

Classic, push, apriori, static provisioningl pros: forward references, less change, supports deprovisioningl cons: proliferates copies of identity information, hard to update,

authentication issues

Just in time (JIT) provisioningl pros: only create accounts when needed, no provisioning protocol or

APIs needed (side effect of authentication).l cons: no forward references, no deprovisioning

Provisioning standards: LDAP, SPML, SCIM

Delegated Authorization forDistributed Applications

Federated authentication: protecting the front door

Federated authentication controls how users gain access to an app.

This is like controlling who can come into the front door of a store.

But the loading dock is open...

Modern apps aggregate information from other services, we need to control access to those services are well.

Who's protecting the loading dock?

A modern web or cloud app uses external services

sparklrphoto sharing

app

facespaceidentity provider

(idp)

browser

photo printing service

map data service

Joe needs to delegate authorization such that sparklr can access the services on his behalf.

Enter OAuth2

photo storage service

distributed app

But first, let's talk about what happens when selling a car

Illustration: selling a car

Bank

Sam

Joe, used car

broker

Me, selling a rusty 2000

nissan pathfinder

1. Sam tells Joe he'll take the pathfinder. Joe replies that he'll need a cashiers check for the purchase price.

2. Sam authenticates and gets a cashier's check.

3. Sam gives the check (signed by the bank) to joe.

4. Joe gives the check to me in exchange for the car.

I don't really care who Joe and Sam are, the check authorizes the transaction and it's guaranteed by the bank.

l issuing bankl check numberl account and namel authorized amount

l issued at datel expiration datel recipientl authorized signature

Contents of a cashier's check

authorizationserver(bank)

resourceowner(user)

clientapplication(joe broker)

resource server(me with pathfinder)

1. user accesses application but is not authorized. Application redirects user to the authorization server with instructions of what authorization to request.

2. user authenticates and approves release of token containing proof of authorization.

3. user is redirected back to the client app which gets the token.

4. client app presents token to resource server to authorize access to the resource.

Same transaction in OAuth2 terms

l JWT is an IETF specification (pronounced 'jot')l Three parts: header, content, signaturel While commonly used with OAuth2, OAuth2 does not require JWTs.l OpenID Connect does require JWTs for id_token

Sample token content, with corresponding cashier's check fields:

jwt meaning cashier's check

JSON web token (JWT) – a check format for the web

* commonly used, but not specified in JWT or Openid connect

iss issuer issuing bank

jti token ID check number

sub subject account & name

iat issued at issued at date

exp expiration expiration date

aud audience recipient

azp OIDC authorized party

*scope authorization authorized amount

signature

third part of the token authorized signature

authorizationserver

resourceowner

via user agent

(browser)

clientapplication resource server

1. user accesses application but is not authorized. application redirects user to the authorization server to request authorization.

2. user authenticates and approves release of token containing proof of authorization.

3. user is redirectedback to the client appwith an access tokenin location fragment

4. client app presents access token to resource server to authorize access. client app can use access token until it expires.

l access token is exposed to user's agent.

l access token lifetime is longest interval user cannot revoke access.

l client id, redirect urls must be registered – no secret

l generally a less secure and less convenient grant – avoid if possible

Implicit grant

authorizationserver

resourceowner

via user agent

(browser)

clientapplication resource server

1. user accesses application but is not authorized. application redirects user to the authorization server to request authorization.

2. user authenticates and approves release of token containing proof of authorization.

3. user is redirected back to the client app with an authorization code.

5. client app presents access token to resource server to authorize access. client app can use refresh token to request new access token on expiration.

4. client redeems authorization code for access and refresh tokens.

l access and refresh tokens aren't exposed to user's agent.

l access token lifetime is longest interval user cannot revoke access.

l refresh token lifetime is interval before user has to re-authenticate.

l client id, secret, redirect urls must be registered

Authorization code and refresh token grants

authorizationserver

resourceowner

via native app

resource server

1. user accesses cloud controller but is not authorized. application gets usernameand password

2. app posts user credentials to authenticate user and autoapprove release of token containing proof of authorization, requests password grant.

3. returns to the app with an access token and a refresh token

4. app presents access token to resource server to authorize access. app can use access token until it expires, but can get a new access token with the refresh token

l access and refresh tokens are exposed to the user's machine.

l access token lifetime is longest interval user cannot revoke access.

l limited to user name and password.

Resource owner password grant from native app

authorizationserver

clientapplication

resource server

2. client app presents access token to resource server to authorize access.

1. client authenticates and gets an access token with all its registered authorizations.

l access token cannot be revoked for it's lifetime.

l client id, secret must be registered

Client credentials grant

Standards and Vogon poetry

Standards landscape: federated authentication

While Craig's statement was entertaining, my team respectfully disagrees. We continue to implement SAML because our business is to support valid customer use cases.

For us, SAML isn't dead, it's done. It's complete. We can safely implement it.

OpenID Connect is very promising. It's not dead, but it's not done. l OpenID Connect has been baking for over 3 yearsl It is implementable, useful now and fairly stable.l Combines very well with OAuth2 (delegated authorization) and SCIM

(provisioning) for a mostly complete identity system.

“There is no future for SAML. No one is putting money into SAML development. NO ONE is writing new SAML code. SAML is dead.”

Craig Burton, CIS 2012

Standards landscape: provisioning and delegated authorization

Provisioningl My bet is on the Simple Cloud Identity Management (SCIM 1.1) protocol

produced by a group of interested individuals.l And my bet is on the IETF's System for Cross-domain Identity

Management (SCIM 2.0) protocol.l SCIM 1.1 is implementable, stable, and combines well with OAuth2l SCIM 2.0 is the first IETF spec and has been in development for just

over a year.

Delegated Authorizationl OAuth2 rules and is becoming a family of specifications.l Personally, I like to use it with JWT – which is also becoming a family of

specifications.

Questions?