Federated identity and web services

1. Introduction

Federation is currently the dominant

movement in identity management.

Federation refers to the establishment of

some or all of business agreements,

cryptographic trust, user identifiers and

attributes between decentralized security

and policy domains. Federation describes

scenarios in which administrators in

separate policy domains manage their own

local security policies and identities in order

to support mutually beneficial transactions

between their domains. For the businesses

managing these policy domains, federated

identity can mean reduced administrative

costs and risk exposure (through more

equitable allocation of identity management

responsibility and adherence to privacy

regulations). For the end-user, federation

can improve their experience by reduced

sign-on and help desk calls.

Web services are the latest candidate

technology for enabling distributed

computing. Web services are application

components that communicate over open

protocols like HTTP using the XML-based

SOAP messaging framework. Web services,

with broad industry support and emerging

stability in standards, are likely to succeed

where previous technologies for distributed

computing (e.g. RMI, CORBA, etc) failed

to become ubiquitous.

Both federated identity & web services

promise integration through loose-

coupling. Compared to alternative

technologies for distributed computing,

web services allow business partners to

connect their systems together without

necessarily agreeing on technologies,

platforms, and operating systems. Similarly,

federated identity technologies allow

companies to connect their identity systems

to those of their partners; sharing identity

information with each other without

having to agree on internal directory

structure, security infrastructure, etc –

instead agreeing on a more abstract

standardized layer above.

Federated identity & web services both

complement and are dependent on each

other. On the one hand, the standards for

federated identity take advantage of the web

services standards stack. In this sense, the

federated identity standards can be seen as

built on top of web services. More interest-

ingly, the federated identity standards can be

used within web services transactions. Web

Services transactions blur the boundaries

that separate business partners by the flow

of application data across them. So too

must identity management mechanisms –

identity must flow across these boundaries

as well, accompanying the fundamental

transaction data. Standard syntax for

identity information allows it to be

expressed within the SOAP message along

with the transaction data.

This paper will examine how two key

standards for federated identity, the Security

Assertions Markup Language (SAML) and

the Liberty Alliance’s ID-Web Services

Framework (ID-WSF) can be used with WS-

Security, (the recently standardized

specification for message-layer SOAP

security) to enable federated & secure web

service transactions.

1.1. Motivating use case

Acme.com provides a web-based purchasing

application to its purchasing officers. When

such a purchasing officer indicates that they

wish to purchase products from a supplier,

Acme.com sends a SOAP request to a SOAP

service at the appropriate supplier (e.g.

Beta.com).

Acme and Beta have the following

requirements for the architecture:

56 1363-4127/04/© 2004, Elsevier Ltd

Federated identity and web servicesPaul Madsen

[email protected]

Paul Madsen works at

Entrust Inc. in the Advanced

Security Technologies group

where he explores the

security challenges and

opportunities of the evolving

Web Services & federated

identity architectures.

He represents Entrust in a

number of standards

activitities, including the

OASIS Security Assertions

Markup Language (SAML)

Technical Committee, and

the Liberty Alliance, an

industry initiative for

federated identity on the Web.

Within the Liberty Alliance,

he has been an editor of

technical specifications, chair

of the Security, Trust,

Security & Privacy sub-team,

and vice-chair of the

Architecture Expert Group.

Prior to joining Entrust, he

designed a Web-based travel

management program using

XML messaging between

airline, travel agent systems

and mobile devices. Prior to

that he helped designed and

implement a document

management system and

developed electronic

document delivery systems

for technical documentation.

Mr. Madsen has over 9 years

experience in structured

markup languages and Web

application development. He

holds an M.Sc. in Applied

Mathematics and a Ph.D. in

Theoretical Physics from the

University of Western

Ontario and Carleton

University respectively.

mailto:[email protected]

http://Acme.com

http://Acme.com

http://Beta.com

• Must be based on open standards.

Neither company is willing to invest in a

one-off proprietary solution as the cost

of such a solution could not be

amortized over transactions with other

business partners.

• The SOAP messages’ authenticity,

integrity & confidentiality must be

ensured. Beta must be confident that if it

processes a purchase order, then it was

indeed from Acme and the details of the

order must not have been changed in

transit. As the purchase order may

contain payment information, Acme

requires that the messages be protected

against prying eyes.

• Beta is unwilling to maintain accounts

for the individual Acme purchasing

officers as it doesn’t want the ongoing

burden of managing such accounts as

Acme hires & fires its employees.

Before we present an architecture that

can address these requirements, the first

