dsyer s2gx2011 idm

Identity Management with Spring Security

Dave Syer, VMware, SpringOne 2011

Overview

●
What is Identity Management?
●
Is it anything to do with Security?
●
Some existing and emerging standards
●
Relevant features of Spring Security and other Spring projects
●
Common use cases
●
Demo of prototype IDM system

COPYRIGHT VMWARE, INC, 2011

Agenda

● Core domain:
● Authentication, identity, trust, delegation, claim, authorization
● SSO
● Identity Management
● Standards:
● SAML
● OpenID
● OAuth, OAuth2
● OpenID Connect
● SCIM
● JWT
● Spring Security and other projects
● Use cases (Google, Facebook, CloudFoundry) and demos
● IDM as a Service

Demo Code

$ git clone git://gist.github.com/1316904.git


Authentication

● You say you are Fred Bloggs? Can you prove it?
● Human-human interactions
● Official document (passport, driving licence, etc.)
● We actually call it “ID”
● Letter of introduction
● Word of mouth, friend of a friend
● Machine-human interactions
● Something you know, hopefully unguessable, maybe random, e.g.
username/password
● Something you have, e.g. one Time Password (OTP) from RSA
hard/soft token
● Multifactor authentication
● Machine-machine interactions


Typical System Architecture

“I'm Fred,
show me my
photos”
User
APP

DB User details
store


Fred Accesses his Photos


Two Apps, No Shared Authentication

“I'm Fred,
show me my
photos”
User
APP1

“I'm Fred,
can I buy a
book?”

APP2

DB User details
store

DB


Two Apps, Shared User Details

“I'm Fred,
show me my
photos”
User
APP1

“I'm Fred,
can I buy a
book?”

APP2

DB

User details
store


Two Apps, Single Sign On

“I'm Fred,
show me my
photos”
User
APP1

“I'm Fred,
can I buy a
book?”

APP2
SSO

DB

User details
store


All Apps are
Single Sign On: Example Flow the same

● Explicit authentication
required on first visit

● Avoidable
subsequently if App
can store token – but
then with multiple
apps you have
distributed state

This is
unavoidable

Two Apps, Single Sign On with Separate Authentication

“I'm Fred,
show me my
photos”
User
APP1

“I'm Fred,
can I buy a
book?”
AUTH

APP2
SSO

DB

User details
store


SSO With Spring Security

● Good support for CAS
● Many custom implementations for commercial products like
SiteMinder
● Field is fragmented
● OpenID...


Trust

● You say you are Fred Bloggs? Can you prove it?
● Oh, I remember, Martha said you're alright. Come in...
● I trust Martha, USDOT, UKPA, etc, to verify Fred's identity
● Why?
● Because I know them, and they say they know Fred.


Consumer Trusts Provider

“I'm Fred,
show me my
photos”
User
Consumer, APP
Relying Party

IDP Provider

DB

User details
store


Simplified User-App-IDP Interaction


So What did we Gain with an Identity Provider?

● App no longer has to do authentication or keep record of secure
information about users
● User only has to type secrets into a known trusted site (e.g.
Google)

● Separation of concerns
● Abstraction always comes at a cost
● Increased complexity – more to understand, more to maintain,
more to go wrong
● Complexity and Security are uneasy bedfellows
● Hence there are standards that cover this interaction


Complexity: Schematic Actual Conversation


Complexity: HTTP Protocol Actual Conversation


Compare: Native Authentication


OpenID

“I'm Fred,
show me my
photos”
User
Relying Party APP

OpenID Provider

DB

User details
store


OpenID

● Protocol for attribute exchange
● Sits on top of HTTP(S)
● Form plus JSONish on back channel (attribute fetch)
● Form data and redirects on front channel
● Does not specify authentication (up to the Provider)
● Does not require pre-registration of Relying Parties (Apps)
● Implemented in various languages, e.g. Java->OpenID4J (Google
code)
● Support in Spring Security for Relying Party


Spring Security OpenID RP

<http xmlns="http://www.springframework.org/schema/security">
...

<openid-login login-page="/openid"
user-service-ref="registeringUserService"
authentication-failure-url="/login_error.jsp">
<attribute-exchange identifier-match=".*">
<openid-attribute name="email"
Type="http://schema.openid.net/contact/email" required="true" />
<openid-attribute name="fullname"
type="http://schema.openid.net/namePerson" required="true" />
</attribute-exchange>
</openid-login>

