Service Oriented Architecture

Identification, Authentication and

Authorization

95-843 SOA Security SAML 1

Master of Information System
Management
 Readings on Schedule
• See SAML Executive Summary
• See SAML Technical Overview
• Read about PubCookie
• See A SAML Application - Shibboleth

95-843 SOA Security SAML 2

 Today’s Outline
• SAML
• XACML
• OpenID

95-843 SOA Security SAML 3

 SAML 2.0

Approved by OASIS, March 2005

Security Assertion Markup
Language

95-843 SOA Security SAML 4

Who Implements SAML 2.0 ?
IBM Tivoli Access Manager, Oblix NetPoint, SunONE Identity Server,
Baltimore, SelectAccess, Entegrity Solutions AssureAccess,
Internet2 OpenSAML, Netegrity SiteMinder, Sigaba Secure
Messaging Solutions, RSA Security ClearTrust, VeriSign Trust
Integration Toolkit, Entrust GetAccess 7, Microsoft’s Geneva
Framework, Oracle SAML

An example SAML 2.0 application is Shibboleth.

95-843 SOA Security SAML 5

 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

95-843 SOA Security SAML 6

 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

95-843 SOA Security SAML 7
 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 8
 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,
revocation and termination.
• SAML’s focus is on single sign on by
applications. 95-843 SOA Security SAML 9
 SAML 2.0 Bottom Line
• XML encoded security assertions
• XML encoded Request/Reply protocol
• Rules on how to incorporate these XML
constructs in messages

95-843 SOA Security SAML 10

 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)
• Web Service Security (SAML allows for the
exchange of assertions within a SOAP
document)
• Federated Identity (consolidate identities
across organizational boundaries)
• See Shibboleth95-843 SOA Security SAML 11
 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.
95-843 SOA Security SAML 12
 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.

95-843 SOA Security SAML 13

 SAML 2.0 Specification
Defines(3)
• Bindings
How, for example, is SAML carried within
a SOAP document?
SOAP Message
SOAP Header
SOAP Body
SAML Request or Response

95-843 SOA Security SAML 14

 SAML 2.0 Specification
Defines(4)
• Profiles
- Rules for embedding, extracting and
integrating SAML assertions into
messages
- Error message handling

95-843 SOA Security SAML 15

 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?

95-843 SOA Security SAML 16

 Authentication Query

<Request
MajorVersion=“1”MinorVersion=“0”
RequestID=“128.14.234.20.12345678”
IssueInstant=“2001-12-03T10:02:00Z”>
<RespondWith>AuthenticationStatement
<ds:Signature>…</ds:Signature>
<AuthenticationQuery>
<Subject>
95-843 SOA Security SAML 17
 Attribute Query
<Request…>
<AttributeQuery>
<Subject>…</Subject>
<AttributeDesignator
AttributeName=“CreditRating”

95-843 SOA Security SAML 18

 Authorization Decision Query
<Request…>
<AuthorizationQuery
Resource=“http://cmu.edu/salaryFile.htm”>
<Subject>
<NameIdentifier SecurityDomain=“heinz.cmu.edu”
Name=“mike”/>
</Subject>
<ActionNamespace=
“urn:oasis:names:tc:SAML:1.0:action:rwedc”>Read
</Action>
<Evidence>
<Assertion>…</Assertion>
</Evidence>
</AuthorizationQuery>
</Request>
95-843 SOA Security SAML 19
SAML WS Response

SOAP BODY

SAML Response

Header
Assertion
Statement
Statement

95-843 SOA Security SAML 20

 A SAML WS Response
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ID="abe567de6"
InResponseTo="example-ncname" Version="2.0"
IssueInstant="2005-01-31T12:00:00Z"
Destination="http://www.example.com/"
Consent="http://www.example.com/">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success"/>
<samlp:StatusMessage>Success</samlp:StatusMessage>
<samlp:StatusDetail/>
</samlp:Status>
…… SAML ASSERTION AND STATEMENTS
</samlp:Response>
</env:Body>
</env:Envelope>
95-843 SOA Security SAML 21
 Assertions
<saml:Assertion>
<AssertionID> Assertions made by a
SAML authority.
<Issuer>
<IssueInstant>
The recipient is normally
<Conditions> a service provider.
<Advice>
<Subject>
<Authentication Statement> or
<Attribute Statement> or
<Authorization Statement>

95-843 SOA Security SAML 22

 Authentication Statement
<Assertion>
:
<AuthenticationStatement>
:
<ConfirmationMethod>

95-843 SOA Security SAML 23

 Attribute Statement
<Assertion>
:
<AttributeStatement>
<Attribute AttrributeName =
“PaidStatus”
<AttributeValue>PaidUp

