Auth in the extended enterprise - Keynote for MIT Legal Hack A Thon 2013

©2013 The MITRE Corporation

Justin Richer, The MITRE Corporation January 2013

Approved for Public Release; Distribution Unlimited. 13-0239


}  OAuth2 }  OpenID Connect }  MITREid Connect open source project }  Trust Frameworks

2


Delegated Authorization

©2013 The MITRE Corporation 4



}  Authorization protocol framework }  Built on deployment experience with OAuth 1,

SAML, OpenID, and others }  IETF Standard (as of 10/2012) ◦  RFC6749, RFC6750

}  Built for HTTP APIs }  Mobile friendly }  REST-friendly ◦  Not RESTful itself

6


Resource Owner (Controls stuff)

Client (Wants stuff)

Protected Resource (Has stuff)

User Agent (Web browser)

Access Token (Lets client get stuff)

Refresh Token (Lets client ask for access tokens without bugging the user again)

Authorization Server (Issues tokens)

7



}  Authorization Code ◦  Very secure ◦  Most common ◦  Good for web server and native apps

}  Implicit ◦  Good for apps inside the browser

}  Client Credentials ◦  When there’s no user involved

}  Resource Owner Credentials ◦  Bootstrap username/password systems

9


}  Refresh token ◦  Get more access tokens without bothering the user

}  Assertion ◦  Extension ◦  Uses structured tokens: JWT, SAML

}  Chain/redelegation ◦  Extension ◦  Trade one access token for another

10


The most common OAuth2 Pattern


Resource Owner & User Agent Authorization Server

Protected Resource Client


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


UA AS

PR C


}  Avoiding password proliferation ◦  User’s credentials never go to the client

}  API protection ◦  Hundreds of thousands of sites, projects, and

systems … and growing }  Mobile access to server systems }  Authentication (sign-on) protocols ◦  Facebook Connect, Log In With Twitter, etc.

24



No, it isn’t.


No, it REALLY isn’t.


Metaphor from: http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx

Chocolate Fudge


}  Delicious on its own }  Versatile ingredient ◦  Useful in many circumstances

}  Can be used to make fudge

29


}  A confection with several ingredients }  Can be made with chocolate ◦  But needs more than just chocolate ◦  Could be made without chocolate

30


}  Create an identity API, protect it with OAuth ◦  Authorization Server becomes Identity Provider ◦  Client becomes Relying Party

}  Standardized user profiles ◦  Name, email, picture, etc.

}  Session management ◦  Is the user still logged in? ◦  Log out

}  Step up to high levels of authentication }  Keep compatibility with basic OAuth2

31



Why hasn’t anyone done that?


Distributed identity at internet scale


}  OpenID Connect (OIDC) is built on experience with OpenID 2, OAuth, SAML, Facebook Connect, etc.

}  Developed by the OpenID Foundation ◦  http://openid.net/connect

35


}  OAuth 2 authorization ◦  Authorization Server becomes Identity Provider ◦  Client becomes Relying Party

}  JSON Web Tokens ◦  Structured token format

}  Can work in fully-distributed mode ◦  Dynamic discovery and registration ◦  Self-issued identities

}  “Make the simple things simple, make the difficult things possible.”

36


}  Use OAuth2 to get a regular access token, as well as an ID token

}  Use access token to call User Info Endpoint ◦  Standardized user profile ◦  Standardized scopes

}  Parse and use ID token to manage current session and user information

37


}  Higher levels of assurance ◦  Signed and encrypted requests ◦  Signed and encrypted responses

}  Fine-grained claims management }  Distributed and aggregated claims }  Self-issued identities }  IdP-initiated login ◦  Kicks off the standard flow “remotely”

}  Can get very complex if you want it to ◦  “SAML with curly braces”

38


}  OAuth 2 in the wild }  Real-life interoperability testing }  Real deployments, large and small }  Generalization of protocols ◦  OIDC Discovery -> Webfinger ◦  OIDC Registration -> OAuth 2 Dynamic Client

Registration ◦  JWT Claims �  Subject, audience, authorized presenter

39


41

42

43


https://github.com/mitreid-connect


}  Server and client built on Spring Security }  Supports key features: ◦  Signed tokens ◦  Request objects ◦  Authorization code and implicit flows

}  Interoperability testing with working group ◦  Nomura Research Institute (PHP client) ◦  OIDC-PHP (PHP Client) ◦  IBM (Java client) ◦  Nov Matake (Ruby client and server) ◦  OIDC test suite (Python) ◦  … and others

