SAML 2.0

1
Service Oriented Architecture
Identification, Authentication and Authorization
Master of Information System Management
2
Readings on Schedule

• See SAML Executive Summary
• See SAML Technical Overview
• Read about PubCookie
• See A SAML Application - Shibboleth

3
Todays Outline

• Identity Management 101 Video from Ping Identity
• SAML video from Ping Identity
• The Needham-Schroeder protocol
• SAML
• OpenID

4
The NeedhamSchroeder Secret-Key Authentication
Protocol
Header
Message
Notes
1. A-gtS
A requests S to supply a key for communication
A, B, NA
with B.
S returns a message encrypted in As secret key,
2. S-gtA
NA , B, KAB,
containing a newly generated key KAB and a
KAB, AKBKA
ticket encrypted in Bs secret key. The nonce
NA
demonstrates that the message was sent in response
to the preceding one. A believes that S sent the
message because only S knows As secret key.

A sends the ticket to B.
KAB, AKB
3. A-gtB
B decrypts the ticket and uses the new key KAB to
NBKAB
4. B-gtA
encrypt another nonce NB.
A demonstrates to B that it was the sender of the
NB - 1KAB
5. A-gtB
previous message by returning an agreed
transformation of NB.
Master of Information System Management
5
The NeedhamSchroeder Secret-Key Authentication
Protocol
Quiz. (0) With respect to Needham-Schroeder,
discuss Identification, Authentication and
Authorization. (1) What benefits are present in
the separation of concerns that have been
built into Needham-Schroeder? (2) Why would this
protocol work well on an intranet but, at the
same time, be hard to scale to the internet?

Master of Information System Management
6
SAML 2.0
Approved by OASIS, March 2005 Security Assertion
Markup Language
7
SAML 2.0 is widely implemented
IBM Tivoli Access Manager Oblix NetPoint SunONE
Identity Server Entegrity Solutions Assure
Access, Internet2 OpenSAML Netegrity
SiteMinder Sigaba Secure Messaging Solutions RSA
Security ClearTrust VeriSign Trust Integration
Toolkit Entrust GetAccess 7 Microsofts Geneva
Framework Oracle SAML An example SAML 2.0
application is Shibboleth.
8
SAML Web Service Use Case
SAML is different from other security approaches
mostly because of its expression of security in
the form of assertions about subjects. Other
approaches use a central certificate authority to
issue certificates that guarantee secure
communication from one point to another within a
network. With SAML, any point in the network
can assert that it knows the identity of a user
or piece of data. It is up to the receiving
application to accept if it trusts the
assertion. Any SAML-compliant software can
assert its authentication of a user or data.
This is important for the coming wave of
business workflow web services standards where
secured data needs to move through several
systems for a transaction to be completely
processed. From IBM Developerworks
9
What is Identity Management?
In the information systems security space,
identity management recently emerged as a new
term that covers the following areas of
computing Provisioning. Adds new users to
network operating system directories and
application server directories, both inside an
enterprise and outside at partner
information systems. Password management.
Enables users to have a single set of credentials
to sign on to the company information
systems. Additionally, it enables users to
self-administer their passwords, user account
data, and privileges. Access control.
Enables the system to recognize security policies
for groups of users. For example, a
security policy would prevent people from
changing their own job title and instead route a
request for a job title change to the
appropriate authority. SAML is a protocol
specification to use when two servers need to
share authentication information. Nothing in the
SAML specification provides the actual
authentication service From IBM Developerworks
10
SAML 2.0

• Security Assertion Markup Language
• Organization for the Advancement of
• Structured Information Standards
• (OASIS) Approved March 2005
• Industry standard way of
• representing and exchanging assertions
• about identity, attributes and entitlements
• Vendor neutral
• XML based
• Uses SOAP, XMLDSig, XMLEnc
• SSL is required between servers

11
SAML 2.0

• SAML falls under the broader topic of
• Identity Management.
• Identity management applies to both
• network and federated identity.
• Federated Identity refers to the use of
• identity or authorization decisions across
• organizational boundaries.
• Identity management includes the
• consideration of identity registration,
• management and termination.
• SAMLs focus is on single sign on by
• applications.

12
SAML 2.0 Bottom Line

• XML encoded security assertions
• XML encoded Request/Reply protocol
• Rules on how to incorporate these XML
• constructs into messages

13
Important SAML 2.0 Drivers

