Upload
ca-api-management
View
600
Download
0
Embed Size (px)
Citation preview
Pa#erns to Bring Enterprise and Social Iden5ty to the Cloud
SVP and Dis5nguished Engineer K. Sco' Morrison
7 Copyright © 2013 CA. All rights reserved.
Trading Partner
Secure Internal Network
Firewall
Suppose We Recast the Problem?
8 Copyright © 2013 CA. All rights reserved.
Secure Internal Network
This is Just Federa@on
Trading Partner
IdP
Principal
9 Copyright © 2013 CA. All rights reserved.
Secure Internal Network
Admin Sets Up Trust Rela@onship
IdP
Admin
11 Copyright © 2013 CA. All rights reserved.
Let’s Call This Pa'ern #1: SAML-‐based Federa5on
IdP
Service Provider
Message + SAML
Principal
Authenticate Acquire SAML token
Data
1)
2)
Note that this demonstrates SAML browser POST profile. The artifact profile is harder to do through corporate firewalls
13 Copyright © 2013 CA. All rights reserved.
What Does It Mean To Have An Account?
Directory
Objects
Some Cloud Service
App Server
15 Copyright © 2013 CA. All rights reserved.
Firewall
What We Really Have A Synchroniza@on Problem
Objects
Identities
Enterprise Directory
16 Copyright © 2013 CA. All rights reserved.
And What About Small Business?
Travels Mostly
Works from home
Works from Starbucks
18 Copyright © 2013 CA. All rights reserved.
Conceptually Here Is What Happens
1. User posts new tweet 2. Twitter posts
tweet to Facebook on user’s behalf
User Scott
19 Copyright © 2013 CA. All rights reserved.
This is the “password an5-‐pa#ern” A Bad First A'empt: Stored Passwords
User Scott
Send in Facebook Password
Twitter uses Facebook Password
20 Copyright © 2013 CA. All rights reserved.
OK, So Let’s Try SAML
User Scott
Scott authenticates
using his Twitter Password
Twitter vouches it authenticated Scott
21 Copyright © 2013 CA. All rights reserved.
But There Are Problems…
User Scott
How can we associate these different
representations of Scott?
Where are the limits on what Twitter can do?
23 Copyright © 2013 CA. All rights reserved.
Here’s What It Looks Like When We’re Done
User Scott
Scott authenticates
using his Twitter Password
Tweet plus access token authorizing Twitter to post for
Scott
OAuth Client
OAuth Authorization & Resource Servers
24 Copyright © 2013 CA. All rights reserved.
But OAuth Also Enables NASCAR-‐style Sign On
Taken from sears.com
25 Copyright © 2013 CA. All rights reserved.
Data
Let’s Call This Pa'ern #2: Social Sign-‐On
OAuth Authorization
Server
OAuth Client
User
Authenticate Get Code
Validate Code Get Access Token
1)
3)
Pass code to client 2)
This demonstrates:
grant-type=authorization_code! !Note the user never sees the access token, only the client sees it. The user’s session must be managed using other means (eg: session cookie, etc)
26 Copyright © 2013 CA. All rights reserved.
This Is Actually A Profound ShiZ In Iden@ty Mgmt
The Old Enterprise The New Hybrid Enterprise
This is the secret to achieving scale and agile federation
27 Copyright © 2013 CA. All rights reserved.
What is Really Different Here?
• Integra@on with simple RESTful APIs • Very loose coupling • Very low ceremony • Very loose rela@onships driven by caller
• Client to authoriza5on server • User to client
This all adds up to a distribution of responsibility that scales with no. of users
28 Copyright © 2013 CA. All rights reserved.
Let’s drive home how this enables self-‐provisioning of clients & users Delega@on of Responsibility
Auth Server
Client
User Authenticate Get Code
TBD
29 Copyright © 2013 CA. All rights reserved.
But We’re Not Quite At Federa@on
• We have simple Single Sign-‐On • But what about a'ributes?
<saml:AttributeStatement> ! <saml:Attribute FriendlyName="fooAttrib" Name="SFDC_USERNAME" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> ! <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string"> [email protected] </saml:AttributeValue> ! </saml:Attribute> !</saml:AttributeStatement>!
From: http://login.salesforce.com/help/doc/en/sso_saml_assertion_examples.htm
30 Copyright © 2013 CA. All rights reserved.
This Is The Job Of OpenID Connect
OpenID Connect Endpoint
OAuth Client
User
Call to UserInfo endpoint for specific scope
JSON structured attribute list of
claims Eg: User’s email,
First name, Last name,
etc
31 Copyright © 2013 CA. All rights reserved.
Scopes Define Collec@ons of Claims
• Profile – name, family_name, given_name, middle_name, nickname,
preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at
• Email – email
• Address – address
• Phone – phone_number, phone_number_verified
• etc
JSON Example:!{ "sub": "248289761001", ! "name": "Jane Doe", ! "given_name": "Jane",! "family_name": "Doe",! "preferred_username": "j.doe”,! "email": "[email protected]",! "picture": "http://example.com/janedoe/me.jpg" !}!
From: http://openid.net/specs/openid-connect-basic-1_0.html
Claims are associated with an access token
32 Copyright © 2013 CA. All rights reserved.
But we s5ll have a registra5on problem We’re Almost There
Authorization Server
Client
Provisioning of new users
This is obviously an enterprise problem, not an individual problem
They may already exist here
Remember our earlier point about what
constitutes an “account”
33 Copyright © 2013 CA. All rights reserved.
API for user management This Is The What SCIM Is For
Authorization Server
Client
Create New
Users
SCIM defines user/group schema and REST endpoints for CRUD
SCIM stands for: System for Cross-domain Identity Management
Enterprise Administrator
34 Copyright © 2013 CA. All rights reserved.
Secure Internal Network
Firewall
First, on-‐premise iden5ty stores We’re Now LeZ With Two Deployment Op@ons
Leverages Existing
Infrastructure IdP
35 Copyright © 2013 CA. All rights reserved.
Secure Internal Network
Or Cloud-‐based We’re Now LeZ With Two Deployment Op@ons
Identity-as-a-Service
36 Copyright © 2013 CA. All rights reserved.
Choose SAML or OAuth based on opera5onal goals The Deployment Is Independent Authoriza@on Technology
• SAML support is widespread • Dominant for enterprise SSO and federa5on • Strong in passive (browser) profiles • Less strong in ac5ve (classic SOAP or newer RESTful APIs) profiles • Lots of central administra5on and federa5on ceremony
• OAuth/OpenID Connect is growing very fast • OAuth owns RESTful APIs • The world is not just about browsers any longer
• Think about rise of mobile apps • Fast to integrate, with no need to engage par5es • Irresis5ble delega5on model • Poten5al brand, regulatory, or organiza5onal issues with social login
37 Copyright © 2013 CA. All rights reserved.
Summary
• SAML is not going away • Your exis5ng investment is safe • It will con5nue to play a huge role in web-‐based federa5on
• But OAuth+OpenID Connect+SCIM is coming on very strong • Driven by rise of APIs and mobile devices
• Don’t let anyone tell you OAuth is just another auth token scheme
• It really represents a shiW in authority