requirement of a standards-based solution

motivates a review of the standards in the

space.

2. Standards

2.1. Security Assertion MarkupLanguage

The Security Assertion Markup Language

(SAML) [SAML] is an XML-based

framework for communicating user

authentication, entitlements and attribute

information. As its name suggests, SAML

allows business entities to make assertions

regarding the identity, attributes, and

entitlements of a subject to other entities,

which may be a partner company, another

enterprise application etc.

SAML is being standardized under the

auspices of the Organization for

Advancement of Structured Information

Science (OASIS). SAML is currently at

version 1.1, version 2 is expected to be

ratified by OASIS in the Autumn of 2004.

2.1.1. SAML components

SAML is composed of a number of distinct

(but interrelated) components.

• Assertions

• Protocols

• Bindings

• Profiles

2.1.1.1. Assertions

An assertion is a package of information

that supplies one or more statements made

by a SAML authority. SAML defines three

different kinds of statement that can be

created by a SAML authority and placed

within an assertion.

• Authentication: The specified subject was

authenticated by a particular means at a

particular time.

• Attribute: The specified subject is

associated with the supplied

attributes.


Information Security Technical Report. Vol. 9, No. 3 57

Figure 1: SAML Authentication Statement

<Assertion issuer = " ">

<Signature>

<Conditions>

<AuthnStatement>

<Subject>

• Authorization Decision: A request to

allow the specified subject to access the

specified resource has been granted or

denied.

The outer structure of an assertion is

generic, providing information that is

common to all of the statements within it.

Within an assertion, a series of inner

elements describe the authentication,

attribute, authorization decision, or user-

defined statements containing the specifics.

Figure 1 illustrates the high-level structure

of a SAML authentication assertion.

The subject of the assertion is specified in

the <Subject> element within the

<AuthnStatement> element. The

issuing authority (specified in the Issuer

attribute on the <Assertion> element)

inserts its signature within the <Signa-ture> element. The issuer uses the <Con-ditions> element to constrain the use of

the Assertion (e.g. to stipulate that it must

be used within a certain period of time.)

2.1.1.2. Protocols

SAML defines pairs of XML-based data

structures – request and response messages

– by which one actor requests that another

return an assertion of a specified type. Each

request message specifies the particular

elements required in the corresponding

response message.

2.1.1.3. Bindings

Mappings from SAML request-response

message exchanges into standard messaging

or communication protocols are called

SAML protocol bindings. For instance, the

SAML SOAP Binding defines how SAML

protocol messages can be communicated

within SOAP messages.

2.1.1.4. Profiles

A profile of SAML defines constraints

and/or extensions in support of the usage of

SAML for a particular application – the

goal to enhance interoperability by

removing some of the flexibility inevitable

in a general usage standard.

As an example, the Browser/Artifact

Profile of SAML 1.1 specifies how SAML

authentication assertions are communicated

between an identity provider and service

provider through a combination of HTTP

redirects and SOAP messaging.

2.2. Liberty Alliance

The Liberty Alliance [LIB] is defining

specifications for network identity

management. The Alliance is an

undertaking by a group of companies and

government agencies to create open,

technical specifications for federated

identity. Liberty is following a phased

approach to the release of its specifications.

The first phase was the development of a

set of specification enabling simplified

single sign-on for end-users – this is

Liberty’s ID-Federation Framework (ID-FF).

Building on this first phase, Liberty’s

second phase is the development of a set of

specifications for identity based web

services and supporting infrastructure – the

ID-Web Services Framework (ID-WSF).

The following sections give brief

overviews of Liberty ID-Federation

Framework and ID-Web Services

Framework.

2.2.1. ID-Federation Framework

Single sign-on is the ability of a Principal to

authenticate herself once per session with

an Identity Provider and then use that

authentication to create sessions with

various Service Providers without having to

reauthenticate to those Service Providers.

ID-FF enables identity federation and

management. It can be used on its own or

XML

58 Information Security Technical Report. Vol. 9, No. 3

in conjunction with existing identity

management systems. This framework is

designed to work with heterogeneous

platforms and with all types of network

devices, including personal computers,

mobile phones, PDAs and other emerging

devices.

Liberty ID-FF includes support for the

following functionality (amongst other):

• Opt-in account linking – Allows a user

with multiple accounts at different

Liberty enabled sites to link these

accounts for future authentication and

sign-in at these sites. This linking of

accounts is also sometimes referred to as

federation of the accounts.

• Simplified Sign-On – Allows a user to

sign-on once at a Liberty ID-FF enabled

