Step Up Authenticationin SAML

(and XACML)

Hal LockhartFebruary 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

ServiceAccesscheck

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?