October 2, 2001

SAML

RL "Bob" Morgan, University of Washington

Topics

How it came to be

SAML scope

SAML architecture

Status

Issues

SAML in one slide

Security Assertion Markup Language specification from OASIS Security Services TC supports interop among "web access management"

products and deployments; other functions too defines Assertions in XML for carrying

Authentication, Attribute, Authz Decision statements defines simple XML request/response protocol bindings to common transports: HTTP, SOAP could be security syntax for other XML-based

protocols

How it came to be

"Web access management" products webiso-like services, plus authz management many vendors in market, in deployments,

customers want interop other opportunities for XML-based stuff

(eg ebXML-defined business processes)

2000: vendors struggle, decide to cooperate Jan 2001 establish committee in OASIS, a

membership org promoting XML-based standards

Who are the players

Netegrity, Securant (now RSA) contributed initial specs (S2ML, AuthXML)

Other major vendors/contributors: Baltimore, Entrust, Entegrity, HP, IBM/Tivoli, Oblix,

Sun, VeriSign, Jamcracker, others (and Internet2!)

Areas of expertise: "distributed systems" (i.e., DCE) PKI XML (SOAP, schema definition, web services)

What the major products do

Web single sign-on multiple backend mechanisms, etc. redirect model vs proxy model

Authorization management for web apps "policy store" with rules, expressions, attributes access protocol from webserver to policy engine

can user foo see page X?

Session management single sign-off, single time-out

SAML scope/structure

XML-format Assertions as fundamental tech used for core authn/authz purposes exchange of security info between systems/domains also reusable for other XML-based assertions

e.g. OASIS XACML (ACLs in XML, sort of) TC

Bindings are where "security" lives e.g., protection with SSL or XML-DSIG

Profiles specify use in application scenarios e.g., web browser sign-on scenario

SAML Domain Model

AuthenticationAuthority

AttributeAuthority

PolicyDecisionPoint

PolicyEnforcement

Point

Credentials

AuthenticationAssertion

SystemEntity

AttributeAssertion

AuthorizationDecisionAssertion

SAML

PolicyPolicy PolicyPolicy Policy

CredentialsCollector

CredentialsAssertion

ApplicationRequest

SAML Assertions

Authentication statement that Subject authenticated at time T authentication exchange itself is not in SAML scope

Attribute statement that Subject has stated attributes

presumably but not necessarily "authorization" attrs

Authorization Decision statement that resource request is granted/denied

Assertion basics

Each Assertion has: Assertion ID Subject

optional SubjectConfirmation, e.g. public keyNameIdentifier = Name + SecurityDomain

IssueInstant Issuer (string) Conditions: critical (i.e., "must process") elements Advice: other non-critical items

Request/response protocol

Simplest possible protocol for requesting/supplying any kind of assertion not intended to rival SQL, LDAP, etc

Authentication, Attribute Assertions are requested for a particular Subject

Authz Decision Assertion request is: is action Y on resource Z by subject S permitted?

This protocol is not the only way to get Assns

Bindings

Specify transport of protocol messages in carrier protocols HTTP, HTTP/SSL, SOAP are most likely BEEP is possible S/MIME also desirable protecting via XML-DSIG part of binding spec?

Browser profile

Supports the standard web sign-on case

Size limits of URLs, cookies a problem "Artifact" refers to an assertion, is small enough to

travel in URL/cookie used by receiver to request full (authn) assertion

Alternative: use POST to send full assertion

Both methods will be specified, probably

Concern: where do "countermeasures" go?

Other SAML spec docs

Conformance specify mandatory-to-implement pieces may profile particular app scenarios

Security/Privacy considerations will depend a lot on specifics of bindings, schema most Shibboleth privacy concerns go here

SAML Status

"Core" document mostly done (rev 19 now) includes assertion and protocol schema

Browser profile mostly done (rev 5)

Other bindings need more work

Conformance, sec/priv considerations still early in process

Intent to have spec by December 2001

Netegrity releasing open toolkit in October

Issues and observations

A lot is still left to designers/deployers Is Subject NameIdentifier a DN, a Kerb name?

It's a string! Whatever!same with Issuer!

out-of-box interop is unlikely

XML Schema-writing is still a young art differences of opinion on best practice unknown value of some constructs, as still not

supported in parsers or common in practice

Remarkable collaboration among worldviews

What about Microsoft?

MS didn't participate in early work,but received some "encouragement" later

Has contributed design ideas,mostly about Kerberos support subcommittee formed to pursue this more

Latest .NET/Passport story addresses "federated" functions, based on Kerberos

No commitment to SAML, but at the table

Authorization data format interop?

More speculation

SAML vs. X.509? X.509 certs underlie authentication, SSL, DSIG Authn Assns are somewhat like PK certs Attr Assns are very much like X.509 Attr certs still disjunction between ASN.1 and XML

(really, ASN.1 "schema" vs XML Schema)

SAML vs Kerberos? Authn Assn like session ticket Kerberos fine as binding/transport, once specified Kerberos per se has no authz data format

Conclusion

SAML meets important interop requirements

Right players are involved

Spec is moving along, software happening

Will be important technology

Won't solve problems out of the box

Shibboleth based on SAML