Step Up Authenticationin SAML
(and XACML)
Hal Lockhart
February 6, 2014
Outline
SAML Overview Authentication Assertions & Protocols Features relevant to step up AuthN SSO Flows Other relevant SAML Profiles Using XACML to decide that step up
is needed
SAML 2.0 – Brief History
SAML 2.0 - OASIS Standard - March 2005 ITU-T Rec. X.1141 – June 2006 Work since 2005 has consisted of defining
additional Profiles 30+ Documents have reached OS or CS A few corrections, mostly new usecases built on
existing features of core
SAML 2.0 Specifications Conformance
Requirements Required “Operational
Modes” for SAML implementations
Assertions and Protocols The “Core” specification
Bindings Maps SAML messages
onto common communications protocols
Profiles “How-to’s” for using SAML
to solve specific business problems
MetadataConfiguration data for
establishing connections between SAML entities
Authentication ContextDetailed descriptions of user authentication mechanisms
Security and Privacy ConsiderationsSecurity and privacy analysis of SAML 2.0
GlossaryTerms used in SAML 2.0
SAML components and how they relate to each other
ProfilesCombinations of assertions, protocols,
and bindings to support a defined use case(also attribute profiles)
BindingsMappings of SAML protocolsonto standard messaging and
communication protocols
ProtocolsRequests and responses for
obtaining assertions and doingidentity management
AssertionsAuthentication, attribute, and
entitlement information
MetadataConfiguration data for
identity and service providers
Authentication ContextDetailed data on types
and strengths of authentication
SAML assertions
Assertions are declarations of fact, according to someone
SAML assertions are compounds of one or more of three kinds of “statement” about “subject” (human or program):
Authentication Attribute Authorization decision (obsolete)
You can extend SAML to make your own kinds of assertions and statements
Assertions can be digitally signed
All statements in an assertion share common information
Issuer ID and issuance timestamp Assertion ID Subject
Name plus the security domain Optional subject confirmation, e.g. public key
“Conditions” under which assertion is valid SAML clients must reject assertions containing
unsupported conditions Special kind of condition: assertion validity period
Additional “advice” E.g., to explain how the assertion was made
Authentication Statement Indicates Issuer Authenticated Subject
details how and when Contains:
AuthN time (Req) Session index (Opt) Session end (Opt) AuthN Location (Opt)
IP Address or DNS Name AuthN Context (Req)
Details of AuthN Method
Authentication context classes
Internet Protocol Internet Protocol Password Kerberos Mobile One Factor Unregistered Mobile Two Fa1ctor Unregistered Mobile One Factor Contract Mobile Two Factor Contract Password Password Protected Transport Previous Session Public Key – X.509 Public Key – PGP Public Key – SPKI
Public Key – XML Signature Smartcard Smartcard PKI Software PKI Telephony Nomadic Telephony Personalized Telephony Authenticated Telephony Secure Remote Password SSL/TLS Cert-Based Client
Authentication Time Sync Token Unspecified
SAML comes with a healthy set of predefined identifiers fortypical authentication scenarios:
You can also create or customize your own authentication contextclasses...
Attribute statement
An issuing authority asserts that subject S is associated with attributes A, B, … with values “a”, “b”, “c”…
Useful for distributed transactions and authorization services
Typically this would be gotten from an LDAP repository
“john.doe” in “example.com” is associated with attribute “Department” with value “Human Resources”
SAML Protocol Reqs/Resps Assertion Queries & Requests Authentication Request Artifact Resolution Name Identifier Resolution Single Logout Name Identifier Mapping
Authentication Request
Subject (Opt) Conditions (Opt) Requested AuthN Context (Opt)
Context & Comparison(exact, minimum, better or maximum)
Force AuthN (Opt) [default: false] Is Passive (Opt) [default: false] Protocol Binding More …
Single-Sign On Browser-driven SSO
Form POST, SAML Artifact Profiles Note: conformant implementations must implement both
profiles Assertions may contain attribute statements
SAML 2.0 introduces notion of attribute profile All or certain parts of an assertion may be encrypted
Important when security intermediaries are involved SSO for enhanced client
Enhanced client is a device that understands HTTP but not SOAP
Also has “built in” knowledge of identity provider Examples
HTTP proxies such as a WAP gateway Consumer device with HTTP client
SP-initiated flow with redirect and POST bindings
Browser
Service Providerwww.abc.com
Resource
Identity Providerwww.xyz.com
SingleSign-OnService
AssertionConsumer
Service
Accesscheck
User or UA action
User or UA action
Accessresource
Supplyresource
GET using<AuthnRequest>
7
1
3
Challengefor
credentials
Userlogin
4
Signed<Response>in HTML form
5
Redirect with<AuthnRequest>
2
POST signed<Response>
6
IdP-initiated flow with the POST binding
Browser
Service Providerwww.abc.com
Resource
Identity Providerwww.xyz.com
SingleSign-OnService
AssertionConsumer
Service
User or UA action
Supplyresource
7 1
Challengefor
credentials
Userlogin
2
Signed<Response>in HTML form
4
POST signed<Response>
5 3
Accesscheck
Selectremote
resource
Step Up Authentication
Usecase User is signed in with weak mechanism User requests admin function Policy requires stronger AuthN New signon required; request granted
Not really a special case for SAML Normal SSO – request stronger AuthN
with Requested AuthN Context
Other relevant SAML Profiles
Identity Assurance Profiles (1 doc) Lets IdP or SP express or request a
level of assurance (LOA) associated with an AuthN method
Lets IdP advertise ability to Authenticate at some LOA
SP Request Initiation Profile Lets Browser request SP issue AuthN
Request for some particular method
What is XACML?
XML language for access control Coarse or fine-grained Extremely powerful evaluation logic Ability to use any available information Superset of Permissions, ACLs, RBAC, etc Scales from PDA to Internet Federated policy administration OASIS and ITU-T Standard
Determining the Need to Authenticate XACML decision can be: Permit, Deny,
Not Applicable & Indeterminate If attributes are missing which policy
says must be present, PDP returns Indeterminate
Missing Attributes detail includes: Attr Id, Category, Issuer (Opt), Value (Opt)
Can indicate need for Step Up AuthN
General SAML Observations
SAML has many Assertion & Protocol features not profiled
New features generally require a champion (not necessarily an expert)
Profiles can be written by SS TC or elsewhere: e.g., FICAM Profiles
SS TC will provide expertise
Questions?