• Single Sign On Across Domains
• Cookies prevent the need for reauthorization
• only within the same domain
• SSO interoperability? (before SAML little)
• Part of Web Service Security (SAML allows
• for the exchange of assertions within a SOAP
• document)
• Federated Identity (consolidate identities
• across organizational boundaries)
• See Shibboleth

14
Terminology From SAML Spec

• Assertions are declarations of facts about
• subjects.
• The Identity Provider or SAML Authority or
  Asserting Party is the entity that makes
  assertions.
• The Service Provider or Relying party
• Relies on information provided by the
• identity providers.

95-843 SOA Security SAML
14
15
SAML 2.0 Specification Defines(1)

• Assertions about
• - authentication acts (e.g., YES, the
  entity did
• authenticate in this way at this time)
• - attributes of subjects (e.g., access
• rights, credit limits, status) name,
  value pairs
• - authorization decisions already made
• Note
• Assertions are usually passed from an
  identity
• provider to a service provider.
• Assertions contain statements used by the
  service
• provider to make decisions about access
  control.

16
SAML 2.0 Specification Defines(2)

• A Simple Request / Reply protocol
• - Request Types (queries)
• authentication
• authorization
• attribute
• - One reply format containing assertions.
• (authentication, authorization or
  attribute statements)
• The requests and replies occur on an SSL channel.
  The requestor is typically a service provider and
  the responder an identity provider.

17
SAML 2.0 Request Types

• AuthenticationQuery - request
• any authentication information held
  by
• an authority about a subject has
  this
• subject logged in?
• AttributeQuery request attributes of a
  
• subject - What is the role associated
  with
• this subject?
• AuthorizationDecisionQuery request a
• decision on subject s to resource r
  with
• evidence e. What is your opinion?

18
Authentication Query

• ltRequest
• MajorVersion1MinorVersion0
• RequestID128.14.234.20.12345678
• IssueInstant2001-12-03T100200Zgt
• ltRespondWithgtAuthenticationStatement
• ltdsSignaturegtlt/dsSignaturegt
• ltAuthenticationQuerygt
• ltSubjectgt

19
Attribute Query

• ltRequestgt
• ltAttributeQuerygt
• ltSubjectgtlt/Subjectgt
• ltAttributeDesignator
• AttributeNameCreditRating

20
Authorization Decision Query

• ltRequestgt
• ltAuthorizationQuery
• Resourcehttp//cmu.edu/salaryFile.htmgt
• ltSubjectgt
• ltNameIdentifier SecurityDomainheinz.cmu.edu
  
• Namemike/gt
• lt/Subjectgt
• ltActionNamespace
• urnoasisnamestcSAML1.0actionrwedcgtRead
• lt/Actiongt
• ltEvidencegt
• ltAssertiongtlt/Assertiongt
• lt/Evidencegt
• lt/AuthorizationQuerygt
• lt/Requestgt

21
SAML WS Response
SOAP BODY
SAML Response
Header
Assertion
Statement Statement
22
A SAML WS Response
ltenvEnvelope xmlnsenv"http//schemas.xmlsoap.or
g/soap/envelope/"gt ltenvBodygt ltsamlpResponse
xmlnssamlp"urnoasisnamestcSAML2.0protocol"
xmlnsxsi"http//www.w3.org/2001/XM
LSchema-instance" ID"abe567de6"
InResponseTo"example-ncname"
Version"2.0" IssueInstant"2005-01-31
T120000Z" Destination"http//www.e
xample.com/" Consent"http//www.examp
le.com/"gt ltsamlpStatusgt
ltsamlpStatusCode Value"samlpSuccess"/gt
ltsamlpStatusMessagegtSuccesslt/samlp
StatusMessagegt
ltsamlpStatusDetail/gt
lt/samlpStatusgt SAML ASSERTION
AND STATEMENTS lt/samlpResponsegt lt/en
vBodygt lt/envEnvelopegt
23
SAML Assertions

• ltsamlAssertiongt
• ltAssertionIDgt
• ltIssuergt
• ltIssueInstantgt
• ltConditionsgt
• ltAdvicegt
• ltSubjectgt
• ltAuthentication Statementgt or
• ltAttribute Statementgt or
• ltAuthorization Statementgt

Assertions made by a SAML authority.
The recipient is normally a service provider.
24
Authentication Statement

