Web-services

1

Web-services & Federated Identity

ISSA- Motor City, March 18/04

Paul Madsen,

Senior Security Consultant

Entrust - Advanced Security Technologies

2© Copyright 2004 Entrust. All rights reserved.

Thesis

Web Services and federated identity both enable loosely coupled integration across autonomous domains

Today• Security for Web services is immature

in general, e.g. SSL• Federation is mostly for browser

based user single sign on• Weak connection between the two

Future– Federated Identity fundamental

building block for Web Services– Web Services fundamental building

block for Federated Identity


Agenda

What’s the Connection? Web Services Security Federated identity Federated Scenario


Web Services & Identity Inseparable

Web Service endpoints require identities, e.g. SSL certs

Web Services transactions are often on behalf of an individual whose identity must flow with messages, e.g. WS-Security

Authorization of Web Service transactions may depend on both identities, e.g. XACML

Web Services emerging as standardized interface for identity-based Web Services, e.g. Liberty ID-WSF

Web Services emerging as default standardized interface for provisioning identities, e.g. SPML


Web Services impact on Identity Management

Organizations have to think in new ways about identity for securing Web services

XML-DSIG

SOAP

SSL/TLSWAP

XML

SAMLHTTP XML Enc

WSDL

WSS

UDDI

GatewayWeb Service Provider

Domain 1 Domain 2

1.

2.

3.

4.Web Service Client


XML-DSIG

SOAP

SSL/TLSWAP

XML

SAMLHTTP XML Enc

WSDL

WSS

UDDI

App 1

App 2

App 3

Domain 1 Domain 2User Identity

Invoker Identity

Intermediary Identity

Trusted 3rd Party

Identity

Multiple Identities to manage


Agenda



client service

execution

SOAP

Basic Web Services Model


client service

servicedevelopment

clientdevelopment

development

execution

distribution

WSDL

UDDI

SOAP

Basic Web Services Model


client service

servicedevelopment

clientdevelopment

development

security

execution

distribution

WSDL

UDDI

Security Components

Services

ProxyGateway Proxy


Security Gateway

Sits in the DMZ, protects the internal network and internal service interfaces from the external network

XML-Dos attacks, terminates SSL, remote end-point authentication, coarse-grained authorization, schema validation

Cons– Sensitive information such as private keys sitting in the

DMZ

– Doesn’t protect applications from internal attacks


client service

servicedevelopment

clientdevelopment

development

security

execution

distribution

GatewayGateway

Today


client service

servicedevelopment

clientdevelopment

development

security

execution

distribution

GatewayGateway

WS-Policy +

Future


Security Proxy

Sits in the application environment Proxies security processing for

application it front-ends Performs fine-grained (at least role-

based) authorization Applies message-level privacy policy Integrates with policy management

infrastructure


Security Services

Provides security services to gateways and proxies

– Token Verification– Identification– Authorization– Etc

Accessed through standardized Web Services interfaces

Allows security policy to be defined, managed, and applied consistently across enterprise


How do they help

Security components will work together to apply policy-appropriate processing at execution time

May also be involved at distribution time, I.e. a services ‘unprotected’ WSDL is extended by security components to include security requirements of interface– E.g. sign the Body of the SOAP message

Intermediary-mediated policy negotiation– Finding an intersection of the security policies of both

enterprises


Flow

Sec-WSDL

WSDL

UDDI Query

Sec-WSDL

WSDL

SOAPSec-SOAP + policy

Sec-SOAPSOAP

SOAP

SOAP

Client Security Registry Security Service


Agenda



What is Network Identity?

19

A Network Identity is

a user’s overall global set of attributes constituting their various accounts


Network Identity?

Common Profile Info

Address, etc.

Credentials

Credentials

•Multiple credentials•Different strengths,

different apps•Can change

Unique Identifier

•Subjects/principals•Name, number, attributes •Unique in some scope•Various ‘nyms’

App,

Site

, or P

artn

er P

rofile

s

Consumer Profiles

Employer Profiles

•Roles, entitlements, policies

•Often specific to apps or sites

App, Site, or Partner Profiles


The Problem with Network Identity?

Multiple, disconnected identities scattered across

isolated Internet sites

21

Inconvenient and frustrating for users

Expensive to support

Continual reauthorization to disparate systems


Federated Identity Management

What is Identity management?

– Set of processes, and a supporting infrastructure, for the creation, maintenance, and use of digital

What is Federated Identity management?

– Agreements, standards, technologies that make identity and entitlements portable across autonomous domains.


What does federated identity provide?

For browser apps, improve the end user’s experience

Reduce the number of logins Increased effectiveness with wider

scope of authorized accessReduce help desk calls & simplify

administration -> ROI


‘Standards’

SAML – In the lead, early adoption gaining momentum– Multiple products, open source solutions in release or

development– Simple, narrow focus both best and most limiting attribute

Liberty Alliance– Consortium of customers & vendors– Standards effort driven (in part) by enterprise customers– Products, early implementations underway in consumer-facing

apps WS-* Framework

– Developed by IBM and Microsoft, with help from others– Well-integrated with full Web services stack, composable

architecture– Ambitious framework, broad scope, necessary but harder to

create


Dependencies

MSFT/IBM OASIS Liberty

WS-Fed(7/8/03)

WS-Security4/5/02)

Phase 1ID-FF 1.1(1/15/03)

Phase 1ID-FF 1.0(7/15/02)

SAML 1.0(11/5/02)

SAML 1.1(9/2/03)

Phase 1ID-FF 1.2(11/12/03)

Phase 2ID-WSF 1.0(11/12/03)

WS-Trust(12/18/02)

Phase 3(08/04)

WSS(2/04)

2003

2004

SAML 2.0(6/04)


