Transcript Document 7610028

SAML
RL "Bob" Morgan, University of Washington
October 2, 2001
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
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 key
–NameIdentifier = 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