Transcript SAML

Security Assertion Markup
Language (SAML)
Interoperability Demonstration
What is SAML for?
• Distributed Authorization
• Federated Identity Management
• Multi-vendor Portals
• Web Services Access Control
SAML Use Cases
•
SAML developed three “use cases”
to drive its requirements and design:
1. Single sign-on (SSO)
2. Distributed transaction
3. Authorization service
•
Each use case has one or more
“scenarios” that provide a more
detailed roadmap of interaction
#1: Single sign-on (SSO)
• Logged-in users of analyst research
site SmithCo are allowed access to
research produced by sister site
JonesCo
Authenticate
Source
Web Site
Web User
Use Secured
Resource
Destination
Web Site
#2: Distributed transaction
• Employees at SmithCo are allowed to
order office supplies from OfficeBarn
if they are authorized to spend enough
Authenticate,
Qualify
Authority
Known to
Both
Buyer
Transact
Business
Seller
#3: Authorization service
• Employees at SmithCo order office
supplies directly from OfficeBarn,
which performs its own authorization
Policy Decision Point
Check Permission
Access Resource
User
Policy Enforcement Point
SAML producer-consumer model
Policy
Credentials
Collector
Policy
Authentication
Authority
Policy
Attribute
Authority
Policy Decision
Point
Attribute
Assertion
Authorization
Decision
Assertion
SAML
Authentication
Assertion
System
Entity
Application
Request
Policy Enforcement
Point
This model is conceptual only
• In practice, multiple kinds of authorities may
reside in a single software system
– SAML allows, but doesn’t require, total
federation of these jobs
• Also, the arrows may not reflect information
flow in real life
–
–
–
–
The order of assertion types is insignificant
Information can be pulled or pushed
Not all assertions are always produced
Not all potential consumers (clients) are shown
SAML Specification Elements
• A standard XML message format
– It’s just data traveling on any wire
– No particular API mandated
– Lots of XML tools available
• A standard message exchange protocol
– Clarity in orchestrating how you ask for and get
the information you need
• Rules for how the messages ride “on” and
“in” transport protocols
– For better interoperability
SAML is NOT…
• A new form of Authentication
• Existing security “translated” into XML
• An alternative to WS-Security
• Limited to legacy applications
• Limited to Web Browser applications
• Limited to Web Services security
SAML Assertions
• Assertions are declarations of fact, according to
someone
• SAML assertions are compounds of one or more
of three kinds of “statement” about “subject”
(human or program):
– Authentication
– Attribute
– Authorization decision
• You can extend SAML to make your own kinds of
assertions and statements
• Assertions can be digitally signed
Common Header
• Issuer ID 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
• Targeted towards SSO uses
• Caution: Actually checking or revoking of
credentials is not in scope for SAML!
• It merely lets you link back to acts of
authentication that took place previously
Attribute Statement
• An issuing authority asserts that subject S
is associated with attributes A, B, … with
values “a”, “b”, “c”…
• Useful for distributed transactions and
authorization services
• Typically this would be gotten from an LDAP
repository
– “john.doe” in “example.com”
– is associated with attribute “Department”
– with value “Human Resources”
Authorization Decision Statement
• An issuing authority decides whether to
grant the request by subject S for access
type A to resource R given evidence E
• Useful for distributed transactions and
authorization services
• The subject could be a human or a program
• The resource could be a web page or a web
service, for example
SAML Requests and Responses
Asserting Party
SAML
Request for
Assertion of
Certain Type
Response
Assertion
Relying Party
SAML Requests
• You can query for specific kinds of
assertion/statement
– Authentication query
– Attribute query
– Authorization decision query
• You can ask for an assertion with a
particular ID
– By providing an ID reference
– By providing a SAML “artifact”
SAML Bindings and Profiles
• This is where SAML itself gets made secure
• A “binding” is a way to transport SAML
requests and responses
– SOAP-over-HTTP binding is a baseline
– Other bindings will follow, e.g., raw HTTP
• A “profile” is a pattern for how to make
assertions about other information
– Two browser profiles for SSO: artifact and POST
– WS-Security profile for securing SOAP payloads
The SOAP-over-HTTP binding
Transport (HTTP)
SOAP Message
SOAP Header
SOAP Body
SAML Request or
Response
SAML Web Services Profile
Transport (HTTP)
SOAP Message
SOAP Header
SAML Assertion
about SOAP Body
SOAP Body
...
SAML status
• Work started on 9 January 2001
– From a base of S2ML and AuthXML
– www.oasis-open.org/committees/security/
• TC voted to accept as Committee Specification
on 16 April 2002
• Submitted to OASIS for Approval – 28 May 2002
– Approval expected 1 Nov 2002
• More that a dozen vendors have announced
implementations – most soon in products
• Public Interoperability Demonstration
– Catalyst Conference – 15 July 2002
SAML Interoperability Demo
• 12 Vendors Participated
– Baltimore Technologies, Crosslogix, ePeople,
Entegrity Solutions, IBM/Tivoli, Netegrity, Novell,
Oblix, OverXeer, RSA Security, Sigaba, Sun
Microsystems
– 9 Portals
– 12 Applications
•
•
•
•
•
SAML Browser/Artifact Profile
Dry runs June 17-21
Setup and Testing - July 13 & 14
Demonstration and Press Conference – July 15
Remarkably easy for first use of a specification
Interoperability Demo Elements
Application 1
Portal
Application 1
username
password
Application 2
Application 2
Application 3
Application 4
Application 3
Application 4
Demonstration Scenario
• Begin demo: signon at any Portal
• Click thru to any application
• Service depends on user attributes
Authenticate
Source
Web Site
Web User
Use Secured
Resource
Destination
Web Site
Demo Message Exchange
Web User
Portal
Application
Source
Web Site
Destination
Web Site
Authenticate (out of band)
Access inter-site transfer URL
Redirect with artifact
Get assertion consumer URL
Request referenced assertion
Supply referenced assertion
Provide or refuse destination resource (out of band)