SAML

Security Assertions Markup Language Provides authentication, authorization, and

attribute assertions between loosely coupled domains

Set of XML and SOAP-based services, protocols, and formats for exchanging authentication and authorization information

Emerging as interoperability syntax between different security technologies and/or realms

SAML 1.1 is latest OASIS Standard– Work underway on SAML 2.0


SAML

WS-Security profiles SAML for securing SOAP messages

Liberty uses SAML for Single Sign-On (SSO) in ID-FF

Liberty uses SAML to convey Identity to Web services in ID-WSF

Shibboleth uses SAML for SSO and Attributes Exchange

SAML is a building block


Liberty Alliance

Liberty is global member community defining specs for federated identity management

Liberty Alliance has built on SAML 1.1 to develop additional specifications

– Opt-in account linking

– Session management

– Authentication Context

– Permission based attribute sharing


Liberty Components

ID- Federation Framework– Enables identity federation and SSO through SAML—based

messaging

ID-Web Services Framework– Set of foundation services and mechanisms to support identity-

based services• Discovery Service

• Interaction Service

ID- Service Interface Specifications– Definitions for identity services

• Personal Profile

• Employee Profile

• Contact Book

• etc


SAML & Liberty overlap


SAML/Liberty convergence

Liberty has submitted ID-FF 1.2 into the OASIS SSTC as input to SAML 2.0

Further work will occur within SAML 2.0 stream Liberty will continue to evolve ID-WSF and ID-SIS

specs independent of SAML 2.0 efforts


WS-Federation

Proposal from IBM/Microsoft as part of broader WS-* (includes WS-Security, WS-Policy, WS-Trust, WS-SecureConversation)

Released to the public mid 2003 Not yet submitted to a standards body Significant overlap with Liberty

ID-FF/SAML


Liberty/WS-Fed convergence

Convergence discussions ongoing between Liberty management board and IBM/MSFT

General agreement that the barriers are not technological, rather political

If convergence happens, it implies a single standard for federated identity (given the Liberty/SAML convergence)

If convergence doesn’t happen, it won’t be the first time that the industry has not been able to agree


Agenda



Federated Supply Chain Scenario

Geoff is an employee of Acme Widgets, a leading manufacturer of widgets for the thingymajig industry.

Geoff's role within Acme is a Junior Purchasing Agent– Authorized to place parts orders with Acme's suppliers up to a

value of $1,000 at a time

Geoff occasionally deals with Acme's supplier Bolts-R-Us• Sporadic nature of Geoff's dealings there meant he often forgot

both the account name and/or the password, causing delay for Geoff and support costs for Bolts-R-Us.

• Bolts-R-Us has to create new accounts for Acme's new hires, an expensive process when the information needs to be verified by Acme


Liberty enabled Scenario

Geoff will not be required to establish an account at Bolts-R-Us. He will be able to access the appropriate resources there based on an authentication he performed to his own company

As Bolts-R-Us will not need to maintain accounts for Acme's individual Purchasing Agents, they will be unaffected as Acme's employees come and go.


Geoff’s Experience1. Geoff goes to Acme's intranet portal first thing

2. Geoff logs in using an X.509 certificate issued to him by Acme

3. Geoff sees a customized Acme interface, including a link 'Order at Bolts-R-Us'

4. As he knows Acme is running low on #45 bolts, Geoff clicks on 'Order at Bolts-R-Us' link

5. Geoff sees Bolts-R-Us's ordering interface

6. Geoff orders 20,000 #45 bolts at a unit cost of $0.10.

7. Geoff see's an alert that his order has failed because the amount exceeds his purchaing amount authorization

8. Geoff changes the order to 10,000 #45 bolts.

9. Geoff sees an acknowledgement that the order has gone through.


Message Flow1. Geoff authenticates to Acme-IDP.

2. Geoff clicks on 'Order at Bolts-R-Us' button, browser is sent to Bolts-R-Us with artifact

3. Bolts-R-Us requests SAML assertion

4. Acme-IDP returns SAML assertion for Geoff containing anonymous one-time identifier for Geoff.

5. Bolts-R-Us queries Acme-EIP for Geoff's EmployeeType.

6. Acme-EP returns Geoff's EmployeeType.

7. Based on returned roles, Bolts-R-Us can make authorization decisions with respect to what resources Geoff can access.


Request/Response<s:Body> <ep:Query> <ep:ResourceID>

http://eip.acme.com/sdfjs78 </ep:ResourceID>

<ep:QueryItem itemID="type"> <ep:Select>/ep:EP/ep:EmployeeType</ep:Select> </ep:QueryItem> </ep:Query>

</s:Body>

<s:Body> <ep:QueryResponse> <ep:Status code="ep:OK"/> <ep:Data itemIDRef="type"> <ep:EmployeeType> JuniorPurchasingAgent </ep:EmployeeType> </ep:Data> </ep:QueryResponse>

</s:Body>

Request

Response


Summary

Web Services offer standard architecture for distributed computing – likely to succeed where previous attempts have failed

Federated Identity makes identity portable across boundaries

Federated identity necessary building block for future Web Service-based business transactions

Web Services are key enabling technology for emerging federated identity architectures


Thank you


Entrust Web Services Webinar

When:

Wednesday, March 24

11:00am

Real World Customer Success with Identity Management

Clerical Medical Europe will talk first hand about the success of their Web Services deployment and how Entrust enabled them to efficiently manage the digital identities of internal and external users alike

Contact

Duncan Hoge

[email protected]

740-965-9493

Louise Popyk

[email protected]

313-359-4393

http://www.entrust.com/events

Web-services

Documents

security services

security gateway

security policy

xacml web services

thesis web services

security proxy

security policies

web servicesimpact