220 likes | 242 Views
SAML: An XML Framework for Exchanging Authentication and Authorization Information + SPML, XCBF. Prateek Mishra August 2002. Agenda. SAML Status and Impact SAML in a Nutshell SAML and Web Services
E N D
SAML: An XML Framework for Exchanging Authentication and Authorization Information+SPML, XCBF Prateek Mishra August 2002
Agenda • SAML Status and Impact • SAML in a Nutshell • SAML and Web Services [thanks to Eve Maler (SUN) and Marc Chanliau (Netegrity) for the materials used in this presentation]
SAML Status • The SAML 1.0 Specification Set is at Commitee Specification maturity level • Entered a balloting period in pursuit of OASIS Standard status on 1 June 2002. • Available at http://www.oasis-open.org/committees/security/#documents • SSTC discussion around next steps ongoing • WS-Security Profile of SAML
SAML Impact • Implementations available from http://www.opensaml.org, http://www.phaos.com, … • JSR-155 Java API standard and Reference Implementation ongoing (complete in 2002) • Liberty Alliance uses and extends SAML 1.0 • Several products available (Baltimore, Entegrity) and many more announced (Netegrity, Tivoli, Oblix, RSA, SUN, Quadrasis, CrossLogic, Sigaba, ePeople, …)
SAML 1.0: Main Features • Normative Specification is in two parts: • Assertion and Protocol XML Schema • Bindings and Profiles • Assertion: a set of statements in a standard envelope • Statement: a declaration of fact about a subject • Three types: attribute, authentication and authorization decision • Protocol: SAML web services defined as XML request-response pairs • Services consume and/or produce SAML assertions
Bindings and Profiles • SAML 1.0 includes a SOAP-over-HTTP binding for SAML protocol • Trust model and SOAP-over-HTTP details required for interoperability • Profile: use of SAML to solve a business problem • SAML 1.0 includes a family of Web Browser SSO profiles
All assertions have some common information • Issuer 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 • An issuing authority asserts that: • subject S • was authenticated by means M • at time T • Caution: Actually checking or revoking of credentials is not in scope for SAML! • Password exchange • Challenge-response • Etc.
Attribute Statement • An issuing authority asserts that: • subject S • is associated with attributes X, Y, Z • with values “a”, “b”, “c”…(XML fragments) • Often this would be gotten from an LDAP repository • “john.doe” in “example.com” • is associated with attribute “Department” • with value “Human Resources”
Example • “John Doe” logged in at 9AM at example.com. He is a manager with spending limit of $10K. • <saml:assertion Issuer=“example.com”…> <saml:Conditions NotBefore=… NotAfter=…/> <saml:AuthenticationStatement AuthenticationMethod=… AuthenticationInstant=… > <saml:subject …>John Doe</saml:subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:subject …>John Doe</saml:subject> <saml:Attribute AttributeName=“Title” …> <saml:AttributeValue>Manager</AttributeValue> </saml:Attribute> <saml:Attribute AttributeName=“SpendLimit” …> <saml:AttributeValue>10,000</AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>
Authorization decision assertion • An issuing authority decides whether to grant the request: • by subject S • to perform action A • on resource R • given evidence E (other assertions) • The subject could be a human or a program • The resource could be a web page or a web service, for example
Example authorization decision assertion • <saml:Assertion …> <saml:Conditions …/> <saml:AuthorizationDecisionStatement Decision=“Permit” Resource=“http://jonesco.com/rpt_12345.htm”> • <saml:Action>READ</saml:Action> <saml:Evidence>…</saml:Evidence> <saml:Subject> <saml:NameIdentifier SecurityDomain=“smithco.com” Name=“joeuser” /> </saml:Subject> </saml:AuthorizationDecisionStatement></saml:Assertion>
SAML Protocol • Defined via XML request-response pairs • A <samlp:Request> includes one of two query forms • Assertion Lookup based on simple query language • Assertion Lookup by id or artifact • Query for assertions with AuthN statements by matching against subject name and authentication method • Query for assertions with Attribute statements by matching against subject name and attribute name(s) • Authorization Decision Assertion Request
Authorization decision assertion request • “Is this subject allowed to access the specified resource in the specified manner, given this evidence?” • This type of request is the most complex • Models classical PEP (policy enforcement point) and PDP (policy decision point) dialog
SAML and Web Services • SAML Protocol describes a class of security services (expressed as web services) • SAML responders support: • Lookup by assertion id • (remote) lookup of attributes or authentication information, • Interaction between a PEP and a remote PDP • SOAP Binding for SAML 1.0 provides interoperable implementation
Securing a web service using SAML • WS-Security Profile of SAML • draft-sstc-ws-sec-profile-03 available at http://lists.oasis-open.org/archives/security-services/200208/msg00015.html • <wsse:Security> element carries SAML assertions or assertion identifier references. • Additional signatures may be added to provide proof-of-possession (and data integrity)
WS-Security profile WS-Security Header
Messaging Use-Case • Two parties: a buyer and a seller • Asymmetrical relationship is assumed • Seller is already known to buyer, but buyer is not known to seller, a common situation • E.g., server-side certificates might be used to authenticate seller • If it were symmetrical, additional SAML steps would happen on the right side too • This would be an extension of this scenario
Service Provisioning Markup Language • What is SPML? • Open standard for defining and exchanging identity provisioning requests in XML • Loosely-coupled model for integration and operation of identity provisioning request flows • What does it look like? • An XML Schema – data layout for expressing the request (C.R.U.D) and attributes required for a given provisioning request • A Protocol – a basic request/response dialog for exchanging request schema • A Binding – the definition of how you pack the schema and protocol in a message transport like HTTP or SOAP. • When is it available? • Expected December 2002
XCBF – Common Biometric Format • The XCBF TC will define a common set of secure XML encodings for the patron formats specified in CBEFF, the Common Biometric Exchange File Format (NISTIR 6529). • http://www.oasis-open.org/committees/xcbf/