</http>


SSO with OpenID

“I'm Fred,
show me my
photos”
User
Relying Party APP1

“I'm Fred,
can I buy a
book?”

APP2
OpenID

DB
Provider
User details
store


SSO with OpenID

No user input
required here if
IDP is stateful


Delegation and Client Authorization

● So Fred told you to come and pick up his order?
● You say you're Martha? Show me some ID.
● And what about some documentation about the order?

Resource Owner

Client
(e.g. a service
provider) Scope of
responsibility


Delegation and Client Authorization

● An App needs to access Fred's resources on his behalf
● Resources live in a protected Resource Server (API)
● Fred is the Resource Owner: he can read and write his resources
if he logs into the API himself
● But App is the Client of the API service not Fred, and Fred
doesn't want to grant App write access
● Resource Server can grant App access to a restricted Scope of
activity
● Fred authorizes the App to read his Resources
● App gets an Access Token that enables it to act on behalf of Fred
● Where does it get the token from? An Authorization Server


Delegation

“I'm Fred,
show me my
photos” Resource
Client APP Owner

Token

API Resource
Server

Token Authorization
AUTH
Services Server


Example Token Services using Shared Storage

“I'm Fred,
show me my
photos” Resource
Client APP Owner

Token

API Resource
Server

AUTH Authorization
Server
DB

Token Store


Delegation Standards

● SAML 1.0, 2.0
● XML
● back channel Need key
exchange
● cryptography
● Spring Security SAML, Service Provider = Resource Server only
● OAuth 1.0a
● plain text
● back channel
Nonce and request token
● cryptography
● Spring Security OAuth (consumer and provider)
● OAuth 2
● JSON (plus optional custom formats)
● no back channel in spec (but need token services in practice)
● clear text (need SSL), plus extensions
● Spring Security OAuth (consumer and provider)


OAuth2

● Client /app

GET /api/photos
Authorization: Bearer FDSHGK78JH356G

● Resource Server /api
authenticated:
200 OK
...

unauthenticated:

401 Unauthorized
WWW-Authenticate: Bearer realm=”/auth”


OAuth2 Acquiring an Access Token

● Grant Types
● Password
● Authorization Code
● Refresh Token
● Implicit
● Client Credentials
● Others allowed as extensions, e.g. SAML assertion


OAuth2 Grant Type: Password


GET /auth/token?response_type=password&username=......&...
Authorization: Basic asdsdfggghf=

● Authorization Server /auth Client
credentials
● Token Endpoint

200 OK
{
“access_token” : “JAHDGFJH78IOUY”,
“token_type” : “bearer”,
“expires_in” : “3600”
}


OAuth2: Grant Type Password


OAuth2 Grant Type: Authorization Code

● Client /app

GET /auth/authorize?response_type=authorization_code&...

● Authorization Server /auth
● Authorization Endpoint

302 Found
Location: /app/photos?code=dfjhg




GET /auth/token?grant_type=authorization_code&code=......&...

● Token Endpoint

200 OK
{
“expires_in” : “3600”
}



????


OAuth2 Grant Type: Authorization Code, Explicit Authorization

The spec doesn't say how this happens, just that it does,
e.g:
????


OAuth2: More Detail and Options

● Grant type
● Password – native apps, fixed authentication
● Authorization Code – webapps with browser redirects
● Refresh Token – optional for tokens issued with Auth Code
● Implicit – script clients in webapps, native apps
● Client Credentials – service peers
● Other, e.g. SAML
● Token type
● Bearer
● Other, e.g. MAC
● Scope
● Arbitrary string. Signifies something to Resource Server about which
resources are available. C.f. “audience” in SAML.
● State


Spring Security OAuth: Resource Server /api

<sec:http ...>
...
<sec:custom-filter ref="oauth2ServiceFilter"
before="EXCEPTION_TRANSLATION_FILTER" />
</sec:http>

<oauth:provider id="oauth2ServiceFilter" token-services-ref="tokenServices">
<oauth:resource-server resource-id="api" />
</oauth:provider>


Spring Security OAuth: Authorization Server /auth

<sec:http>
...
<sec:custom-filter ref="oauth2ServiceFilter" after="EXCEPTION_TRANSLATION_FILTER" />
</sec:http>

