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