Step Up Authentication in SAML (and XACML) Hal Lockhart February 6, 2014

Outline n SAML Overview n Authentication Assertions & Protocols n Features relevant to step up AuthN n SSO Flows n Other relevant SAML Profiles n Using XACML to decide that step up is needed

SAML 2.0 – Brief History n SAML OASIS Standard - March 2005 n ITU-T Rec. X.1141 – June 2006 n Work since 2005 has consisted of defining additional Profiles l 30+ Documents have reached OS or CS l A few corrections, mostly new usecases built on existing features of core

SAML 2.0 Specifications n Conformance Requirements l Required “Operational Modes” for SAML implementations n Assertions and Protocols l The “Core” specification n Bindings l Maps SAML messages onto common communications protocols n Profiles l “How-to’s” for using SAML to solve specific business problems n Metadata l Configuration data for establishing connections between SAML entities n Authentication Context l Detailed descriptions of user authentication mechanisms n Security and Privacy Considerations l Security and privacy analysis of SAML 2.0 n Glossary l Terms used in SAML 2.0

SAML components and how they relate to each other Profiles Combinations of assertions, protocols, and bindings to support a defined use case (also attribute profiles) Bindings Mappings of SAML protocols onto standard messaging and communication protocols Protocols Requests and responses for obtaining assertions and doing identity management Assertions Authentication, attribute, and entitlement information Metadata Configuration data for identity and service providers Authentication Context Detailed data on types and strengths of authentication

SAML assertions n Assertions are declarations of fact, according to someone n SAML assertions are compounds of one or more of three kinds of “statement” about “subject” (human or program): l Authentication l Attribute l Authorization decision (obsolete) n You can extend SAML to make your own kinds of assertions and statements n Assertions can be digitally signed

All statements in an assertion share common information n Issuer ID and issuance timestamp n Assertion ID n Subject l Name plus the security domain l Optional subject confirmation, e.g. public key n “Conditions” under which assertion is valid l SAML clients must reject assertions containing unsupported conditions l Special kind of condition: assertion validity period n Additional “advice” l E.g., to explain how the assertion was made

Authentication Statement n Indicates Issuer Authenticated Subject details how and when n Contains: l AuthN time (Req) l Session index (Opt) l Session end (Opt) l AuthN Location (Opt) n IP Address or DNS Name l AuthN Context (Req) n Details of AuthN Method

Authentication context classes n Internet Protocol n Internet Protocol Password n Kerberos n Mobile One Factor Unregistered n Mobile Two Fa1ctor Unregistered n Mobile One Factor Contract n Mobile Two Factor Contract n Password n Password Protected Transport n Previous Session n Public Key – X.509 n Public Key – PGP n Public Key – SPKI n Public Key – XML Signature n Smartcard n Smartcard PKI n Software PKI n Telephony n Nomadic Telephony n Personalized Telephony n Authenticated Telephony n Secure Remote Password n SSL/TLS Cert-Based Client Authentication n Time Sync Token n Unspecified SAML comes with a healthy set of predefined identifiers for typical authentication scenarios: You can also create or customize your own authentication context classes...

Attribute statement n An issuing authority asserts that subject S is associated with attributes A, B, … with values “a”, “b”, “c”… n Useful for distributed transactions and authorization services n Typically this would be gotten from an LDAP repository l “john.doe” in “example.com” l is associated with attribute “Department” l with value “Human Resources”

SAML Protocol Reqs/Resps n Assertion Queries & Requests n Authentication Request n Artifact Resolution n Name Identifier Resolution n Single Logout n Name Identifier Mapping

Authentication Request l Subject (Opt) l Conditions (Opt) l Requested AuthN Context (Opt) n Context & Comparison (exact, minimum, better or maximum) l Force AuthN (Opt) [default: false] l Is Passive (Opt) [default: false] l Protocol Binding l More …

Single-Sign On n Browser-driven SSO l Form POST, SAML Artifact Profiles n Note: conformant implementations must implement both profiles l Assertions may contain attribute statements n SAML 2.0 introduces notion of attribute profile l All or certain parts of an assertion may be encrypted n Important when security intermediaries are involved n SSO for enhanced client l Enhanced client is a device that understands HTTP but not SOAP n Also has “built in” knowledge of identity provider l Examples n HTTP proxies such as a WAP gateway n Consumer device with HTTP client

SP-initiated flow with redirect and POST bindings

IdP-initiated flow with the POST binding

Step Up Authentication n Usecase l User is signed in with weak mechanism l User requests admin function l Policy requires stronger AuthN l New signon required; request granted n Not really a special case for SAML n Normal SSO – request stronger AuthN with Requested AuthN Context

Other relevant SAML Profiles n Identity Assurance Profiles (1 doc) l Lets IdP or SP express or request a level of assurance (LOA) associated with an AuthN method l Lets IdP advertise ability to Authenticate at some LOA n SP Request Initiation Profile l Lets Browser request SP issue AuthN Request for some particular method

What is XACML? n XML language for access control n Coarse or fine-grained n Extremely powerful evaluation logic n Ability to use any available information n Superset of Permissions, ACLs, RBAC, etc n Scales from PDA to Internet n Federated policy administration n OASIS and ITU-T Standard

Determining the Need to Authenticate n XACML decision can be: Permit, Deny, Not Applicable & Indeterminate n If attributes are missing which policy says must be present, PDP returns Indeterminate n Missing Attributes detail includes: l Attr Id, Category, Issuer (Opt), Value (Opt) n Can indicate need for Step Up AuthN

General SAML Observations n SAML has many Assertion & Protocol features not profiled n New features generally require a champion (not necessarily an expert) n Profiles can be written by SS TC or elsewhere: e.g., FICAM Profiles n SS TC will provide expertise

Questions?