master of information system management

95-843 SOA Security SAML 1Master of Information System

Management

Service Oriented Architecture

Identification, Authentication and Authorization

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



Management

The Needham–Schroeder Secret-Key Authentication Protocol

Header Message Notes

1. A->S: A, B, NAA requests S to supply a key for communicationwith B.

2. S->A: {NA , B, KAB,

{KAB, A}KB}KA

S returns a message encrypted in A’s secret key,containing a newly generated key KAB and a‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in responseto the preceding one. A believes that S sent themessage because only S knows A’s secret key.

3. A->B: A sends the ‘ticket’ to B.

4. B->A: B decrypts the ticket and uses the new key KAB toencrypt another nonce NB.

5. A->B: A demonstrates to B that it was the sender of theprevious message by returning an agreedtransformation of NB.

{KAB, A}KB

{NB}KAB

{NB - 1}KAB


Management

The Needham–Schroeder 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?


SAML 2.0

Approved by OASIS, March 2005

Security Assertion Markup Language


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.


“SAML is different from other security approaches mostly because ofits 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

SAML Web Service Use Case


“In the information systems security space, identity management recentlyemerged 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 providesthe actual authentication service…”

From IBM Developerworks

What is Identity Management?

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


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.


SAML 2.0 Bottom Line

• XML encoded security assertions

• XML encoded Request/Reply protocol

• Rules on how to incorporate these XML

constructs into messages


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

95-843 SOA Security SAML 1495-843 SOA Security SAML 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.


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.


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.


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?


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>


Attribute Query

<Request…>

<AttributeQuery>

<Subject>…</Subject>

<AttributeDesignator

AttributeName=“CreditRating”


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>


SAML WS Response

SOAP BODY

SAML Response

Header

Assertion

Statement Statement


<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>

A SAML WS Response


SAML Assertions

<saml:Assertion> <AssertionID> <Issuer> <IssueInstant> <Conditions> <Advice> <Subject> <Authentication Statement> or <Attribute Statement> or <Authorization Statement>

Assertions made by aSAML authority.

The recipient is normallya service provider.


Authentication Statement

<Assertion>

:

<AuthenticationStatement>

:

<ConfirmationMethod>


Attribute Statement

<Assertion>

:

<AttributeStatement>

<Attribute AttrributeName =

“PaidStatus”

<AttributeValue>PaidUp


Authorization Decision Statement

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


Authorization Decision Statement

<Assertion>

:

<AuthorizationStatement

decision=“permit”

resource = “salaryData”

action=“read”


Trusted SAML Authority

Relying Party or Service Provider

SAML RequestSAML Query

SAML ResponseAssertions

ServiceRequest


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?

http://en.wikipedia.org/wiki/SAML


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.


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.


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.


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 providetokens to Trent.

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?


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 & REST95-843 SOA Security SAML 35

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

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


• 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 key95-843 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.


master of information system management

Documents

soa security saml95

soa security samlreadings

security approaches

ofits expression of

samlcompliant software

generated key kab

bs secret key

new key kab toencrypt