Post on 16-Dec-2015
1
Presented by:
OAuth, OpenID, SAMLMaking Sense of the Alphabet Soup for Cloud Identities
Vikas Jain, Director, Product ManagementApplication Security and Identity ProductsIntel CorporationTwitter: @VikasJainTweetBlog: blogs.intel.com/cloud-access-security
4
Cloud Identity Alphabet Soup
SAML
OAUTH
OpenID
UMASCIM
JWTPortable Contacts
5
Why were these Standards created?
•Enterprise User Federation
SAML
•API Authorization
•Allow sharing of user data with user’s consent
OAUTH
•Consumer Authentication
OpenID
Widely adopted in Enterprises, weak adoption in consumers
Drivers
Started for consumer use cases (Twitter, Facebook, etc.), moving into the Enterprise
Started for consumer use cases (Google, Yahoo, etc.), moving into the Enterprise
7
SAML - Security Assertion Markup Language
OASIS TC formed2001 V1.02002 V1.12003 V2.02005
Mature standard … but carries the legacy of XML
8
SAML Assertion
SAML Assertion (Portable Identity Container)
Subject
Attribute Stmts
User Identifier
User Attributes
Authentication Stmt Info about authentication context
…
XML
Describes user identity in XML format for exchange across domain boundaries
9
SAML Assertion Example<ns2:Assertion ID=“RbefeiCOM4ztlN2RHr9unkpQ”
IssueInstant="2010-10-21T13:59:07.953-04:00" Version="2.0”
xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion”>
<ns2:Issuer Format=“urn:oasis:names:tc:SAML:2.0:nameid format:entity”>ServerXYZ</ns2:Issuer>
<ns2:Subject>
<ns2:NameID Format=”- - -”>NameIdStatic</ns2:NameID>
<ns2:SubjectConfirmation OptionalInformationHere>
<ns2:SubjectConfirmationData OptionalInformationHere/>
</ns2:SubjectConfirmation>
</ns2:Subject>
<ns2:Conditions NotBefore="2010-10-21T13:58:57.953-04:00”
NotOnOrAfter="2010-10-21T14:01:01.265-04:00">
<ns2:AudienceRestriction>OptionalInformationHere</ns2:AudienceRestriction>
</ns2:Conditions>
<ns2:AuthnStatement AuthnInstant="2010-10-21T13:59:07.953-04:00"
SessionIndex="c+dWjVJ24DMVNNo1U/cr+hgfywg=PWUYaQ=="
SessionNotOnOrAfter="2010-10-21T14:01:01.328-04:00">
<ns2:AuthnContext> - - - </ns2:AuthnContext>
</ns2:AuthnStatement>
<ns2:AttributeStatement>
<ns2:Attribute Name=“Attr1”
NameFormat=“urn:oasis:names:tc:SAML2.0:profiles:attributes:basic”>
<ns2:AttributeValue>Attr1value</ns2:AttributeValue>
</ns2:Attribute>
</ns2:AttributeStatement>
</ns2:Assertion>
10
SAML Protocols, Bindings, and Profiles
Profiles
Web SSO
Single Logout
WS-Security,
etc.
Bindings
HTTP Post
HTTP Redirect
Artifact, etc.
ProtocolsAuthN
requestSingle Logout
Assertion query, etc.
Use case flows (combination of assertion, protocol, binding)
Maps Protocols to std messaging (combines Assertion, protocol, binding )
Get Assertions (request/response)
Defines how SAML Assertions are used
11
SAML Use Case #1: Web Federated SSO For Cloud and Partner Apps
BrowserSAML Server
Identity Provider (IdP)Service Provider (SP)
SAML Server
User Store User Store
Authenticate Verify IdentitySAML
•Users redirected to IdP for authentication
•Use Web Browser SSO SAML Profile
Login
•Logout from both IdP or SP sessions
•Use Single Logout SAML Profile
Logout
App
12
SAML Use Case #2: Web Service Access Control
XML Gateway
Web Service Consumer
Web Service Provider
Web Service
XML Gateway
User Store User Store
Insert SAML Token Verify SAML TokenSAML (in WS-Security
header)
•Client app adds user info as SAML token in the message
•Use WS-Security SAML profile
Authentication
•Achieve fine grained authorization at web service by requesting clients to send add’l attributes in the SAML token
Authorization
Client App
SOAP Message
13
SAML Use Case #3: API Access Control
XML Gateway
API Consumer API Provider
APIXML Gateway
User Store User Store
Insert SAML Token Verify SAML TokenSAML (in HTTP header)
•Client app adds user info as SAML token in the HTTP Authorization header
•No standard profile exist
Authentication
•Achieve fine grained authorization at API by requesting clients to send add’l attributes in the SAML token
Authorization
Client App
15
OAUTH
1.02007 1.0a2009 2.02012(draft 26)
Provides API Authorization
Before OAUTH, HTTP Basic was primarily used by API providers to authenticate clients using username/password. Scoped access wasn’t possible.
16
OAUTH 2 Protocol Flow (Abstract version)
Client
User / Resource
Owner
Authorization Server
Resource Server
1. Authorization Request
2. Authorization Grant
3. Authorization Grantand Client Credentials
4. Access Token
5. Access Token
6. Resource
Access Token allows the client to access resource on behalf of the user
17
What’s new in OAUTH 2?
•Signature made optional, SSL made mandatory
•No need for special parsing, encoding, and sorting of parameters
Simplified Signatures
•User-Agent Flow, Web Server Flow, Device Flow, Username and Password Flow, Client Credentials Flow, Assertion Flow
More Flows
•Authorization Server – user authorization and issue access token
•Resource Server – handles API calls
Separation of Roles
•Short-lived Access tokens and Refresh tokens
•Bearer Tokens
Token Enhancements
18
OAUTH 2 Flows
User-Agent Flow• For clients running inside a user-agent that can’t maintain state over time• e.g. JavaScript based client apps
Server-Side Flow• For clients that are part of a server-side web application• e.g. Java/PHP client app
Native App Flow (not part of spec, but vendors implementing it)• For mobile and desktop apps. Same as server-side flow with one exception: a special redirect_uri (=oob)• e.g. Native mobile client app
Client Credentials Flow• For clients using application identity instead of end user identity to authenticate with authorization server• e.g. App to App connectivity
Assertion Flow• Client presents assertion (such as SAML) to authenticate with authorization server• e.g. Mobile app of SaaS app authenticating user with Enterprise credentials over SAML
Device Flow• For clients running on limited devices• e.g. TV and other SFF clients
Username and Password Flow• Client sends user’s username/password to authenticate with the authorization server. User trusts the client to maintain
security of it’s password• e.g. clients leveraging password managers
19
OAUTH Consumer Use Cases
• With user’s consent, grant my app to access user’s FB/Twitter account
• Access granted for limited scope (posting status updates)
Post to FB/Twitter from my App
• Login to my app using FB login• Achieved implicitly by user authenticating to FB to request
access token
Social Login
• Mobile Native apps retrieve/post data over APIs• APIs are protected using OAUTH
Mobile Apps
20
OAUTH Enterprise Use Case #1:Mobile App for Enterprise Apps
Mobile App accesses Enterprise App using OAUTH authenticating the user (with OAUTH AS) using Enterprise credentials
Benefits
• Enable Mobile access for Employees
• Authenticated by the Enterprise
• Enterprise user passwords not stored in Mobile
Source: Sep 29, 2011, “Enterprise Use Cases for Open Identity: OpenID and OAuth” Gartner report by Bob Blakley
21
OAUTH Enterprise Use Case #2:Mobile App for SaaS Apps
Mobile App accesses SaaS App using OAUTH authenticating the user (with OAUTH AS) using SAML assertion from the Enterprise
Benefits
• Enable Employee access to SaaS app via Mobile
• Authenticated by the Enterprise
• Enterprise user passwords not stored in mobile or SaaS App
Source: Sep 29, 2011, “Enterprise Use Cases for Open Identity: OpenID and OAuth” Gartner report by Bob Blakley
22
OAUTH Enterprise Use Case #3:Enterprise User accesses Partner REST app
Enterprise App accesses Partner REST App over OAUTH authenticating the user (with Partner OAUTH AS) using SAML assertion from the Enterprise
Benefits
• Access data in partner app under user’s identity
• Allows Enterprise App to make API calls on user’s behalf
• Enterprise user passwords not shared with Partner
Source: Sep 29, 2011, “Enterprise Use Cases for Open Identity: OpenID and OAuth” Gartner report by Bob Blakley
23
OAUTH Enterprise Use Case #4:Partner App accesses Enterprise REST app
Partner App accesses Enterprise REST App over OAUTH authenticating itself (with Partner OAUTH AS) using Application password
Benefits
• Enterprise exposes REST interface to partner
• Quick adoption: Partner doesn’t need to implement SAML server
• Partner app authentication secrets not exposed
Source: Sep 29, 2011, “Enterprise Use Cases for Open Identity: OpenID and OAuth” Gartner report by Bob Blakley
24
OAUTH Enterprise Use Case #5:Temp Workers access Enterprise App using FB Login
Contract workers/Affiliates accesses Enterprise App authenticating themselves using Facebook login (with Facebook OAUTH AS) and Enterprise OTP
Benefits
• Enterprise doesn’t have to manage temp identities
• OTP provides additional security
• Temp workers don’t have to remember another password
Temp Worker
Enterprise
ApplicationEnteprise AS & OTP
26
OpenID
1.12006 2.02007 Connect 1.02012(draft 10)
Provides Federated Login
User Identifier used is a URI that’s unique across all users. Based on key-value pairs. Carry some similarities with SAML.
Originally developed to prevent anonymous users from posting spam to blog comment fields …
28
OpenID Consumer Use Cases
•Login to my app using Google login
Social Login
•Pull user attributes from OpenID provider during registration process
User Registration
29
OpenID Enterprise Use Cases
•Bring Your Own Identity – Employee bring their own OpenID to access Enterprise Apps
•One password to unlock Enterprise and Personal Apps
BYOI•Partne
r orgs don’t need to stand up SAML IdP
•Enterprise don’t have to manage external identities
Enterprise app access to partners &
contractors
•Enterprises can add an extra layer of OTP for enhanced security
Add multi-factor authN to OpenID
OpenID has the potential to accelerate the BYOI (Bring Your Own Identity) movement into the Enterprise
30
Key Takeaways
SAML Enterprise Authentication
Sharing app with partners
OAUTH REST API Authorization
Building or consuming
mobile / REST app
OpenID AuthenticationSocial login
for consumer websites
Protocol Built for Use Cases
32
McAfee Cloud Security Platform
Web Authentication Email
Enterprise
MobileUsers
EnterpriseUsers
Private CloudApplications
Cloud Security Platform
Global Threat Intelligence
Saa
S o
r Applia
nce
Services Gateway Identity Manager
Web SecurityData LossPrevention
Email Security
Mod
ules
Unified Management, Policy and Reporting, ePO Integration
PartnersCloud
Vendors Applications Customers
Cloud Ecosystem
www.mcafee.com/cloudsecurity
33
Intel Expressway Service Gateway – for REST APIs
• REST.,SOAP• XML, Non-XML• HTTP, FTP, TCP
Protocol Agnostic
• 2x hard appliances • Tie-in to chip roadmap• Efficient XML
parsing at machine level
Performance
• Simple visualenvironment
No Programming
CODING
• Routing • Transform• Validation• Service Call-outs• Firewall rules
Flexible
• FIPS 140-2 Level 3 Crypto• Common Criteria EAL4+ • DoD STIG Ready & PKI Certified• HSM PKI key storage• Cavium crypto acceleration• Form factors: software, virtual, and tamper
resistant
34
Provision Access Secure SSO Regulatory Compliance
• Provision/de-provision user accounts
• AD integration
• Sync Id Profiles
• Rich audit trail of user login showing AuthN level
• De-provision & orphan account reports
• Federate windows/AD log in
• To popular SaaS like Salesforce & Google Apps
Adaptive Strong Auth
• Selectively apply 2nd factor OTP AuthN
• Variety of software AuthN methods & devices- mobile devices, SMS, email
Enterprise to Cloud SSO Securing Custom or SaaS Apps
AppsSAML
Combining Enterprise Class Strong Auth with SSO
Intel Expressway Cloud Access 360 – for Cloud SSO
In the CloudTo the Cloud
AD
Enterprise
Available as McAfee Identity Manager
35
Intel Cloud SSO - IAM-as-a-service
Browser
SSO PortalAccount
Provisioning
Mobile
Laptop
iPad
Enterprise
My Apps
One Time Password
• Delivers same level of control as on-prem IAM
• Leverage Salesforce or enterprise accounts for SSO
• Trigger mobile & hardware assisted authentication
Force.comApps
Access 100s of External SaaS Apps