site and to be seamlessly signed-on when

navigating to another Liberty-enabled

site without the need to authenticate

again.

• Session management – Enables “single

sign-out”, i.e. once users sign-out of a

Liberty-enabled site, they can be

automatically signed-out on all the sites

they’ve linked to in that session.

Liberty ID-FF was defined on top of the

SAML standard and has been submitted to

OASIS for incorporation into SAML 2.

2.2.2. ID-Web Service Framework

The Liberty Alliance’s ID-WSF defines a

common framework for web services of

authentication, message protection, service

discovery & addressing, policy & metadata

advertisement, and data interaction (e.g.

query & modify).

While Liberty’s current focus is on

identity-based services (i.e. web services

that expose an interface on behalf of

particular individuals), much of the

functionality that the ID-WSF provides is

also relevant for identity-consuming services

(i.e. web services that expose an interface to

an application which requires, or is

enhanced by, knowledge of the identity of

the requestor or other actors).

Key functionality within ID-WSF

includes:

• Identity service discovery – enables

various entities to dynamically and

securely discover a user’s identity

services, and it responds, on a

permission-basis, with a service

description of the desired identity

service.

• SOAP Binding – provides a SOAP-based

invocation framework for identity

services. It defines SOAP Header blocks

and processing rules enabling the

invocation of identity services via SOAP

requests and responses.

• Authentication Service – provides SOAP-

based authentication facilities to web

service actors. An Authentication Service

allows a SOAP client to authenticate to

the service via any of the authentication

methods specified by the IETF’s Simple

Authentication and Security Layer

[SASL] specification; authentication

results in a SAML assertion being

returned to the client.

2.3. WS-Security

The OASIS WS-Security [WSS] standard

defines a set of SOAP extensions that can

be used when building secure Web services

to implement message level authentication,

integrity, and confidentiality.

WS-Security is the first component of

Microsoft & IBM’s so-called WS-*

framework for securing web services to be

submitted to a standards organization.

Other components include WS-Trust, WS-



Federation, WS-SecureConversation which,

although made public, as yet have not been

submitted to a standards body for industry

collaboration.

WS-Security defines a SOAP Header into

which message senders can insert security

information such as digital signatures,

encrypted data, and security tokens. WS-

Security defines a security token as a

collection of one or more claims, typically

made by the message sender and often

digitally signed by some trusted authority

so that the message recipient will have

reason to trust those claims. WS-Security

supports both binary security tokens (e.g.

X.509 certificates and Kerberos tickets) as

well as XML-based tokens – importantly,

including SAML assertions.

2.3.1.SAML Token Profile

The WS-Security SAML Token Profile

[STP] defines how to use SAML assertions

within the <ws:Security> header block

defined by the WS-Security standard. Figure

2 displays how a SAML assertion is

communicated from SOAP sender to

recipient within the <ws:Security> header

block. The SOAP sender would demonstrate

its right to the claims made within the

SAML assertion through the application of

a digital signature, the result placed in the

<ds:Signature> element.

3. Purchasing ScenarioRevisited

With an understanding of what the SAML,

Liberty, and WS-Security standards provide,

we can now examine how Acme and Beta’s

requirements for online procurement can be

met.

By basing the solution on SAML 1.1,

Liberty ID-WSF and WS-Security – the

requirement of a standards-based solution

will be met.

The integrity of the SOAP messages will

be protected by a combination of message-

level (using WS-Security) and transport-

level security mechanisms.

The solution will allow Beta to make

authorization decisions for Acme’s

purchasing officers based on their roles

within Acme (these agreed upon between

Acme and Beta out of band) rather than

their individual identities. This will

significantly decrease for Beta the burden of

managing identity for Acme’s purchasing

officers.

3.1. Solution model

An Acme purchasing officer logs in to the

Acme Online Procurement Application – a

web-based application that allows Acme’s

purchasing officers to check inventory, view

prices of specific products at different

XML


Figure 2: SAML Token Profile of WS-Security

<soap: Envelope>

<soap: Header>

<ws: security>

<saml: Assertion>

<ds: Signature>

<soap: Body>

suppliers, and place orders for those

suppliers. After the purchasing officer

submits an order, the procurement

application creates and sends a SOAP

request to the relevant supplier’s (e.g. Beta)

purchasing web service.

Before Acme sends the SOAP request,

the message will have appended to the

fundamental purchase order a SAML

assertion that will indicate the roles of the

initiating Acme purchasing officer. The

SOAP client will use the Authentication &

