Dale Olds, VMware A pinch of authentication theory and methods, a taste of the sweet and the bitter of the much maligned password, and then larger portions of federated authentication protocols from SAML to OpenID Connect, clearing up along the way some confusion between federated authentication and tokens used for delegated authorization.

1. © 2014VMware Inc. All rights reserved.
Introduction to Authentication
Cloud Identity Summit
Dale Olds
olds@vmware.com
Senior Staff Engineer, VMware
July 2014

2. An Introduction to Authentication
●
Authentication definition and
purpose
●
Authentication methods
●
Federated authentication
●
Emerging trends and future
directions

3. 1. This presentation has been prepared
for identity newbies.
2. All heckling is encouraged.
3. Advanced hecklers, please see #1.

4. Definitions for Identity and Authentication Terms
From Open ID Connect Core 1.0, http://openid.net/specs/openid-connect-core-1_0.html

5. A Few Definitions for Starters
●
Entity – Something that has a separate and
distinct existence and that can be identified
in a context. An End-User is one example of
an Entity.
●
Identity – Set of attributes related to an
Entity.
●
Identifier – Value that uniquely characterizes
an Entity in a specific context.
●
Authentication – Process used to achieve
sufficient confidence in the binding between
the Entity and the presented Identity.

6. The Authentication Event
The ceremony that
establishes context
and security
(Pam's view)
Something to get past
quickly on the way to
something else (my view)

7. Why Do We Authenticate?
● Authentication is necessary for
authorization.
● Authentication of a user is necessary to
allow the user to DODO something.
● Authentication is the user in action
● Identity (user accounts) involves user
information at rest
● Provisioning involves managing identity
information by others.
“If you don't eat your meat, you can't
have any pudding. How can you
have any pudding if you don't eat
your meat?"
Pink Floyd (via Gil)

8. Why Do We Authenticate?
Photo by Emily Carlin, https://www.flickr.com/photos/cuttingboard/
To get to
authorization

9. Authentication Methods, and the Problems with Passwords
“Passwords are easy. Change is hard.”
-- Jeff Bohren

10. Protecting Password Data is Difficult
Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
● Saving some password
data necessary so a
service can verify the
password, making it a
tasty target.
● It's an arms race with
the birds that want to
eat your lunch.

11. Problems with Passwords: Password Hash Needs Salt
Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
● Saving passwords in clear text is obviously
dangerous if the password data is stolen.
● Save password hashes – non-reversible
fingerprint of the password means raw
passwords are not stored.
● Lookup tables, dictionary attacks and rainbow
tables can be used to efficiently crack large
amounts of hashed passwords.
● Using a unique, large salt value with each hash
renders rainbow tables much less effective.
● CPU/GPU capabilities have greatly increased.
Brute force cracking of passwords is feasible.
● Use hash algorithms such as Bcrypt to blunt
increase in CPU capability, and get users to use
larger passwords.
● And so it goes.

12. Problems with How Users Choose Passwords
Users use the same
password for multiple
sites.
Even “low value” sites
share password with
“high value” sites.

13. Passwords Should be Easy to Remember, Hard to Crack
Source: http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html
● Four short words are easy to remember, and hard to
crack.
● Password policy for punctuation and special
characters just irritates the users and is very little
help against password cracking.
● Good open source projects exist that implement this
technique. See https://github.com/dropbox/zxcvbn and
http://blog.cloudfoundry.org/2012/11/07/password-policy-in-cloud-foundry/
● Not so good for mobile devices yet.

14. Password Anti-Pattern is STILL in Use
If you actually read the User Agreement above,
it's clear what the password anti-pattern
really means.
source: http://virtualsoul.org/blog/2012/10/11/password-anti-pattern-alive-and-well-at-a-financial-institution/

15. Password Problems are Even Misunderstood
● The problem was a key logger virus
● No password data was retrieved from
Facebook, Yahoo, Google, etc.
● The article's advice for password
length, character type, and
uniqueness is not applicable to a key
logger.

16. Beyond Passwords: Other Authentication Methods
● Password managers
● Smart Cards
● Multi-factor authentication systems
● SMS message and other call-backs
● The rise of FIDO
However, the evolution of authentication methods remains an arms race.
We need a way to manage changing authentication methods, and to manage
the evolution of authentication effectively...

17. Federated Authentication: Add a Level of Indirection

18. Speaking of Computer Science...
“There are two hard problems in computer
science: cache invalidation, naming things,
and off-by-one errors.”
– various unattributed sources

19. Old-School Federated Authentication with SAML
WebAppA
SAML Identity
Provider - IdP
Browser
WebAppB
WebAppC
1. Joe starts at
WebAppA but is
not logged in,
gets redirected to
SAML IdP.2. Joe logs in with method
known only to IdP. IdP saves
session with Joe (probably in
a cookie) and redirects back
to WebAppA with a SAML
artifact.
3. WebAppA gets the
SAML artifact.
5. When Joe accesses
WebAppB or WebAppC, they
redirect him to the IdP – which
already has a session with Joe
so he is immediately redirected
back with an artifact.
4. WebAppA exchanges the SAML artifact for a
SAML assertion via the back channel. It trusts
the SAML assertion from that IdP, sets up
session with Joe (probably with a cookie) and
grants access.

20. Modern, Cool Federated Authentication with OpenID Connect,
and Delegated Authorization via OAuth2
WebAppA
OIDC AuthZ
Server - AS
Browser
WebAppB
WebAppC
1. Joe starts at
WebAppA but is not
logged in, gets
redirected to OIDC
Authorization Server.2. Joe logs in with method
known only to AS. AS saves
session with Joe (probably in
a cookie) and redirects back
to WebAppA with an
OAuth2/OIDC authorization
code.
3. WebAppA gets the
OAuth2 authorization
code.
5. When Joe accesses
WebAppB or WebAppC, they
redirect him to the AS – which
already has a session with Joe
so he is immediately redirected
back with an authorization
code.
4. WebAppA exchanges the authorization code
for an ID token (and an access token) via the
back channel. It trusts the ID token from that AS,
sets up session with Joe (probably with a cookie)
and grants access.

21. Progress in Identity Evolution
One
identity
(user
account)
per
application
External
identities
via LDAP
External
authentication
via SAML
External
authentication
and roles via
OAuth2 and
OpenID
Connect
External
authorization
We are
here

22. Does Federated Authentication Need to be so Complex?
● I went to Starbucks and ordered a vente
coffee with cream with my VISA debit card.
● The VISA network contacted my bank,
which transmitted an authorization code to
Starbucks.
● The authorization code was used to
transfer funds to Starbucks from my
account.
● I enjoyed the latte.
● I pointed a browser at my employee
benefits site and selected our payroll
provider, ADP.
● The benefits site presented a SAML
artifact to ADP
● The artifact was used to retrieve an
assertion which authorized access to my
payroll information.
● I wish I made more money
Teenagers, most adults, and
supposedly tech-averse grandmothers
have no problem understanding this.
Programmers, technologists, and tech-
executives claim this is too difficult.

23. Advantages of Federated Authentication
● Fewer numbers of identity and
authentication sources means less exposure
(but also higher value targets of those
sources).
● Identity and authentication sources can
specialize in security – no need for casual
services like Gawker to handle passwords.
● Authentication methods can evolve with no
change to applications.
● Varying authentication methods can be
required for applications based on identity
provider policy.
● Better user experience (longer lived single
signon) with more control over revocation of
access.
● Partitioned security space – authentication
and role information is targeted to specific
services. No password anti-pattern.

24. Future Directions
● Authentication policy – including step-up
authentication, and re-authentication
intervals.
● Continuous authentication and risk
analysis.
● Shared signals.
Remember why we authenticate...
Photo by Angélica Portales, https://www.flickr.com/photos/frozen-in-time/

25. Shared Signals

26. Shared Signals
White Paper
at the Open
Identity
Exchange
http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf

27. Shared Signals
White Paper
at the Open
Identity
Exchange
http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf

28. Conclusion to Introduction to Authentication
●
Authentication definition and
purpose: to get to authorization
●
Authentication methods: evolve,
passwords suck, other methods
exist and are improving.
●
Federated authentication: helps us
handle authentication evolution,
provides better security with better
user experience.
●
Emerging trends and future
directions: continuous
authentication, shared signals