Upload
cloudidsummit
View
3.287
Download
6
Embed Size (px)
DESCRIPTION
John DaSilva, Identity Architect, Ping Identity Craig Wu, Director, Product Development, Ping Identity If you’ve ever asked yourself, "What is SAML and how can it help me relieve my identity and access headaches?” then this is the session for you! In this bootcamp, you will learn why SAML is important for providing a secure exchange of identity information. We will dive into the specification and highlight the significant details with respect to federation. We will outline use cases that can be applied to your organization and finish with some hands-on activities to let you see it in action. Bring your laptop; a configuration of PingFederate that you can set up and a temporary product license will be provided.
Citation preview
6/21/13
1
Copyright ©2013 Ping Identity Corporation. All rights reserved. 1
Bootcamp: Ping Identity PingFederate SAML Hands-On
Copyright ©2013 Ping Identity Corporation. All rights reserved. 2
• Overview of most common SAML options • Gain an understanding of how SAML is being
utilized • Benefits of standards-based single-sign on • Common implementation challenges • See it in action!
Bootcamp Goals
6/21/13
2
Copyright ©2013 Ping Identity Corporation. All rights reserved. 3
• I want to understand how SAML works? – Because I want to implement the spec? – Because I just want to understand the process
better? • The session I wanted was full, second
choice? • What no free T-Shirts for attending!
Why are you here?
Copyright ©2013 Ping Identity Corporation. All rights reserved. 4 Copyright ©2013 Ping Identity Corporation. All rights reserved. 4
Bootcamp Agenda
Ø What and Why of SAML? • Benefits and Use Cases for SAML • Brief History of SAML • Version Changes • Interoperability • Technical Details
• Core – Profiles – Bindings
• Implementation Challenges
6/21/13
3
Copyright ©2013 Ping Identity Corporation. All rights reserved. 5
• Security Assertion Markup Language • Developed by the OASIS SSTC
– Organization for the Advancement of Structured Information Standards – Security Services Technical Committee
– SAML, ebXML, WS-*, UBL • XML specification for communicating user
authentication, entitlement, and attribute information • Designed to be extensible/customizable by other
standards
SAML a Definition (sort of)
Copyright ©2013 Ping Identity Corporation. All rights reserved. 6
• A system that allows the exchange of identity information across multiple domains using open standards in order to facilitate single sign-on.
• Partners in a Federated Identity Management system depend on each other to authenticate their respective users and vouch for their access to services.
• Companies can share applications/resources without needing to adopt the same technologies for directory services, security and authentication.
• A company must trust its partners to vouch for their users. Partners also need a standard way to send that message, such as one that uses the conventions of the Security Assertion Markup Language (SAML).
Background
6/21/13
4
Copyright ©2013 Ping Identity Corporation. All rights reserved. 7
• Limitations of Browser cookies – Most existing Single-Sign On products use browser cookies
to maintain state so that re-authentication is not required – Browser cookies are not transferred between DNS domains
• SSO Interoperability – Products implementing SSO and Cross-Domain SSO are
completely proprietary
• Federation – Simplification of identity management across organizational
boundaries, allowing users to consolidate many local identities into a single (or at least a reduced set) identity
Why is it Required?
Copyright ©2013 Ping Identity Corporation. All rights reserved. 8
• Three “Actors” – Identity Provider (IdP) or Assertion Producer
• The Authenticating site
– Service Provider (SP) or Assertion Consumer • The site which trusts the Producer to perform SSO
– Assertion Bearer • Usually the end-user’s web browser, which is used to
transport the Assertion from the Producer to the Consumer
Federation Terminology
6/21/13
5
Copyright ©2013 Ping Identity Corporation. All rights reserved. 9
• Attribute Contract – Agreement between SP and IdP on user attributes in assertion
• Identity Mapping – Conceptual core of identity federation – User generally known
by different identifiers and roles in different security domains • Metadata
– Standard file structure to exchange federation information • “First Mile” – integrating Authentication Service with
Federation Service* • “Last Mile” – integrating data from incoming assertion to
target application*
• * Ping Identity terms
More Terminology
Copyright ©2013 Ping Identity Corporation. All rights reserved. 10 Copyright ©2013 Ping Identity Corporation. All rights reserved. 10
Bootcamp Agenda
ü What and Why of SAML? Ø Benefits and Use Cases for SAML • Brief History of SAML • Version Changes • Interoperability • Technical Details
• Core – Profiles – Bindings
• Implementation Challenges
6/21/13
6
Copyright ©2013 Ping Identity Corporation. All rights reserved. 11
• Platform neutral • Loose coupling of directories • Improved experience for end users • Reduced administrative costs for service providers • Risk transference – IdP is responsible for managing
identities
Benefits of SAML (via OASIS)
Copyright ©2013 Ping Identity Corporation. All rights reserved. 12
• Simplified Administration – Reduces Number of Accounts & Passwords to Maintain – Partners Manage Their Own Users – Replaces Proprietary SSO with Standards-Based Solution – Ensures Compliance via Consistent, Standards-Based
Authentication
• Increased Security – Propagate Strong Authentication – Reduce Identity Theft Targets – Extend Enterprise Security to Hosted Services – Log/Audit Access to Secured Resources
What this really means
6/21/13
7
Copyright ©2013 Ping Identity Corporation. All rights reserved. 13
• Improved End-User Experience – Reduce Password Overload – Multiple Application Access With Single Authentication – More Personalized Experience – Expanded Functionality
• No longer a moving target – No “SAMLv3” on the horizon
• For the Service Provider – Lower operational costs (improve profitability). – Promote SaaS company service usage (stickiness). – Eliminate software piracy (no password sharing, increasing
top line growth) – Replaces Proprietary SSO with Standards-Based Solution
What this really means
Copyright ©2013 Ping Identity Corporation. All rights reserved. 14
PingFederate Use Cases For Federation
Browsers, Phones, Tablets, Clients & APIs
6/21/13
8
Copyright ©2013 Ping Identity Corporation. All rights reserved. 15 Copyright ©2013 Ping Identity Corporation. All rights reserved. 15
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML Ø Brief History of SAML • Version Changes • Interoperability • Technical Details
• Core – Profiles – Bindings
• Implementation Challenges
Copyright ©2013 Ping Identity Corporation. All rights reserved. 16
• Initial SAML 1.0 Efforts – S2ML (Security Services Markup Language) January 2000
(Netegrity) – AuthXML (December, 2000) (Securant ) – XML Trust Assertion Service Specification (X-TASS)
(VeriSign) – Information Technology Markup Language (ITML)
(Jamcracker)
• OASIS SSTC receives public input to create a unified standard in early 2001
• SAML 1.0 released November 2002 • SAML 1.1 released September 2003 • SAML 2.0 released March 2005
Version History
6/21/13
9
Copyright ©2013 Ping Identity Corporation. All rights reserved. 17
• Shibboleth – Led by Middleware Architecture Committee for Education (MACE) – Shibboleth Profile
• v1.3 Extends SAML 1.1 • Incorporated SP-Init SSO • Not compatible with SAML 1.1 implementations
– Shibboleth v2.0 is fully SAML 2.0 compliant • Liberty Alliance – Led by Sun Microsystems
– Industry backed effort to establish open standards, guidelines and best practices for identity management.
– Create specifications based on business and marketplace needs
– Liberty Identity Federation Framework (ID-FF) • ID-FF 1.1 released in April 2003 • ID-FF 1.2 released in November 2003 (submitted for SAML
2.0 inclusion)
Other Efforts from SAML 1.0
Copyright ©2013 Ping Identity Corporation. All rights reserved. 18
• WS-Federation (Passive & Active Requestor) – V1.1 (July 2003) – V1.2 (OASIS Approved July 2009) – Considered competitive to ID-FF by Liberty – Commercial vendor-backed initiative – Two modes:
• “Active” – Web Services • “Passive” – Browser SSO
– Passive utilizes HTTP GET/POST instead of SOAP messages
– Allows use of arbitrary tokens – MS Implementation of WS-Fed (only complete
implementation today) utilizes extended SAML 1.1 tokens
Other Efforts
6/21/13
10
Copyright ©2013 Ping Identity Corporation. All rights reserved. 19
SAML Timeline
Copyright ©2013 Ping Identity Corporation. All rights reserved. 20 Copyright ©2013 Ping Identity Corporation. All rights reserved. 20
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML Ø Version Changes • Interoperability • Technical Details
• Core – Profiles – Bindings
• Implementation Challenges
6/21/13
11
Copyright ©2013 Ping Identity Corporation. All rights reserved. 21
• SAML 1.0 à 1.1 – Not backwards compatible – Lots of clarity added to specification – Digital Signature support for Exclusive XML Canonicalization
v1.0 (improved DSig Interop)
• SAML 1.1 à2.0 – MAJOR changes – Not backwards compatible – Brings together the 3 major Federation efforts:
• SAML 1.1, Shibboleth Profile and ID-FF
So What Changed?
Copyright ©2013 Ping Identity Corporation. All rights reserved. 22
• Pseudonyms – Ability to create an opaque pseudo-random identifier – Separate user identities between Identity and Service
Providers – Maintain user privacy
• Identifier Management – Define how pseudonyms managed between federation
partners • Metadata
– Define standard document for exchanging configuration information to ease setup of SAML connections
• Encryption – End-to-End confidentiality of Assertions, Name Identifiers, or
attribute statements
SAML 2.0 Additions
6/21/13
12
Copyright ©2013 Ping Identity Corporation. All rights reserved. 23
• Attribute Profiles • Session Management (Single Logout)
– Allows for global logout across all service providers a user has logged into during a given session.
• Devices (Enhanced Client or Proxy) • Privacy
– Gives users the ability to express consent to a given operation being performed
• Identity Provider Discovery – Provides a mechanism for service providers to determine the
appropriate identity provider to use for a given user when more than one identity provider is part of a deployment
SAML 2.0 Additions
Copyright ©2013 Ping Identity Corporation. All rights reserved. 24 Copyright ©2013 Ping Identity Corporation. All rights reserved. 24
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes Ø Interoperability • Technical Details
• Core – Profiles – Bindings
• Implementation Challenges
6/21/13
13
Copyright ©2013 Ping Identity Corporation. All rights reserved. 25
• Annual Event to bring together software vendors to speed adoption of identity standards
• Organized/Supported by Kantara Initiative (formally Liberty Alliance) – Executed by Drummond Group Inc
• Stated goal of: – “..helping developers' to deploy with confidence, success
and minimal time and cost, and vendors to incorporate standards effectively and interoperability into their offerings.”
• Defined by SAML Conformance document – Lists all available “operator modes” that software can
execute for SAML conformance
SAML Interop Certification
Copyright ©2013 Ping Identity Corporation. All rights reserved. 26
• IdP – Identity Provider • IdP Lite – Identity Provider Lite • SP – Service Provider • SP Lite – Service Provider Lite • ECP – Enhanced Client/Proxy • SAML Attribute Authority • SAML Authorization Decision Authority • SAML Authentication Authority • SAML Requester
Operational Modes
6/21/13
14
Copyright ©2013 Ping Identity Corporation. All rights reserved. 27
IdP and SP Feature Matrix
Copyright ©2013 Ping Identity Corporation. All rights reserved. 28
Extended IdP/SP
6/21/13
15
Copyright ©2013 Ping Identity Corporation. All rights reserved. 29
SAML Authority & Requester Matrix
Copyright ©2013 Ping Identity Corporation. All rights reserved. 30 Copyright ©2013 Ping Identity Corporation. All rights reserved. 30
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes ü Interoperability Ø Technical Details
• Core – Profiles – Bindings
• Implementation Challenges
6/21/13
16
Copyright ©2013 Ping Identity Corporation. All rights reserved. 31
• Advanced Encryption Standard (AES) • RFC 2246 (TLS v1) • RFC 2617 (HTTP Auth: Basic & Digest Access
Authentication) • SSL3 • XML Encryption • XML Signature
Other Specifications within SAML
Copyright ©2013 Ping Identity Corporation. All rights reserved. 32
Specification Documents
• Defines a syntax for the definition of authentication context declarations and an initial list of authentication context classes.
AuthnContext
• Defines protocol bindings for the use of SAML assertions and request-response messages in communications protocols and frameworks.
Bindings
• Provides the technical requirements for SAML V2.0 conformance and specifies the entire set of documents comprising SAML V2.0.
Conformance
• Defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information.
Core
• Defines profiles for the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as profiles for SAML attribute value syntax and naming conventions.
Profiles
• Defines an extensible metadata format for SAML system entities, organized by roles that reflect SAML profiles.
Metadata
6/21/13
17
Copyright ©2013 Ping Identity Corporation. All rights reserved. 33
SAML Components
• Name Identifiers • Assertions • Subjects • Conditions • Statements
Core
• Redirect • SOAP • POST • Artifact • PAOS
Bindings
• Web-Browser SSO • Artifact Resolution • IDP Discovery • Single Logout • Enhance Client/Proxy SSO
Profiles
Copyright ©2013 Ping Identity Corporation. All rights reserved. 34 Copyright ©2013 Ping Identity Corporation. All rights reserved. 34
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes ü Interoperability Ø Technical Details
Ø Core – Profiles – Bindings
• Implementation Challenges
6/21/13
18
Copyright ©2013 Ping Identity Corporation. All rights reserved. 35
• Covers the “core” of SAML • Defines a syntax for the definition of authentication
context declarations and initial list of authentication context classes.
• Defines: – Common Data Types (String, URI, Time and ID/ID
Reference Values) – Schema Header and Namespaces – Request & Responses – How SAML versions are declared and processed – XML Signature Syntax and Processing – XML Encryption Syntax and Processing – SAML Extensibility – SAML-Defined Identifiers
SAML Core
Copyright ©2013 Ping Identity Corporation. All rights reserved. 36
• Assertion Query & Request • Authentication Request (AuthnRequest) • Artifact Resolution • Name Identifier Management • Single Logout • Name Identifier Mapping
SAML Core Protocols
6/21/13
19
Copyright ©2013 Ping Identity Corporation. All rights reserved. 37
Protocol Message
• What kind of message is this? • When was the message issued? • Message ID • InResponseTo (Required for some Profiles) • Destination (Required for some Profiles)
Request Type
• Who issued the message
Issuer
• How was the message signed? • What key was used? • How should the message be verified?
Signature
• Success/Failure
Status
Copyright ©2013 Ping Identity Corporation. All rights reserved. 38
• Who issued the message Issuer
• Digital Signature Info Signature
• Who is the Assertion about? Subject
• How long should the message be considered valid? • Who is the message intended for?
Conditions
• How and when was the user authenticated? Authn Statement (Advice)
• Have any authorization decisions been made for this user? Authorization Decision Statement (Advice)
• Is there any additional identity information about the user? Attribute Statement (Advice)
Assertion Structure
6/21/13
20
Copyright ©2013 Ping Identity Corporation. All rights reserved. 39
• Defines how SAML versions are declared and processed
• Signatures are defined by the XML Signature spec • Assertions and protocol messages MUST use
enveloped signatures when signing
Signature
Copyright ©2013 Ping Identity Corporation. All rights reserved. 40
Signature Sample <samlp:Response Destination="http://pf.pingsp.com:9030/sp/ACS.saml2" IssueInstant="2010-07-08T20:41:10.940Z" ID="u92mMuMlNkYjnJ1zDc75Yw0WTjq" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">pf:saml2:dev</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#u92mMuMlNkYjnJ1zDc75Yw0WTjq"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>/vB9H56PmnIxi7iCQ/UDB8GW+ic=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>I1dcu+0yKpqN3Z+9UlCazrzhBzpbndYNKiQUwOkQ0ob31EoS2lmjYR71cNLfp8R37azA8iZIv0av FGiK7xF63wLgyJWgNaY/1mSJil3iHuVOSv3f2oe0KMVdTfcas5PpTMBnJ7UEm3rmsANkx/pY7kHk lHmlUX55leahLpWWUX4=</ds:SignatureValue> </ds:Signature> [….SNIP] </samlp:Response>
6/21/13
21
Copyright ©2013 Ping Identity Corporation. All rights reserved. 41
• Defines several ways to protect confidentiality: – SSL/TLS – An entire <Assertion> element may be encrypted – The <BaseID> or <NameID> element may be encrypted – An <Attribute> element may be encrypted
• XML Encryption spec method defined for message encryption
• If Encryption & Signatures are used: – When a signed <Assertion> element is encrypted, the
signature MUST first be calculated and placed within the <Assertion> element before the element is encrypted.
– When a <BaseID>, <NameID>, or <Attribute> element is encrypted, the encryption MUST be performed first and then the signature calculated over the assertion or message containing the encrypted element.
Encryption
Copyright ©2013 Ping Identity Corporation. All rights reserved. 42
Encryption Sample – Assertion (Before) <Assertion Version="2.0" IssueInstant="2010-07-08T19:24:38.723Z" ID="O5CqTQErjwI9Yo18Mu_EM7w2ytF" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Issuer>pf:saml2:dev</Issuer> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">joe</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData NotOnOrAfter="2010-07-08T19:29:38.723Z" Recipient="http://pf.pingsp.com:9030/sp/ACS.saml2"/> </SubjectConfirmation> </Subject> <Conditions NotOnOrAfter="2010-07-08T19:29:38.723Z" NotBefore="2010-07-08T19:19:38.723Z"> <AudienceRestriction> <Audience>pf:saml2:dev</Audience> </AudienceRestriction> </Conditions> <AuthnStatement AuthnInstant="2010-07-08T19:24:38.723Z" SessionIndex="O5CqTQErjwI9Yo18Mu_EM7w2ytF"> <AuthnContext> <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion>
6/21/13
22
Copyright ©2013 Ping Identity Corporation. All rights reserved. 43
Encryption Sample – Assertion (After) <saml:EncryptedAssertion> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <ds:KeyInfo> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <xenc:CipherData> <xenc:CipherValue>idGGytcD3PW5DNEdSEiaRlquQOU9As3Bi9hxueMEoqM/HGpyUS76w2hPYyTIkEWKsEuWf+l0SifU rRL7whGzNNxppRPHsaHcSeID7uzqpVtvQTnLYm5iJc3toybnA0Osn3u1tpjJuLq1K/Qu9wFG2dup CXXMf6M201BI3DN/RPQ=</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedKey> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>MThSrXZf7nsAVnVTEWizzPwkeH7uJfDgHPdtl5of2E8Coy/JyURuF12eKi8BzYaaRjTlF9ncpdQg7EhcDtapWzuxwdvh9c34IS49OvNF2T9wSkM73ZqnH2SZIDqkxyFycIe52cw4YfbfFAxPPKdK55az07e/EopEfWHm4GRH122AqVhEThbrJLf+vlCa308n18Em9JocdcHNy2pFQ6HReBbSQehYPRRy9nXSYZ6a4qSRthJvv4xzOL+HUyqwPKR+nglHe5OHNQdvqDfq7ce4ueSR10lBvLuJXND506GBhO8DNnYYNzUUDyqy/0ICwOOfvGWJd/VHvd8YCQE8iBDjbjj6erPThonqjeWIc+FGenJM3pKDOF6lyXJ7RUOn3NrNkN4gKSCJJhcgevEmoLOwc50GmDtSo6zP/HPLC5AKQ94Z9PcI6czI9Np1JPL/SAa3CidbJdYbNTpmwBr3QGgBH2iaVlCe2uUBLCH/RUiYBPPxKKCXgys03K+X5VSywZiRx3w67jQ4eAwdIwjmry3EGEmLDsY2s1dDJTltrCEdYqPaevVUurhEb/KuoG4Fc1YMYYPbQG4dUPHQLqmX0dh1ngA56jn8Zq+etQJKLl4MXHwzJL3zVPDBRngz5yWOXzYS/ [….SNIP]]]
</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </saml:EncryptedAssertion>
Copyright ©2013 Ping Identity Corporation. All rights reserved. 44
Encryption Sample – Subject (Before) <saml:Assertion Version="2.0" IssueInstant="2010-07-08T19:33:18.315Z" ID="XF7yRaCv_PFV0pcX11lxF-wiJTx" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:Issuer>pf:saml2:dev</saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">joe</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2010-07-08T19:38:18.315Z" Recipient="http://pf.pingsp.com:9030/sp/ACS.saml2"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotOnOrAfter="2010-07-08T19:38:18.315Z" NotBefore="2010-07-08T19:28:18.315Z"> <saml:AudienceRestriction> <saml:Audience>pf:saml2:dev</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2010-07-08T19:33:18.315Z" SessionIndex="XF7yRaCv_PFV0pcX11lxF-wiJTx"> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion>
6/21/13
23
Copyright ©2013 Ping Identity Corporation. All rights reserved. 45
Encryption Sample – Subject (After) <saml:Assertion Version="2.0" IssueInstant="2010-07-08T19:33:18.315Z" ID="XF7yRaCv_PFV0pcX11lxF-wiJTx" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion”> <saml:Issuer>pf:saml2:dev</saml:Issuer>
<saml:Subject> <saml:EncryptedID> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <xenc:CipherData> <xenc:CipherValue>l0m1ZgTsRwTALrrsowhyMpvBuaaPGG5qKvbn3bbuOIAcqpbMfJRuHrK2ip6pDK8l7zDheLtgf2NL 9c1gZXzCDZzOoA44Pg773SOcbpiimrFa0m8pn7+V6x9R3RjM/igdeDOPt5ROYMmyhD23V8GP0OWy R/1e4QO53p3Cvvvw3Vc=</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedKey> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>dHdNAFtydG3ixf5vshA394cJNL4LY+59mxL/IASwqC7BoOe5Fi3twGCOsnipJUpJW/v1dV34Cwtl WoRuDoJlrZT6qLC6zJKU4TkHPxUfqnC2p4OTlkefUSQVcjhQ4pcNl0dYNr5wXeNh0EcE8/ung+K+ OLQl8Vl5c/LtI141S09J5248RHMw0lKqdZjKKFc0souCNP6k9dZu9qHXQ7fa4Q==</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </saml:EncryptedID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2010-07-08T19:38:18.315Z" Recipient="http://pf.pingsp.com:9030/sp/ACS.saml2"/> </saml:SubjectConfirmation> </saml:Subject> [….SNIP] </saml:Assertion>
Copyright ©2013 Ping Identity Corporation. All rights reserved. 46
Encryption Sample – Attribute (Before)
<saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" Name="SSN">
<saml:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">123456789</saml:AttributeValue>
</saml:Attribute> </saml:AttributeStatement> </saml:Assertion>
6/21/13
24
Copyright ©2013 Ping Identity Corporation. All rights reserved. 47
Encryption Sample – Attribute (After) <saml:AttributeStatement> <saml:EncryptedAttribute> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <xenc:CipherData> <xenc:CipherValue>ix5Y4tE5Nde59UQJNOXdYJNLdpDdq9ZuXf8rcZAdH09a2Jd3HPJzaZTQqPc1196OWkqw+r8W7gzOWCSYCdxdDKvBfXfWF4cczSk4rX9ty2/hiC+9Wp/q54ON8EjNif2+devGeTcJT5fGJ1Fta8xjmSM6 8Ub17c/UAlVtclpMkpI=</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedKey> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>o10DRbBPvu8q8ZBN3bwmIaJJtpTwiaLbQ5SXBeSmALSIC1WTDGQ3EuKYwCWHXKLk3fapRLCt99PDbYSKoWJPXAuSwvR5m1j0O6wO876LjTRG9ynrF1Ltk4UG8gUCTGMx/4BVFVl/NWB3e3cxGqqff7Sn dV27J/Z9ea/4HKUez75EGIZGgPYK6GckSUHNsWGXvFYsyyBmAV4LKYVrozPd0ecw/56Xm5XlZK+f hUGHL797CbBkp6xgpcS1Q6OwZC1TJavHr963RcGJ+mZwklP5rHGctBKgV22zis8x2M76RkCgDlpK OQVnriGAzNKakr+gR5B73MG6nEsEn1qH1YqFgugN3w4WdDqyuIa2WuYEet196dB4DWtkIi9ZCzeq r8ouei6V49Tpxrd1FSrlJFHLQ9LJu+sR+LEYe6l13dPd8IGunb7oHJjjmgw3+FeZyUrmarATy0Vq oiD7dCBlUDQipnFHaQN88wJoD+HYsyGq/jUSaMiowdYbvCYCCy5cITin</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </saml:EncryptedAttribute> </saml:AttributeStatement>
Copyright ©2013 Ping Identity Corporation. All rights reserved. 48 Copyright ©2013 Ping Identity Corporation. All rights reserved. 48
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes ü Interoperability Ø Technical Details
ü Core Ø Profiles – Bindings
• Implementation Challenges
6/21/13
25
Copyright ©2013 Ping Identity Corporation. All rights reserved. 49
• SSO Profiles – Web Browser SSO – Identity Provider Discovery – Single Logout – Enhanced Client or Proxy – Name Identifier Management
• Artifact Resolution • Assertion Query/Request • Name Identifier Mapping • Attribute Profiles
– Basic Attribute – X.500/DAP Attribute – UUID Attribute – DCE PAC Attribute – XACML Attribute
SAML Profiles
Copyright ©2013 Ping Identity Corporation. All rights reserved. 50
• “Traditional” Federation SSO use case • Allows for either IDP-Init SSO (Unsolicited) or SP-Init
SSO • Assumes the user is using a standard commercial
web browser • Utilizes SAML Authentication Request protocol in
conjunction with HTTP Redirect, HTTP POST and HTTP Artifact Bindings
Web Browser SSO
6/21/13
26
Copyright ©2013 Ping Identity Corporation. All rights reserved. 51
Create Session With Identity
SAML Response In HTTP POST
SAML Explained: Web SSO
• User connects directly to cloud application
Identity Look-up
SAML Response In Form
Redirect to Application
With Session
• User is redirected to Application’s Federation Server
• Federation server redirects user to PingFederate with an AuthnRequest
• A SAML assertion is generated and returned in an HTML form
• The SAML assertion is posted to the federation server at the cloud application
• The federation server consumes the SAML assertions and notifies the application to create an authenticated session
• The user is redirected to the cloud application with an authenticated session.
Request Application
Redirect to Federation
Server
Redirect to PingFederate
With AuthnRequest
• User authenticates
Authentication Challenge Credentials
Better known as SP initiated, using POST.
Copyright ©2013 Ping Identity Corporation. All rights reserved. 52
Create Session With Identity
SAML Response In HTTP POST
SAML Explained: Web SSO (Unsolicited)
• User requests to connect to cloud application
Request Application
Identity Look-up
Redirect to PingFederate
SAML Response In Form
Redirect to Application
With Session
• User is redirected to PingFederate
• PingFederate validates the user’s identity
• A SAML assertion is generated and returned in an HTML form
• The SAML assertion is posted to the federation server at the cloud application
• The federation server consumes the SAML assertions and notifies the application to create an authenticated session
• The user is redirected to the cloud application with an authenticated session.
Better known as IdP initiated, using POST.
6/21/13
27
Copyright ©2013 Ping Identity Corporation. All rights reserved. 53
• Notable checks for Service Provider: – All signatures must be valid – Verify timestamps (NotBefore/NotOnOrAfter) – InResponseTo attribute equals the ID of the original
AuthnRequest – Assertion has not been replayed – Recipient attribute in <SubjectConfirmationData> matches
ACS URL to which <Response> or Artifact was delivered
Web SSO - <Response> Processing Rules
Copyright ©2013 Ping Identity Corporation. All rights reserved. 54
• Notable checks for Identity Provider: – All signatures must be valid – Verify timestamps (NotBefore/NotOnOrAfter) – InResponseTo attribute must be included in the <Response> – If the <AuthnRequest> is not authenticated and/or integrity
protected the information in it MUST NOT be trusted except as advisory.
– The identity provider MUST ensure that any <AssertionConsumerServiceURL> or <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service provider to whom the response will be sent.
Web SSO - <AuthnRequest> Processing Rules
6/21/13
28
Copyright ©2013 Ping Identity Corporation. All rights reserved. 55
• Artifact Resolution protocol is defined in SAML Core Spec Document
• Artifact Resolution Profile uses the Artifact Resolution protocol + HTTP Artifact binding
Artifact Resolution Profile
Copyright ©2013 Ping Identity Corporation. All rights reserved. 56
Create Session With Identity
Artifact In HTTP POST
SAML Explained: IdP Initiated SSO - Artifact
• User requests to connect to cloud application
Request Application
Identity Look-up
Redirect to PingFederate
Retrieve SAML by SOAP
Artifact In Form
Redirect to Application
With Session
• User is redirected to PingFederate
• PingFederate validates the user’s identity
• The artifact is posted to the federation server.
• The SAML assertion is generated and stored in PingFederate. An artifact is returned in an HTML form.
• The federation server calls back to PingFederate to retrieve the SAML assertion.
• The user is redirected to the cloud application with an authenticated session.
• The SAML assertion is consumed and used to create an authenticated session at the cloud application.
6/21/13
29
Copyright ©2013 Ping Identity Corporation. All rights reserved. 57
• Synchronous binding is required (SOAP) SP • Requester should authenticate to IdP by signing the
<ArtifactResolve> or via any binding-supported mechanism
• Responded MUST authenticate itself to requester (usually by signing the <ArtifactResponse>
Artifact Processing Rules
Copyright ©2013 Ping Identity Corporation. All rights reserved. 58
• Leverages the use of a “common cookie” ("_saml_idp”)
• All participants must be part of the same domain (.[common-domain]) to be able to read/write to cookie
• The common domain cookie: – May be session-only or persistent – Contains list of IdP IDs – IDs are Base64 encoded first then entire list is URL
encoded.
Identity Provider Discovery Profile
6/21/13
30
Copyright ©2013 Ping Identity Corporation. All rights reserved. 59
• Defines a mechanism in which a principal may terminate their session at the IdP (session authority) as well as all SP sessions (session participant) in which the IdP is managing
• IDP-Init and SP-Init SLO use cases defined • Front (Redirect, POST, Artifact) and back-channel
(SOAP) bindings are defined • Front-channel bindings are recommended since most
sessions are stored via the browser
Single Logout Profile
Copyright ©2013 Ping Identity Corporation. All rights reserved. 60
Single Logout (Unsolicited)
SP 2
Identity Provider
SP 1
User requests logout from SP2
SP 2 terminates local session
<LogoutRequest> issued by SP 2
IdP determines other SPs
<LogoutRequest> issued by IdP
SP 1 terminates local session
<LogoutResponse> issued by SP 1
<LogoutResponse> returned by IdP
6/21/13
31
Copyright ©2013 Ping Identity Corporation. All rights reserved. 61
• <LogoutRequest> – Must be signed for HTTP POST or Redirect (Artifact/SOAP
allows Binding Authentication only) – SP message MUST contain <SessionIndex> (may omit for
IdP) – Issuer MUST be present
• <LogoutResponse> – Issuer MUST be present – Must be signed for HTTP POST or Redirect (Artifact/SOAP
allows Binding Authentication only)
SLO Processing Rules
Copyright ©2013 Ping Identity Corporation. All rights reserved. 62
• Specifies communication between enhanced clients or proxies and IdPs/SPs
• An ECP: – Knows how to obtain appropriate IdP info with regard to SP – Supports reverse SOAP (PAOS)
• Enhanced Client: may be a browser or user agent • Enhanced Proxy: HTTP proxy (ie, WAP gateway) the
emulates enhanced client • Profile applies to EC/EP equally
Enhanced Client or Proxy (ECP) Profile
6/21/13
32
Copyright ©2013 Ping Identity Corporation. All rights reserved. 63
ECP
3. ECP Determines IDP to use
1. ECP requests access to resource at SP
2. <AuthnRequest> issued by SP using POAS (HTTP Response)
4. ECP sends <AuthnRequest> to IDP via SAML SOAP
5. IDP Authenticates user (out of scope)
6. IDP issues <Response> to ECP via SAML SOAP
7. ECP sends <Response> to SP using POAS (HTTP POST)
8. SP returns the resource or error (HTTP) in HTTP Response
ECP SP IdP
Copyright ©2013 Ping Identity Corporation. All rights reserved. 64 Copyright ©2013 Ping Identity Corporation. All rights reserved. 64
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes ü Interoperability Ø Technical Details
ü Core ü Profiles Ø Bindings
• Implementation Challenges
6/21/13
33
Copyright ©2013 Ping Identity Corporation. All rights reserved. 65
• Allows protocol messages to be transmitted within URL parameters
• URL length is theoretically infinite but limited in practice (web servers & browsers)
• Not recommended for transmission of Assertion data due to URL length – SLO, AuthnRequest, and Artifact messages are most
common using HTTP Redirect
• Endpoints MUST support the DEFLATE compression method (RFC 1951)
• More in SAML “Bindings” Doc Sect 3.4
HTTP Redirect Binding
Copyright ©2013 Ping Identity Corporation. All rights reserved. 66
HTTP Redirect Binding Example
<AuthnRequest IssueInstant="2010-06-17T14:10:35.125Z” ID="tZVMOWVaoGOUh_fFjwllXTeMlYT" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion”><saml:Issuer>pf:saml2:dev</saml:Issuer><NameIDPolicy AllowCreate="true"/></AuthnRequest>
Message Output https://idp.server.com/ssoendpoint?
SAMLRequest=fZDBTsMwEER%2FxfK9rR1akFZJpIiKKlJDEaQBekFW2KqpHDt4bQp%2Fj0kv5cL9vZnZTUn1eoAi%2BIN5xI%2BA5FlJFLA05JXxGU%2BEFBNxPZE3tZyDFHC1mMpkseOsXGbc75pq89wou9psD2%2F7u%2BNJ65caK%2F1ac9ago86amDEVnH312hCMfRkPzoBV1BEY1SOBb%2BGpqNYQSRic9ba1mufpLw3jHnfh%2F68rInQ%2B9vJ82I98Au%2F4mc4uws7JA9xHu1w%2BWN2136zQ2p5uHSqP8TAXkM%2Fys%2FX3QfkP&RelayState=<URL Encoded>
Protocol Message
6/21/13
34
Copyright ©2013 Ping Identity Corporation. All rights reserved. 67
• Defines how protocol messages may be transmitted within a Base64 encoded HTML form [HTML401] Section 17
• No restriction on recommended protocol message types
• Not typically limited by user agent • More in SAML “Bindings” Doc Sect 3.5
HTTP Post Binding
Copyright ©2013 Ping Identity Corporation. All rights reserved. 68
HTTP Post Binding Example
Protocol Message
<AuthnRequest IssueInstant="2010-06-17T15:02:06.923Z" ID="WvhjWtL2Dz4sPVTnuqnxXdeLW1L" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer>pf:saml2:dev</saml:Issuer>
<NameIDPolicy AllowCreate="true"/>
</AuthnRequest>
Message Output <html> <head><title>Submit Form</title></head> <body onload="javascript:document.forms[0].submit()"> <form method="post" action="https://idp.server.com/ssoendpoint"> <input type="hidden" name="SAMLRequest" value="PHNhbWxwOkF1dGhuUmVxdWVzdCBJc3N1ZUluc3RhbnQ9IjIwMTAtMDYtMTdUMTU6MDI6MDYuOTIzWiIgSUQ9Ild2aGpXdEwyRHo0c1BWVG51cW54WGRlTFcxTCIgVmVyc2lvbj0iMi4wIiB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+cGY6c2FtbDI6ZGV2PC9zYW1sOklzc3Vlcj48c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3JlYXRlPSJ0cnVlIi8+PC9zYW1scDpBdXRoblJlcXVlc3Q+"/> <input type="hidden" name="RelayState" value="RaAeQlq5X5vE7W2akrF7ynW2fslMW8"/> <noscript><input type="submit" value="Resume"/></noscript> </form> </body> </html>
6/21/13
35
Copyright ©2013 Ping Identity Corporation. All rights reserved. 69
• Defines how to send/receive SAML requests and responses
• Only supports SOAP 1.1 • SAML protocol messages *MUST* be enclosed within
SOAP message body • Conformance to SOAP Binding requires SAML over
SOAP over HTTP • More in SAML “Bindings” Doc Sect 3.2
SAML SOAP Binding
Copyright ©2013 Ping Identity Corporation. All rights reserved. 70
SOAP Binding Example
Protocol Message
<samlp:ArtifactResolve IssueInstant="2010-07-09T15:47:01.459Z" ID="FPiM_AHllAVj1cTAx2Ym-5Ptk_T" Version="2.0" xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol”>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">pf:saml2:dev</saml:Issuer>
<samlp:Artifact>AAQAAFSrmHm5JrjWYQ3cyTcwdOFaQRusm9QjjfvSoNuN/I37nOdSZDISWz4=</samlp:Artifact>
</samlp:ArtifactResolve>
Message Output <S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">
<S11:Body> <samlp:ArtifactResolve IssueInstant="2010-07-09T15:47:01.459Z" ID="FPiM_AHllAVj1cTAx2Ym-5Ptk_T" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">pf:saml2:dev</saml:Issuer>
<samlp:Artifact>AAQAAFSrmHm5JrjWYQ3cyTcwdOFaQRusm9QjjfvSoNuN/I37nOdSZDISWz4=</samlp:Artifact>
</samlp:ArtifactResolve> </S11:Body> </S11:Envelope>"
6/21/13
36
Copyright ©2013 Ping Identity Corporation. All rights reserved. 71
• Designed for use in cases where the browser is the intermediary
• Most commonly used when browser has technical limitations to carry entire message or the IdP & SP do not want to expose the message content to the intermediary (w/out using encryption
• More in SAML “Bindings” Doc Sect 3.6
HTTP Artifact Binding
Copyright ©2013 Ping Identity Corporation. All rights reserved. 72
HTTP Artifact Format
SAML_artifact := B64(TypeCode EndpointIndex RemainingArtifact)
TypeCode := Byte1Byte2
EndpointIndex := Byte1Byte2
TypeCode := 0x0004
RemainingArtifact := SourceID MessageHandle
SourceID := 20-byte_sequence
MessageHandle := 20-byte_sequence
6/21/13
37
Copyright ©2013 Ping Identity Corporation. All rights reserved. 73
HTTP Artifact Binding Example
Artifact via Redirect
SAMLart=AAQAAFSrmHm5JrjWYQ3cyTcwdOFaQRusm9QjjfvSoNuN/I37nOdSZDISWz4=
ArtifactResolve via SOAP
<samlp:ArtifactResolve IssueInstant="2010-07-09T15:47:01.459Z" ID="FPiM_AHllAVj1cTAx2Ym-5Ptk_T" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">pf:saml2:dev</saml:Issuer><samlp:Artifact>AAQAAFSrmHm5JrjWYQ3cyTcwdOFaQRusm9QjjfvSoNuN/I37nOdSZDISWz4=</samlp:Artifact></samlp:ArtifactResolve>
Copyright ©2013 Ping Identity Corporation. All rights reserved. 74 Copyright ©2013 Ping Identity Corporation. All rights reserved. 74
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes ü Interoperability ü Technical Details
ü Core ü Profiles ü Bindings
Ø Implementation Challenges
6/21/13
38
Copyright ©2013 Ping Identity Corporation. All rights reserved. 75
• Identifier collisions • Build vs. Buy • IdP Discovery • Legal • Remote vs Network access (ditch the VPN) • Continued use of local accounts • Provisioning
Common Implementation Challenges
Copyright ©2013 Ping Identity Corporation. All rights reserved. 76
• Active Federation – Oauth 2.0 – WS-Trust
• Other Passive Federation Protocols – WS-Federation
• Authorization – XACML
Expanded Uses of SAML
6/21/13
39
Copyright ©2013 Ping Identity Corporation. All rights reserved. 77
• SAML (protocol) and WS-Federation are examples of “passive” federation – Requests and responses are embedded into
HTTP web activities to enable token travel • OAuth and WS-Security are examples of
“active” federation – A web services client must programmatically
request the issuance or validation of the token and then decide what to do with that token
Active and Passive Federation
Copyright ©2013 Ping Identity Corporation. All rights reserved. 78
• OAuth is evolving into the WS-Security of the REST world • OAuth enables delegation of access or authentication
without sharing passwords • OAuth 1.0a is the old standard still in use
– Focused on granting authorization to 3rd party services, – authentication was not in scope – mostly web-based – 3-legged involves user, used for initial permission – 2-legged is passive, used for subsequent activity
• OAuth 2.0 is the current standard approved at IETF – Much broader scope, multiple profiles – Includes desktop clients, devices – Authentication is now an integral part of the spec – Work underway to profile SAML tokens for use with Oauth
Expanded Uses - OAuth
6/21/13
40
Copyright ©2013 Ping Identity Corporation. All rights reserved. 79
• WS-Trust is part of the WS-* suite of XML protocols
• WS-Trust is used to programmatically ask for and validate a token
– SAML tokens most common target • A critical part of web services/SOA
security – Tokens “transformed” through the
issue/validate process – Allows delegation without
password sharing
Expanded Uses – WS-Trust
STS STS
Java or .NET Application
STS Client SDK
ExistingSecurityToken
NewSecurityToken
NewSAML
Assertion
Copyright ©2013 Ping Identity Corporation. All rights reserved. 80
• WS-Federation is also part of the WS-* suite of XML protocols
– Takes WS-Trust active federation and embeds it into an HTTP exchange to accomplish browser single sign-on
– The same SAML tokens are communicated, just via a different envelope
• WS-Federation is the default SSO protocol for federation at Microsoft
– Microsoft products that are federation enabled use WS-Federation, not SAML
– Heavy .NET support for WS-Federation
• WS-Federation is primarily RP-initiated
– Users generally go to the Relying Party first
Expanded Uses – WS-Federation
6/21/13
41
Copyright ©2013 Ping Identity Corporation. All rights reserved. 81
• XACML adds specification and enforcement of policy on top of federated authentication requests – Standard language describing actions and consequences – Enforcement Points, Decision Points, and Administration
Points each have roles – Enables federated authorization, delegation, and obligation
Expanded Uses - XACML
Copyright ©2013 Ping Identity Corporation. All rights reserved. 82 Copyright ©2013 Ping Identity Corporation. All rights reserved. 82
Bootcamp Agenda
ü What and Why of SAML? ü Benefits and Use Cases for SAML ü Brief History of SAML ü Version Changes ü Interoperability ü Technical Details
ü Core ü Profiles ü Bindings
ü Implementation Challenges
6/21/13
42
Copyright ©2013 Ping Identity Corporation. All rights reserved. 83
• Configuring SSO Using SAML – Salesforce as Service Provider – PingFederate as Identity Provider
Demonstration of Bootcamp Exercise
Copyright ©2013 Ping Identity Corporation. All rights reserved. 84
• Now your turn!!
Bootcamp Exercise