1. Seminar on Service Oriented Architecture
Identification, Authentication and Authorization
SOA Seminar

2. Readings on Schedule See SAML Executive Summary
See SAML Technical Overview
Read about PubCookie
See A SAML Application - Shibboleth
SOA Seminar

3. Topics
SAML
XACML
OpenID
SOA Seminar

4. SAML 2.0 Approved by OASIS, March 2005
Security Assertion Markup Language
SOA Seminar

5. 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.
SOA Seminar

6. 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
SOA Seminar

7. 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
SOA Seminar

8. 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
SOA Seminar

9. 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.
SOA Seminar

10. SAML 2.0 Bottom Line XML encoded security assertions
XML encoded Request/Reply protocol
Rules on how to incorporate these XML
constructs in messages
SOA Seminar

11. 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 Shibboleth
SOA Seminar

12. 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.
SOA Seminar

13. 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.
SOA Seminar

14. 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
SOA Seminar

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

16. 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?
SOA Seminar

17. Authentication Query <Request MajorVersion=“1”MinorVersion=“0”
RequestID=“ ”
IssueInstant=“ T10:02:00Z”>
<RespondWith>AuthenticationStatement
<ds:Signature>…</ds:Signature>
<AuthenticationQuery>
<Subject>
SOA Seminar

18. Attribute Query <Request…> <AttributeQuery>
<Subject>…</Subject>
<AttributeDesignator
AttributeName=“CreditRating”
SOA Seminar

19. Authorization Decision Query
<Request…>
<AuthorizationQuery
Resource=“
<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>
SOA Seminar

20. SAML WS Response SOAP BODY SAML Response Header Assertion Statement
SOA Seminar

21. A SAML WS Response
<env:Envelope xmlns:env="
<env:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xsi="
ID="abe567de6"
InResponseTo="example-ncname" Version="2.0"
IssueInstant=" T12:00:00Z"
Destination="
Consent="
<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>
SOA Seminar

22. Assertions <saml:Assertion> <AssertionID> <Issuer>
<IssueInstant>
<Conditions>
<Advice>
<Subject>
<Authentication Statement> or
<Attribute Statement> or
<Authorization Statement>
Assertions made by a
SAML authority.
The recipient is normally
a service provider.
SOA Seminar

23. Authentication Statement
<Assertion> :
<AuthenticationStatement>
<ConfirmationMethod>
SOA Seminar

24. Attribute Statement <Assertion> : <AttributeStatement>
<Attribute AttrributeName =
“PaidStatus”
<AttributeValue>PaidUp
SOA Seminar

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

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

27. 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.
SOA Seminar

28. Trusted SAML Authority
SAML Request
SAML Query
SAML Response
Assertions
Relying Party or Service Provider
Service
Request
SOA Seminar

29. 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
All of this may be over SSL.
SOA Seminar

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.
SOA Seminar

31. 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.
SOA Seminar

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 end channel and everything over SSL.
SOA Seminar

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.
(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.
SOA Seminar

34. Approved by OASIS March 2005 XML Access Control Markup Language
XACML 2.0
Approved by OASIS March 2005
XML Access Control Markup Language
SOA Seminar

35. 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.
SOA Seminar

36. Who Implements XACML? Oracle BEA SUN Microsoft ? Not yet. IBM
SOA Seminar

37. 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.
SOA Seminar

38. Drivers
A standard is needed so that policies can be processed and shared
Interoperable
Distributed
SOA Seminar

39. Policy Enforcement Point
Use Case (1)
May I act on
Policy Enforcement Point
(PEP)
some resource?
Yes/No
Requests and responses defined by
XACML
Policy Decision Point
(PDP)
The correct policy
in XACML
needs to be selected
and its rules
evaluated.
SOA Seminar

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

41. Algorithms for matching requests
Use Case (3)
May I read
this page
Web Server
(PEP)
Yes
Request
may include
SAML assertions
<Response>
<Result>
<Decision>Permit
Policy Decision Point
(PDP)
Algorithms for matching requests
to policies
Policies in XACML
<Policy>
<Target>
<Subjects>
<Resources>
</Traget>
<Rule>
SOA Seminar

42. 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.
SOA Seminar

43. 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
SOA Seminar

44. 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
SOA Seminar

45. 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
SOA Seminar

46. 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.
SOA Seminar