<oauth:provider id="oauth2ServiceFilter" token-services-ref="tokenServices">
<oauth:authorization-server client-details-service-ref="clientDetails">
<oauth:authorization-code />
<oauth:implicit />
<oauth:refresh-token />
<oauth:client-credentials />
<oauth:password />
</oauth:authorization-server>
</oauth:provider>

<oauth:client-details-service id="clientDetails">
<oauth:client clientId="app"
authorizedGrantTypes="password,authorization_code,refresh_token"
scope="read_photos"
authorities="ROLE_GUEST" />
</oauth:client-details-service>


Spring Security OAuth: Client /app

<sec:http>
...
<sec:custom-filter ref="oauth2ClientFilter" after="EXCEPTION_TRANSLATION_FILTER"/>
</sec:http>

<oauth:client id="oauth2ClientFilter" token-services-ref="oauth2TokenServices" />

<bean class="apiRestTemplate" class="org...oauth2.client.OAuth2RestTemplate">
<constructor-arg ref="api" />
</bean>

<oauth:resource id="api" type="authorization_code"
clientId="app" accessTokenUri="${accessTokenUri}"
userAuthorizationUri="${userAuthorizationUri}" scope="read_photos" />

N.B. Spring Social has client support as well (similar approach,
convergence will come later)


OpenID Connect

● Similar to OpenID in the role that it plays, but not in any other way
related
● Uses OAuth2 as a protocol for attribute exchange
● Google, Salesforce, etc. behind spec
● OAuth2 endpoints:
● /authorize
● /token
● OpenID endpoints are OAuth2 protected resources:
● /userinfo
● /check_id
● Clients obtain access token with scope=openid
● OAuth /token endpoint includes id token in response as well as
access token
● Responses in JSON or JWT (=encrypted JSON)
● Not implemented in Spring project (yet), SECOAUTH or SEC


OpenID Connect: Token Acquisition


GET /auth/token?grant_type=authorization_code&code=......&...

● Token Endpoint

200 OK
{
“expires_in” : “3600”,
“scope” : “openid”,
“id_token” : “LKJADSFKHJG8723E”
}


OpenID Connect: User Info


GET /auth/userinfo
Authorization: Bearer JAHDGFJH78IOUY

● User Info Endpoint

200 OK
{
“user_id” : “dsyer”,
“name” : “Dave Syer”,
“email” : “dsyer@vmware.com”,
...
}


SCIM

● Simple Cloud Identity Management
● Plain test / JSON standard for provisioning identity systems
● Standard endpoints
● /Users – query user accounts
● /User – CRUD operations on users
● /Groups – CRUD operations on groups
● An OAuth2 authorization service might implement SCIM
● Not implemented (yet) in Spring


Spring Security: Project Organization

Luke Taylor (VMW),
Core
Robert Winch Spring Security
Web
● 3.1.0 just released
● Stable, mature

Ryan Heaton, LDAP OpenID ...
Dave Syer (VMW),

Spring Security OAuth
Spring Extensions: Security

Vladimir Schaefer,
Keith Donald (VMW), Mike Wiesner (VMW)
OAuth1a OAuth2 Craig Walls (VMW)
SAML Kerberos
Spring Social
● Oauth2 spec not yet final
● External lead
● 1.0.0 not yet released
● 1.0.0 just released ● Partly external, low-activity
● 1.0.0.M5 release in pipeline
● Consumer for well-

known providers


CloudFoundry IDM

“I'm Fred,
show me my
apps” Resource
Client Admin Console Owner

Token

CloudController Resource
Server

Authorization
Access Token Server:
UAA
Decision Services
OAuth2,
OpenID Connect,
Collab Spaces SCIM


CloudFoundry IDM

“I'm Fred,
show me my
apps” Resource
Client VMC Owner

Token

CloudController Resource
Server

Authorization
Access Token Server:
UAA
Decision Services
OAuth2,
OpenID Connect,
Collab Spaces SCIM


Links

● SECOAUTH:
https://github.com/SpringSource/spring-security-oauth
● OpenId4J: http://code.google.com/p/openid4java/
● OpenID Connect: http://openid.net/developers/specs/
● OAuth2: http://tools.ietf.org/html/draft-ietf-oauth-v2
● SCIM: http://www.simplecloud.info
● SES (SAML and Kerberos):
http://static.springsource.org/spring-security/site/extensions.html
● Demos: http://gist.github.com/1316904


dsyer s2gx2011 idm

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

dsyer s2gx2011 idm