95-843 SOA Security SAML 24

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

95-843 SOA Security SAML 25

 Authorization Decision Statement
<Assertion>
:
<AuthorizationStatement
decision=“permit”
resource = “salaryData”
action=“read”

95-843 SOA Security SAML 26

 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 27
 Trusted SAML Authority

SAML Request SAML Response

SAML Query Assertions

Relying Party or Service Provider Service

Request

95-843 SOA Security SAML 28

 Web SSO Use Case
• A web site requires authentication.
• The user is transferred to a partner’s web page
(both sites are in a “federation”).
The partner is a SAML Authority.
• 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 may be over SSL.
95-843 SOA Security SAML 29
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.

95-843 SOA Security SAML 30

 Authorization Use Case
A user attempts to access a resource. The
security domain defines a Policy
Enforcement Point and a Policy Decision
Point.
The Policy Enforcement Point makes calls
on the Policy Decision Points to check
permissions. These calls use SAML on a
back channel.
95-843 SOA Security SAML 31
 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 end channel and everything over SSL.

95-843 SOA Security SAML 32

 Lower Level Use Cases
• Push (Bob manages tokens)

(1) Alice authenticates with Trent and Trent calls Bob for
SAML token
(2) Bob responds with token. He knows she is authentic.
(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.

95-843 SOA Security SAML 33

 XACML 2.0

Approved by OASIS March 2005

XML Access Control Markup
Language

95-843 SOA Security SAML 34

 XACML Goals
• Industry standard way of representing
and processing access control policies.
• Vendor neutral.
• XML based.
• Provide for “rule combining algorithms”,e.g.,,
“Deny overrides” or “Permit Overrides”
• An XACML policy may specify what a
provider should do when it receives a
SAML assertion.
95-843 SOA Security SAML 35
 Who Implements XACML?

Oracle
BEA
SUN
Microsoft ? Not yet.
IBM

95-843 SOA Security SAML 36

 XACML
• Policy Language
Used to describe access control
requirements. Who is allowed to do what?
• Request/Response Language
The request is a query about permissions
associated with x.
The response is permit, deny,
indeterminate, or not applicable.
95-843 SOA Security SAML 37
 Drivers
• A standard is needed so that policies can
be processed and shared
• Interoperable
• Distributed

95-843 SOA Security SAML 38

 Use Case (1)
May I act on
Policy Enforcement Point
some resource? (PEP)

Yes/No

Requests and responses defined by

XACML

The correct policy

Policy Decision Point in XACML
(PDP) needs to be selected
and its rules
evaluated.

95-843 SOA Security SAML 39

 Use Case (2)
May I read
this page Web Server
(PEP)

Yes
<request> <Response>
<subject> <Result>
<resource> <Decision>Permit
<action>
Policy Decision Point Policies in XACML
(PDP)
Algorithms for matching requests <Policy>
to policies <Target>
<Subjects>
<Resources>
</Traget>
<Rule>
<Rule>
95-843 SOA Security SAML 40
 Use Case (3)
May I read
this page Web Server
(PEP)

Yes
Request <Response>
may include <Result>
SAML assertions <Decision>Permit

Policy Decision Point Policies in XACML

(PDP)
Algorithms for matching requests <Policy>
to policies <Target>
<Subjects>
<Resources>
</Traget>
<Rule>
95-843 SOA Security SAML 41
 OpenID
• Grassrots effort since 2005
• Web user identification and authentication
• OpenID used and provided by:
AOL, BBC, Google, IBM, PayPal, Verisign,
etc.
• Compares a bit with the heavy weight SAML.
• In my view, not central to SOA, but worth a
look.
95-843 SOA Security SAML 42
 Let’s Give OpenID a drive
• A -> B : Service request on B, A’s ID as
a URL
• B -> C : B Visits URL at C (HTTP Get)
• C -> B : HTML Doc holding a pointer to
C’s OpenID Server
• B -> A : Browser redirect to C’s OpenID
Server – many parameters are
passed from B to A destined for
C – including a nonce

95-843 SOA Security SAML 43

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

95-843 SOA Security SAML 44

• A -> B : Params from C. These include:
mode: id_res
B’s URL, session ID and nonce
A’s ID as URL
signed [mode, A’s ID as URL, B’s
URL and nonce] The signature is
encoded as Base 64
association_handle Opaque
Handle used for looking up the
signing key
95-843 SOA Security SAML 45
 Now, some options…
• B ->C : The parameters and the
signature – C checks the
signature and informs B.
B provides service to A. OR
• B -> C : A request for the signing key
• C -> 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.

95-843 SOA Security SAML 46