45


}  Enterprise-friendly platform (Java Spring) }  Administration consoles }  Programmable API }  Modern UI }  Event and action logging }  General-purpose OAuth 2.0 service ◦  Support the wider MITRE Partnership Network effort ◦  More than just single-sign-on

46

©2013 The MITRE Corpora3on 47

©2013 The MITRE Corpora3on




MITREid Connect Open Source Project

SECOAUTH

Spring Security Spring

Java

Per-server overlays (not public)

Hosted on GitHub

Open Source, owned by VMWare

Server A Server B …

51


Please join us!



}  A legally binding document signed by affected parties

}  Dictates the rules in three dimensions ◦  Business, Legal, and Technical

}  Core to National Strategy for Trusted Identities in Cyberspace (NSTIC) ◦  Identity Ecosystem

54


}  Technology is only part of the problem }  Distributed work is commonplace ◦  Policies and guidance haven’t kept up ◦  What defines the “normal” case? ◦  How do you handle the exceptional cases?

}  Built on whitelist/blacklist/graylist construct ◦  Explicitly allow for interactions that haven’t been

previously vetted }  Technology centered around OpenID ◦  Support for 2.0 based on FICAM profile ◦  Support for Connect based on draft standard

55


It’s good for you!


}  First time through, ask: ◦  “You’ve never allowed this before. This is what I can

say about them, is that OK?” }  Subsequent times through: ◦  “I’m reasonably sure this is the same thing that

you’ve said OK to before, let it through”

57


Whitelist Trusted partners, business contracts,

customer organizations, trust frameworks

Graylist User-based trust decisions

Follow TOFU model, keep logs

Blacklist Very bad sites we don’t want to deal with, ever

58


Whitelist Trusted partners, business contracts,

customer organizations, trust frameworks

Graylist User-based trust decisions

Follow TOFU model, keep logs

Blacklist Very bad sites we don’t want to deal with, ever

Org

aniz

atio

ns

deci

de th

ese End-users

decide these

59


}  Security must be usable by regular people }  We need multiple models, together ◦  It’s a continuum

}  Let organizations decide: ◦  What organizations/sites to trust automatically ◦  Who to sue if something goes wrong ◦  Who to block completely

}  Let users decide: ◦  If they trust things the organization is silent about ◦  (It’s easy to forget about this one)

60


What security folks say to do

What users actually do

61


- Eve Maler



}  It’s a real live IETF standard (family) ◦  RFC6749, RFC6750

}  Many, many web APIs use it ◦  Many more on the way

}  Extensions to core OAuth functionality helping it find use in new places ◦  Replacing old-style SOA authorization systems

64


}  Cracking open enterprise identity ◦  Federation over direct authentication ◦  Derived credentials over primary credentials

}  Large scale internet identity platforms ◦  Google fully behind it ◦  Implementations from Ebay, IBM, Microsoft, others

}  Implementer’s draft available now

65


}  Security MUST be usable by “normal people” }  People will find way around things they

perceive to get in their way ◦  Even if it’s “good for them”

66


Justin Richer [email protected]


Here there be dragons



UA AS

PR C


UA AS

PR C


}  OAuth doesn’t define what goes into the token string itself

}  Define a parseable format for moving data within the token: JSON Web Tokens (JWT) ◦  http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06

}  Clients and protected resources can verify the token through signatures (JOSE) ◦  http://datatracker.ietf.org/wg/jose/

72


eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

{"typ":"JWT", "alg":"HS256"}

{"iss":"joe", "exp":1300819380, "http://example.com/is_root":true}

+

+ = (signature)

73


}  Unstructured or opaque tokens ◦  “I have a token, what is it good for?”

}  Token in, JSON out }  http://tools.ietf.org/html/draft-richer-oauth-introspection-01

74

{ "valid": true, "client_id":"s6BhdRkqt3", "scope": ["read", "write", "dolphin"], "subject": "2309fj32kl", "audience": "http://example.org/protected-resource/*" }


http://tools.ietf.org/html/draft-richer-oauth-chain-00 http://tools.ietf.org/html/draft-hunt-oauth-chain-01


UA AS

PR1 C PR2

?


UA AS

PR1 C PR2


UA AS

PR1 C PR2


UA AS

PR1 C PR2

Date post:	27-Jan-2015
Category:	Technology
Upload:	justin-richer
View:	115 times
Download:	4 times