January 9, 2002

Security Assertion Markup Language (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 supports "async" and B2B processes too defines Assertions in XML for carrying

Authentication, Attribute, Authz Decision statements defines simple XML request/response protocol that

runs over SOAP (or HTTP or other) could be security format for other XML protocols

How it came to be

"Web access management" products web sign-on services, plus authz management many vendors in market, in deployments,

customers want interop among them other opportunities for XML-based stuff

(eg ebXML-defined business processes)

Y2000: 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 of participants: "distributed systems security" (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 extensible for other XML-based assertions

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

Protocol as simple means to get Assertions runs over existing "transports" eg SOAP

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 (just a string) Subject

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

IssueInstant Issuer (just a string) Conditions: critical (i.e., "must process") elements Advice: other non-critical items Signing (via XMLDSIG) optional

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 SOAP is mandatory-to-implement HTTP, BEEP are possible S/MIME also mentioned early, but not specified protection via SSL in binding may avoid use of

signature on assertion/message

Browser profile

Supports the standard web sign-on case user initial authentication not in scope,

session management also left for later

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

Or: use HTTP POST to send full assertion

Both methods will be specified

Other SAML spec docs

Conformance specify mandatory-to-implement functions requirements for particular app scenarios

Security/Privacy considerations describes threats and mechanisms,

implementation concerns Shibboleth privacy concerns will go here

SAML Status

First meeting Jan 9, 2001

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

Profile/bindings more or less done (rev 8)

Conformance, sec/priv docs getting closer

Initiating public review this week, hoping for "last call" Feb 1

Netegrity released 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 Kerberos design ideas subcommittee to pursue this more hasn't happened

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

No commitment to SAML apparent

Will MS open authorization data format?

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 is based on SAML