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?
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
•  Core
–  Profiles
–  Bindings

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
ü  Benefits and Use Cases for SAML
Ø  Brief History of SAML
•  Core
–  Profiles
–  Bindings
•  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
ü  Brief History of SAML
Ø  Version Changes
•  Core
–  Profiles
–  Bindings

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
ü  Version Changes
Ø  Interoperability
•  Core
–  Profiles
–  Bindings

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
ü  Interoperability
Ø  Technical Details
•  Core
–  Profiles
–  Bindings

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)
•  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/
JyURuF12eKi8BzYaaRjTlF9ncpdQg7EhcDtapWzuxwdvh9c34IS49OvNF2T9wSkM73ZqnH2SZIDqkxyFycIe52cw4YfbfFAx
PPKdK55az07e/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#">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xenc:CipherData>
<xenc:CipherValue>l0m1ZgTsRwTALrrsowhyMpvBuaaPGG5qKvbn3bbuOIAcqpbMfJRuHrK2ip6pDK8l7zDheLtgf2NL
9c1gZXzCDZzOoA44Pg773SOcbpiimrFa0m8pn7+V6x9R3RjM/igdeDOPt5ROYMmyhD23V8GP0OWy
R/1e4QO53p3Cvvvw3Vc=</xenc:CipherValue>
</xenc:CipherData>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>dHdNAFtydG3ixf5vshA394cJNL4LY+59mxL/IASwqC7BoOe5Fi3twGCOsnipJUpJW/v1dV34Cwtl
WoRuDoJlrZT6qLC6zJKU4TkHPxUfqnC2p4OTlkefUSQVcjhQ4pcNl0dYNr5wXeNh0EcE8/ung+K+
OLQl8Vl5c/LtI141S09J5248RHMw0lKqdZjKKFc0souCNP6k9dZu9qHXQ7fa4Q==</xenc:CipherValue>
</xenc:CipherData>
</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#">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xenc:CipherData>
<xenc:CipherValue>ix5Y4tE5Nde59UQJNOXdYJNLdpDdq9ZuXf8rcZAdH09a2Jd3HPJzaZTQqPc1196OWkqw
+r8W7gzOWCSYCdxdDKvBfXfWF4cczSk4rX9ty2/hiC+9Wp/q54ON8EjNif2+devGeTcJT5fGJ1Fta8xjmSM6
8Ub17c/UAlVtclpMkpI=</xenc:CipherValue>
</xenc:CipherData>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>o10DRbBPvu8q8ZBN3bwmIaJJtpTwiaLbQ5SXBeSmALSIC1WTDGQ3EuKYwCWHXKLk3fap
RLCt99PDbYSKoWJPXAuSwvR5m1j0O6wO876LjTRG9ynrF1Ltk4UG8gUCTGMx/4BVFVl/NWB3e3cxGqqff7Sn
dV27J/Z9ea/4HKUez75EGIZGgPYK6GckSUHNsWGXvFYsyyBmAV4LKYVrozPd0ecw/56Xm5XlZK+f
hUGHL797CbBkp6xgpcS1Q6OwZC1TJavHr963RcGJ+mZwklP5rHGctBKgV22zis8x2M76RkCgDlpK
OQVnriGAzNKakr+gR5B73MG6nEsEn1qH1YqFgugN3w4WdDqyuIa2WuYEet196dB4DWtkIi9ZCzeq
r8ouei6V49Tpxrd1FSrlJFHLQ9LJu+sR+LEYe6l13dPd8IGunb7oHJjjmgw3+FeZyUrmarATy0Vq
oiD7dCBlUDQipnFHaQN88wJoD+HYsyGq/jUSaMiowdYbvCYCCy5cITin</xenc:CipherValue>
</xenc:CipherData>
</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
•  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
ChallengeCredentials
Better known as SP initiated, using POST.
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
PingFederate
•  PingFederate
validates the user’s
identity
•  A SAML assertion is
generated and
returned in an HTML
form
posted to the
federation server at
the cloud application
consumes the SAML
assertions and
notifies the
application to create
an authenticated
session
to the cloud
application with 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
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
PingFederate
•  PingFederate
validates the user’s
identity
•  The artifact is posted
to the federation
server.
generated and stored
in PingFederate. An
artifact is returned in
an HTML form.
calls back to
PingFederate to
retrieve the SAML
assertion.
to the cloud
application with an
authenticated
session.
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
<LogoutRequ
est> issued by
SP 2
IdP
determi
nes
other
SPs
<LogoutRequ
est> issued by
IdP
SP 1
terminates
local
session
<LogoutRespo
nse> issued by
SP 1
<LogoutRespo
nse> 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
%2FxfK9rR1akFZJpIiKKlJDEaQBekF
W2KqpHDt4bQp
%2Fj0kv5cL9vZnZTUn1eoAi%2BIN5xI
%2BA5FlJFLA05JXxGU
%2BEFBNxPZE3tZyDFHC1mMpkseO
sXGbc75pq89wou9psD2%2F7u
%2BNJ65caK
%2F1ac9ago86amDEVnH312hCMfRk
PzoBV1BEY1SOBb
%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
HTTP Post Binding
HTTP Post Binding Example
Protocol Message
<AuthnRequest
IssueInstant="2010-06-17T15:0
2:06.923Z"
ID="WvhjWtL2Dz4sPVTnuqnxXdeLW
1L" Version="2.0"
xmlns="urn:oasis:names:tc:SAM
L:2.0:protocol"
xmlns:saml="urn:oasis:names:t
c: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="PHNhbWxwOkF1dGhuUmVxdWVzdCBJc3N1Z
Uluc3RhbnQ9IjIwMTAtMDYtMTdUMTU6MDI6MDYuOTI
zWiIgSUQ9Ild2aGpXdEwyRHo0c1BWVG51cW54WGRl
TFcxTCIgVmVyc2lvbj0iMi4wIiB4bWxuczpzYW1scD0id
XJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3
RvY29sIj48c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0idXJ
uOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2V
ydGlvbiI
+cGY6c2FtbDI6ZGV2PC9zYW1sOklzc3Vlcj48c2FtbHA
6TmFtZUlEUG9saWN5IEFsbG93Q3JlYXRlPSJ0cnVlIi8
+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
SAML SOAP Binding
SOAP Binding Example
Protocol Message
<samlp:ArtifactResolve
IssueInstant="2010-07-09T15:47:01.45
9Z" 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>AAQAAFSrmHm5JrjWYQ3cy
TcwdOFaQRusm9QjjfvSoNuN/
I37nOdSZDISWz4=</samlp:Artifact>
</samlp:ArtifactResolve>
Message Output
<S11:Envelope xmlns:S11="http://
schemas.xmlsoap.org/soap/envelope/">
<S11:Body>
IssueInstant="2010-07-09T15:47:01.45
9Z" 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:
saml:Issuer>
<samlp:Artifact>AAQAAFSrmHm5JrjWYQ3cy
TcwdOFaQRusm9QjjfvSoNuN/
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
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=AAQAAFSrmHm5JrjWYQ3cyTcwd
OFaQRusm9QjjfvSoNuN/
I37nOdSZDISWz4=
ArtifactResolve via SOAP
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:
saml:Issuer><samlp:Artifact>AAQ
AAFSrmHm5JrjWYQ3cyTcwdOFaQRusm9
QjjfvSoNuN/I37nOdSZDISWz4=</
samlp:Artifact></
samlp:ArtifactResolve>
Bootcamp Agenda
ü  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
Existing
Security
Token
New
Security
Token
New
SAML
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
ü  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

CIS13: Bootcamp: Ping Identity SAML in Action with PingFederate Hands-On

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CIS13: Bootcamp: Ping Identity SAML in Action with PingFederate Hands-On

Similar to CIS13: Bootcamp: Ping Identity SAML in Action with PingFederate Hands-On (20)

More from CloudIDSummit

More from CloudIDSummit (20)

Recently uploaded

Recently uploaded (20)

CIS13: Bootcamp: Ping Identity SAML in Action with PingFederate Hands-On