Discovery Service functionality of Liberty

ID-WSF in order to authenticate to its

local SAML authority and to be issued a

SAML assertion targeted at the Beta

purchasing web service. This SAML

assertion will be digitally signed by Acme

such that Beta can verify its integrity and

origin.

After receiving the SOAP message with

the included SAML assertion, Beta will

extract the role information from the SAML

assertion within the WS-Security

<Security> Header elements in order to

make an authorization decision regarding

the request.

3.2. Message Flow

The sequence of steps is shown in Figure 3.

The steps are:

1 An Acme purchasing officer with role of

“SeniorPO” authenticates to the Acme

online Purchasing Application and

submits a purchase order.

2 The Acme SOAP client authenticates to a

local Authentication Service.

3 The Authentication Service returns the

location of the Acme Discovery Service

along with a SAML assertion that the

SOAP client can present to that

Discovery Service.

4 The Acme SOAP Client presents the

SAML assertion it received from the

Authentication Service to the Acme

Discovery Service in its request for a

SAML assertion that can be presented to

Beta’s SOAP Service.

5 The Acme Discovery Service returns to

the SOAP Client a SAML assertion

targeted at the Beta SOAP Service. The

SAML assertion contains a SAML

Attribute statement expressing the fact

that the individual has the “SeniorPO”

role.

6 The Acme SOAP Client inserts the

SAML assertion in its request to the Beta

SOAP Service. Upon receipt, Beta

retrieves the role information and grants

appropriate authorizations to the

request.

3.2.1. XML Messages

Key SOAP messages from the sequence

described above are listed here (many

details are omitted for clarity and

reasons of space). The numbers for these

messages are highlighted in the diagram

above.



Figure 3: Message Flow for Use Case

Purchasingapplication

SOAP client SOAP service

Authenticationservice

DiscoveryService

Acme

1 6

5432

Beta

Message 2 – Acme SOAP client authenticates to Acme Authentication Service

The following XML instance represents the message the Acme SOAP client sends to its local

Authentication Service requesting that a SAML authentication assertion be created for the

individual purchasing officer who has initiated the purchase order.

<?xml version=“1.0” encoding=“utf-8”?>

<S:Envelope>

<S:Body>

<sa:SASLRequest authzID=“[email protected]” mechanism=“KERBEROS_V4”>

<sa:Data>jsd7fskdfsdf09gdkfg</sa:Data>

<sa:SASLRequest>

</S:Body>

</S:Envelope>

The Acme SOAP client uses Kerberos (as indicated in the mechanism attribute of the

<sa:SASLRequest> element) to authenticate to its local Authentication Service. It

communicates the username of the relevant purchasing officer to the Authentication Service

within the authzID attribute.

Message 3 - Acme Authentication Service returns ResourceOffering for Acme Discovery

Service to Acme SOAP Client

The following XML instance represents the message the Authentication Service returns to

the Acme SOAP client in response to its previous <sa:SASLRequest>

<?xml version=“1.0” encoding=“utf-8” ?>

<S:Envelope>

<S:Body>

<sa:SASLResponse serverMechanism=“KERBEROS_V4”>

<sa:Status code=“success”/>

<disco:ResourceOffering>

<disco:ServiceInstance>

<disco:Endpoint>http://discovery.acme.com</disco:Endpoint>

</disco:ServiceInstance>

</disco:ResourceOffering>

<sa:Credentials>

<saml:Assertion>

<saml:AuthenticationStatement>

<saml:Subject>[email protected]</saml:Subject>

</saml:AuthenticationStatement>

<ds:Signature></ds:Signature>

</saml:Assertion>

</sa:Credentials>

</sa:SASLResponse>

</S:Body>

</S:Envelope>

The Authentication Service returns two objects to the SOAP client, a

<disco:ResourceOffering> that indicates the URL (within the

<disco:Endpoint> element) at which the Acme Discovery Service is located and a

<sa:Credentials> element that contains a SAML authentication statement for the

Acme purchasing officer ‘[email protected]’.

XML



The SOAP client will now use the indicated endpoint URL and the provided SAML

assertion to send a query to the Acme Discovery Service – logically asking the Discovery

Service ‘Give me everything I need in order to compose a request to Beta’s purchasing

service on behalf of ‘[email protected]‘. This would be Message 4 in the sequence above.

Message 5 – Acme Discovery Service returns ResourceOffering and Credentials for Beta

SOAP Service to Acme SOAP Client

The following XML instance represents the message the Discovery Service returns to the

