Dale Olds, Senior Staff Engineer, VMware If identity is the new perimeter, then users must be able to access applications anywhere: on premise, in the cloud or on partner sites. To enable this access we must take identity information into other worlds, and there is no Babel Fish. This session will explain how to enable access to distributed applications without making users feel like Marvin the Paranoid Android. We will cover topics like federated authentication, browser single sign-on and delegated authorization for cloud APIs. Standards in this area are essential, but SAML, OAuth2, SCIM and OpenID can sound like Vogon poetry. We'll touch on the standards, but keep the Vogon poetry to a minimum.

1. © 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 Workspace
Cloud Identity Summit, July 2013

2. Agenda
l
Crossing boundaries with identity information
l
Single sign-on and federated authentication
l
Provisioning user information across borders
l
Delegated authorization for distributed applications
l
Standards and Vogon poetry

3. Crossing Boundaries
with Identity Information

4. The limits of embedded accounts and shared directory services
It's a people problem
l
One account per application is killing us all – too many damn passwords
l
Initially easier for developers, but ultimately impossible for users as
applications proliferate
l
Username and password is easy, change is hard.
It's a management problem
l
Management domains (organizations) have different needs and control
l
Multiple apps can share a directory service such as Active Directory, but
generally only within a management domain
l
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.

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

6. Single Sign-on and Federated
Authentication

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

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

9. Federated authentication – solved for web applications
sparklr
photo sharing
appfacespace
identity provider
(idp)
browser
printr
photo printing
app
editr
photo 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!

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

11. Federated authentication – solved for web applications?
Unfortunately solutions are a primary cause of problems
(and there are some problems with this solution)

12. Federated authentication for web apps: downsides
fake idp
facespace
identity provider
(idp)
browser
printr
photo printing
app
editr
photo 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?
sparklr
evil photo
sharing app
What about non-browser apps? I've
heard that mobile apps may be
important.

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

14. Provisioning
User Information
across Borders

15. 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 provisioning
l
pros: forward references, less change, supports deprovisioning
l
cons: proliferates copies of identity information, hard to update,
authentication issues
Just in time (JIT) provisioning
l
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

16. Delegated Authorization for
Distributed Applications

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

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

19. A modern web or cloud app uses external services
sparklr
photo sharing
app
facespace
identity 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

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

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

22. l
issuing bank
l
check number
l
account and name
l
authorized amount
l
issued at date
l
expiration date
l
recipient
l
authorized signature
Contents of a cashier's check

23. authorization
server
(bank)
resource
owner
(user)
client
application
(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

24. l
JWT is an IETF specification (pronounced 'jot')
l
Three parts: header, content, signature
l
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
signatur
e
third part of the token authorized signature

25. authorization
server
resource
owner
via user
agent
(browser)
client
application 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 access token
in 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

26. authorization
server
resource
owner
via user
agent
(browser)
client
application 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

27. authorization
server
resource
owner
via native
app
resource server
1. user accesses cloud
controller but is not authorized.
application gets username
and 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

28. authorization
server
client
application
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

29. Standards and Vogon poetry

30. 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 years
l
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

31. Standards landscape: provisioning and delegated authorization
Provisioning
l
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 OAuth2
l
SCIM 2.0 is the first IETF spec and has been in development for just
over a year.
Delegated Authorization
l
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.

32. Questions?