cis13: bootcamp: ping identity saml in action with pingfederate hands-on

6/21/13

1

Copyright ©2013 Ping Identity Corporation. All rights reserved. 1

Bootcamp: Ping Identity PingFederate SAML Hands-On


•  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


•  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


•  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)


•  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


•  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?


•  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


•  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


Bootcamp Agenda

ü What and Why of SAML? Ø Benefits and Use Cases for SAML •  Brief History of SAML •  Version Changes •  Interoperability •  Technical Details



6/21/13

6


•  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)


•  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


•  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


PingFederate Use Cases For Federation

Browsers, Phones, Tablets, Clients & APIs

6/21/13

8


Bootcamp Agenda

ü What and Why of SAML? ü  Benefits and Use Cases for SAML Ø Brief History of SAML •  Version Changes •  Interoperability •  Technical Details




•  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


•  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


•  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


SAML Timeline


Bootcamp Agenda

ü What and Why of SAML? ü  Benefits and Use Cases for SAML ü  Brief History of SAML Ø Version Changes •  Interoperability •  Technical Details



6/21/13

11


•  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?


•  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


•  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


Bootcamp Agenda

ü What and Why of SAML? ü  Benefits and Use Cases for SAML ü  Brief History of SAML ü  Version Changes Ø  Interoperability •  Technical Details



6/21/13

13


•  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


•  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


IdP and SP Feature Matrix


Extended IdP/SP

6/21/13

15


SAML Authority & Requester Matrix


Bootcamp Agenda

ü What and Why of SAML? ü  Benefits and Use Cases for SAML ü  Brief History of SAML ü  Version Changes ü  Interoperability Ø  Technical Details



6/21/13

16


•  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


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


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


Bootcamp Agenda


Ø Core –  Profiles –  Bindings


6/21/13

18


•  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


•  Assertion Query & Request •  Authentication Request (AuthnRequest) •  Artifact Resolution •  Name Identifier Management •  Single Logout •  Name Identifier Mapping

SAML Core Protocols

6/21/13

19


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


•  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


•  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


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


•  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


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


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>


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


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>


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


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>


Bootcamp Agenda


ü Core Ø Profiles –  Bindings


6/21/13

25


•  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


•  “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


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.



SAML Response In HTTP POST

SAML Explained: Web SSO (Unsolicited)

•  User requests to connect to cloud application

Request Application

Identity Look-up


SAML Response In Form


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


Better known as IdP initiated, using POST.

6/21/13

27


•  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


•  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


•  Artifact Resolution protocol is defined in SAML Core Spec Document

•  Artifact Resolution Profile uses the Artifact Resolution protocol + HTTP Artifact binding

Artifact Resolution Profile



Artifact In HTTP POST

SAML Explained: IdP Initiated SSO - Artifact

•  User requests to connect to cloud application

Request Application

Identity Look-up


Retrieve SAML by SOAP

Artifact In Form


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 SAML assertion is consumed and used to create an authenticated session at the cloud application.

6/21/13

29


•  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


•  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


•  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


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


•  <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


•  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


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


Bootcamp Agenda


ü Core ü Profiles Ø Bindings


6/21/13

33


•  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


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


•  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


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


•  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


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


•  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


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


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>


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


•  Identifier collisions •  Build vs. Buy •  IdP Discovery •  Legal •  Remote vs Network access (ditch the VPN) •  Continued use of local accounts •  Provisioning

Common Implementation Challenges


•  Active Federation –  Oauth 2.0 –  WS-Trust

•  Other Passive Federation Protocols –  WS-Federation

•  Authorization –  XACML

Expanded Uses of SAML

6/21/13

39


•  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


•  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


•  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


•  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


•  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


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


•  Configuring SSO Using SAML –  Salesforce as Service Provider –  PingFederate as Identity Provider

Demonstration of Bootcamp Exercise


•  Now your turn!!

Bootcamp Exercise