Acme SOAP client containing the information that client needs in order to compose a

request to the Beta SOAP service.


<S:Envelope>

<S:Body>

<disco:QueryResponse>

<disco:ResourceOffering>

<disco:ServiceInstance>

<disco:Endpoint>http://purchase.beta.com</disco:Endpoint>

</disco:ServiceInstance>

</disco:ResourceOffering>

<sa:Credentials>

<saml:Assertion>

<saml:AttributeStatement>

<saml:Subject>anonymous</saml:Subject>

<saml:Attribute AttributeName=“acme-role”>

<samlAttributeValue>

seniorPO

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>


</saml:Assertion>

</sa:Credentials>

</disco:QueryResponse>

</S:Body>

</S:Envelope>

The Discovery Service returns two objects to the SOAP client, a

<disco:ResourceOffering> that indicates the URL (the <disco:Endpoint>element) at which the Beta purchasing service is located and a <sa:Credentials>element that contains a SAML attribute statements for the Acme purchasing officer

‘[email protected]’.

Importantly, the actual identity ‘[email protected]‘ of the purchasing officer is not

expressed within the attribute statement – see the value of ‘anonymous’ in the

<saml:Subject> element. Instead, the role(s) that this purchasing officer has at Acme,

namely ‘SeniorPO’ are expressed in the <saml:AttributeValue> element.

In general, a Liberty ID-WSF Discovery Service plays two roles: 1) helping its clients

determine the location of particular services (i.e. discovery) and 2) issuing credentials to be

presented to those services. In this context, as the SOAP client already likely knows the






location of Beta’s purchasing service, the Discovery Service’s primary job is credential

issuance. The name ‘Discovery’ Service is consequently somewhat misleading.

Message 6 – Acme SOAP client sends request to Beta SOAP Service

The following XML instance represents the message the Acme SOAP client sends to the

Beta SOAP Service. The credentials the SOAP client received in message 5 above are inserted

in the WS-Security <ws:Security> header.


<S:Envelope>

<S:Header>

<ws:Security>

<saml:Assertion>

<saml:AttributeStatement>

<saml:Subject>anonymous</saml:Subject>

<saml:Attribute AttributeName=“acme-role”>

<samlAttributeValue>

seniorPO

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>


</saml:Assertion>

</ws:Security>

</S:Header>

<S:Body>

<acme:purchaseorder/>

</S:Body>

</S:Envelope>

The Acme SOAP client simply inserts the SAML assertion containing the role

information it received from its Discovery Service into the <ws:Security> element and

sends the purchase order to the URL specified in the <disco:ResourceOffering>previously returned by the Acme Discovery Service.

Beta would extract the role information and likely map ‘SeniorPO’ to a locally defined

role against which appropriate permissions for the purchasing service had been defined.

The Acme Discovery Service’s signature over the SAML assertion (carried in the

<ds:Signature> element) will allow Beta to verify that the assertion was issued by a trusted

party. Additionally, the message is sent over a secure HTTPS channel, ensuring the integrity

and confidentiality of the message contents. If there were intermediaries between Acme and

Beta, then comparable protections could be applied at the message layer using WS-Security

again.

4. Summary

Both web services and federated identity promise to enable integration between business

partners through loose-coupling – web services doing so at the application and messaging

layer, federated identity at the identity management layer. Given this shared promise, it

XML


shouldn’t surprise us that web services and

federated identity are ‘joined at the hip’;

federated identity both relies on the web

services standard stack for its supporting

infrastructure and enables more scaleable

web services transactions across policy

domains.

WS-Security is a key standard for

providing message-layer security for web

services; SAML and the Liberty Alliance are

the primary standards for federated identity.

This article has demonstrated how these

standards can work together to enable

secure web service transactions across

autonomous identity management domains.

References[SAML] – OASIS Security Services Technical Committee

http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=security

[LIB] – Liberty Alliance Project

http://www.projectliberty.org

[WSS] – OASIS Web Services Security Technical

Committee http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=wss

[STP] – OASIS Web Services Security – SAML Token

Profile http://www.oasis-

open.org/committees/download.php/7837/WSS-SAML-

15.pdf

[SASL] – Simple Authentication and Security Layer

http://www.ietf.org/html.charters/sasl-charter.html



http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

http://www.projectliberty.org

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

http://www.oasis-open.org/committees/download.php/7837/WSS-SAML-15.pdf



http://www.ietf.org/html.charters/sasl-charter.html

Federated identity and web services

Documents

Transcript of Federated identity and web services