Service Oriented Architecture
Identification, Authentication and
Authorization
95-843 SOA Security SAML
Master of Information System
Management
1
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
• Identity Management 101 Video from Ping
Identity
• SAML video from Ping Identity
• The Needham-Schroeder protocol
• SAML
• OpenID
95-843 SOA Security SAML
3
The Needham–Schroeder SecretKey Authentication Protocol
Header
Message
Notes
1. A->S:
A, B, NA
A requests S to supply a key for communication
with B.
S returns a message encrypted in A’s secret key,
{NA , B, KAB,
containing a newly generated key KAB and a
{KAB, A}KB}KA ‘ticket’ encrypted in B’s 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 A’s secret key.
A sends the ‘ticket’ to B.
3. A->B: {KAB, A}KB
B decrypts the ticket and uses the new key KAB to
4. B->A: {NB}KAB
encrypt another nonce NB.
A demonstrates to B that it was the sender of the
5. A->B: {NB - 1}KAB
previous message by returning an agreed
transformation of NB.
2. S->A:
95-843 SOA Security SAML
Master of Information System
Management
4
The Needham–Schroeder SecretKey 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?
95-843 SOA Security SAML
Master of Information System
Management
5
SAML 2.0
Approved by OASIS, March 2005
Security Assertion Markup
Language
95-843 SOA Security SAML
6
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
Microsoft’s Geneva Framework
Oracle SAML
An example SAML 2.0 application is Shibboleth.
95-843 SOA Security SAML
7
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
8
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
9
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
10
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.
• SAML’s focus is on single sign on by
applications.
95-843 SOA Security SAML
11
SAML 2.0 Bottom Line
• XML encoded security assertions
• XML encoded Request/Reply protocol
• Rules on how to incorporate these XML
constructs into messages
95-843 SOA Security SAML
12
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 Shibboleth95-843 SOA Security SAML
13
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
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
15
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
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?
95-843 SOA Security SAML
17
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
18
Attribute Query
<Request…>
<AttributeQuery>
<Subject>…</Subject>
<AttributeDesignator
AttributeName=“CreditRating”
95-843 SOA Security SAML
19
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
20
SAML WS Response
SOAP BODY
SAML Response
Header
Assertion
Statement
Statement
95-843 SOA Security SAML
21
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
22
SAML Assertions
<saml:Assertion>
Assertions made by a
<AssertionID>
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
23
Authentication Statement
<Assertion>
:
<AuthenticationStatement>
:
<ConfirmationMethod>
95-843 SOA Security SAML
24
Attribute Statement
<Assertion>
:
<AttributeStatement>
<Attribute AttrributeName =
“PaidStatus”
<AttributeValue>PaidUp
95-843 SOA Security SAML
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.
95-843 SOA Security SAML
26
Authorization Decision Statement
<Assertion>
:
<AuthorizationStatement
decision=“permit”
resource = “salaryData”
action=“read”
95-843 SOA Security SAML
27
Trusted SAML Authority
SAML Request
SAML Query
Relying Party or Service Provider
95-843 SOA Security SAML
SAML Response
Assertions
Service
Request
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 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?
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 (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.
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 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.
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.
95-843 SOA Security SAML
33
SAML Replay Attack
• It’s 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?
• ID’s on the token can be checked by the service
provider. Have we seen this request before?
95-843 SOA Security SAML
34
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
on JSON & REST35
95-843 based
SOA Security SAML
The OpenID protocol
• 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
95-843 SOA Security SAML
36
C – including a nonce
• 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
37
• 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
signing95-843
key
SOA Security SAML
38
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
39