© 2014 VMware Inc. All rights reserved.

Introduction to AuthenticationCloud Identity Summit

Dale Oldsolds@vmware.comSenior Staff Engineer, VMwareJuly 2014

An Introduction to Authentication

● Authentication definition and purpose

● Authentication methods

● Federated authentication

● Emerging trends and future directions

1. This presentation has been prepared for identity newbies.

2. All heckling is encouraged.

3. Advanced hecklers, please see #1.

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

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.

The Authentication EventThe ceremony thatestablishes context and security (Pam's view)

Something to get past quickly on the way to something else (my view)

Why Do We Authenticate?

● Authentication is necessary for authorization.

● Authentication of a user is necessary to allow the user to DO DO 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)

Why Do We Authenticate?

Photo by Emily Carlin, https://www.flickr.com/photos/cuttingboard/

To get to authorization

Authentication Methods, and the Problems with Passwords

“Passwords are easy. Change is hard.”

-- Jeff Bohren

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.

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.

Problems with How Users Choose Passwords

Users use the samepassword for multiplesites.

Even “low value” sitesshare password with “high value” sites.

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.

Password Anti-Pattern is STILL in Use

If you actually read the User Agreement above, it's clear what the password anti-patternreally means.

source: http://virtualsoul.org/blog/2012/10/11/password-anti-pattern-alive-and-well-at-a-financial-institution/

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.

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

Federated Authentication: Add a Level of Indirection

Speaking of Computer Science...

“There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.”

– various unattributed sources

Old-School Federated Authentication with SAML

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

Modern, Cool Federated Authentication with OpenID Connect,and Delegated Authorization via OAuth2

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

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 arehere

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.

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.

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/

Shared Signals

Shared SignalsWhite Paperat the Open Identity Exchange

http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf

Shared SignalsWhite Paperat the Open Identity Exchange

http://oixuk.org/wp-content/uploads/2014/04/The-Shared-Signals-Model-1.pdf

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