• ltAssertiongt
• ltAuthenticationStatementgt
• ltConfirmationMethodgt

25
Attribute Statement

• ltAssertiongt
• ltAttributeStatementgt
• ltAttribute AttrributeName
• PaidStatus
• ltAttributeValuegtPaidUp

26
Authorization Decision Statement

• T decides whether to grant a request by S for
  access (of a particular type) to resource R given
  evidence E.

27
Authorization Decision Statement

• ltAssertiongt
• ltAuthorizationStatement
• decisionpermit
• resource
  salaryData
• actionread

28
Trusted SAML Authority
SAML Request SAML Query
SAML Response Assertions
Relying Party or Service Provider
Service Request
29
Web SSO Use Case

• A web site requires authentication.
• The user is transferred to a partners web page
  (both sites are in a federation).
• The partner is a SAML Authority or idP.
• The SAML authentication query is passed as well.
• If the SAML Authority is satisfied (SAML does not
  say how) then particular access may be granted
  and passed (possibly through the browser) to the
  original web site.
• See use case at http//en.wikipedia.org/wiki/SAML.
  
• All of this should be over SSL. Why?

30
Business Transaction Use Case

• An employee may be authenticated and may qualify
  to make purchases for her company.
• The seller may make inquiries on an authority
  known by both buyer and seller.
• The authority may vouch for the employee and
  describe her qualifications.

31
Authorization Use Case

• A user attempts to access a resource. The
  security domain defines a Policy Enforcement
  Point (PEP) and a Policy Decision Point (PDP).
• The Policy Enforcement Point makes calls
• on the Policy Decision Points to check
  permissions. These calls use SAML on a back
  channel.

32
Lower level Use Cases

• Pull (Trent manages tokens)
• (1)Alice authenticates with Trent and receives
  an 8 byte
• random token.
• (2) Alice presents a request for service and the
  token to
• Bob.
• (3) Bob passes the token to Trent and receives
  assertions about Alice.
• (4) Bob provides Alice with the service.
• Assume a back channel and everything over SSL.

33
Lower Level Use Cases

• Push (Bob manages tokens)
• Alice authenticates with Trent and Trent calls
  Bob for SAML token
• (2) Bob responds with token. He knows she is
  authentic. He trusts Trent.
• (3) Trent returns token to Alice.
• (4) Alice calls Bob with token.
• (5) Bob provides Alice with service.
• Bob need not handle authentication and may only
  provide
• tokens to Trent.

34
SAML Replay Attack

• Its hard for the bad guys to get a signed token.
  The signed token is carried over an SSL
  connection.
• But, in principle, the bad guy does not need to
  be able to read the encrypted token in order to
  run a replay attack.
• Timestamps on the token can be checked by the
  Service Provider. Is the request fresh?
• IDs on the token can be checked by the service
  provider. Have we seen this request before?

35
OpenID

• Grassroots effort since 2005
• Now called Open ID Connect
• Web user identification and authentication
• OpenID used and provided by
• AOL, BBC, Google, IBM, PayPal, Verisign, etc.
• Governments and Universities are using SAML2
• OpenID Connect based on JSON REST

36
The OpenID protocol

• A -gt B Service request on B, As ID as
• a URL
• B -gt C B Visits URL at C (HTTP Get)
• C -gt B HTML Doc holding a pointer to
• Cs OpenID Server
• B -gt A Browser redirect to Cs OpenID
• Server many parameters are
• passed from B to A destined
  for
• C including a nonce

37

• A -gt C The parameters from B include
• mode checkID_set-up
• As ID as a URL
• Bs URL, session id and nonce
• C authenticates A OpenID does not
• dictate how this is done.
• C -gt A A browser redirect to B with
• params destined for B

38

• A -gt B Params from C. These include
• mode id_res
• Bs URL, session ID and nonce
• As ID as URL
• signed mode, As ID as URL, Bs
• URL and nonce The signature is
• encoded as Base 64
• association_handle Opaque
• Handle used for looking up the
• signing key

39
Now, some options

• B -gtC The parameters and the
• signature C checks the
• signature and informs B.
• B provides service to A. OR
• B -gt C A request for the signing key
• C -gt B The key is transmitted and B does the
• checking. B provides service
  to A. OR
• B verifies the signature with a key he has built
  with C using Diffie-Hellman. The key was
  established earlier.
• B provides the service to A.