Identity, Security and XML Web Services - OMG...any real-world deployment of a Web Services application Ultimately all security policy decisions are based on the caller’s identity

1

Copyright © 2003 Jorgen Thelin / Cape Clear Software Inc.

Identity, Securityand XML Web Services

Jorgen ThelinChief Scientist

Cape Clear Software Inc.

E-mail: [email protected]

2


AbstractThe use of security credentials and concepts of single-sign-on and “identity” play a big part in Web Servicesas developers start writing enterprise-grade line-of-business applications. An overview is provided of theemerging XML security credential standards such asSAML, along with various “identity” standards such asPassport and Liberty. We examine how “identityaware” Web Service implementations need to be, andthe value a Web Services platform can add in reducingcomplexity in this area, with lessons drawn fromexperiences using J2EE technology for real-worldsecurity scenarios.

3


AgendaThe Concept of IdentityWeb Services and IdentityInteroperable XML Security and IdentityExamples of Security Credentials in SOAPSingle-sign-onIdentity Awareness in Web Services

4


A Definition of IdentityDefinition from Cambridge DictionariesOnline:

Identity[ noun ]

Who a person is, or the qualities of a person orgroup which make them different from othershttp://dictionary.cambridge.org/define.asp?key=identity*1+0

5


What is Identity?At its most basic, the concept of Identity isabout:

Who you are

How you prove who you are

What that allows you to do

6


Identity – Who are you?An identity equates to a particular subject orprincipal

For example: Joe Bloggs …… Who lives at 123 My Street, Your Town

Usually equates to a person, but could alsobe a group, corporation, or even somethinglike an automated software agent component

Subjects must be distinguishable

7


Identity – Proof of identityHow do you prove who you are?

In real life, this is usually thru some officialdocuments such as:

Driving LicensePassport

In computing terms, a user has a set ofsecurity credentials such as:

username + passwordX509 certificates

8


Identity – PermissionsWhat does this identity prove about us?What does this identity allow us to do?

Some real life examples:Holding a UK passport proves I am a UK CitizenLosing my passport does not stop me being a UKCitizen; it just makes it harder to prove that I am.

A standard driving license shows I am allowed todrive a carI am not allowed to drive a Heavy Goods Vehicleunless I hold a HGV Driving License

9


Identity – Permissions and CredentialsThe permissions and entitlements for anidentity is ultimately determined by the setof credentials that were presented to assertthat identity.

Permissions and credentials are use to makepolicy enforcement decisions

Am I allowed to drive a Heavy Goods Vehicle?Am I allowed to work in the UK?Am I allowed to work in the US?

10


Web Services and IdentityHow does this affect Web Services?

Security and Identity is a fundamental requirement ofany real-world deployment of a Web Servicesapplication

Ultimately all security policy decisions are based onthe caller’s identity

The challenge is to how to represent and prove acaller’s identity in an open and interoperable way.

11


Web Services and Identity 2Security and identity considerations for aWeb Services application:

AuthenticationWho is the caller?How did they prove their identity?Do we trust the source of these credentials?

AuthorizationWhat is the caller allowed to do?

AttributesWhat other facts do we know about the caller?

For example, e-mail address, department, employee numberHow do we use this attribute information in the application?

For example, customizing the data returned based on display preferences

12


Web Services and Identity 3To achieve interoperable security and identity, webservices require the following

Standard ways to:

Representing security credential data in XMLEg. SAML – Security Assertions Markup Language specification

Obtaining credential dataEg. Single-sign-on services such as Microsoft Passport or LibertyAlliance specifications

Transport credential data in a SOAP messageEg. SOAP header fields defined in the WS-Security specification

13


Types of Security TokensThe WS-Security specification set defines thefollowing tokens:

Unsigned security tokensUsername

Signed security tokensX.509 certificates (binary)Kerberos tickets (binary)

XML security tokensAny XML token, such as SAMLUsually self verifying / signed

14


Typical XML Security Dialogue– Non Self-Validating Credentials

Need toquery thesecurityservice tovalidate thecredentials

15


Typical XML Security Dialogue– Self Validating Credentials

No need toquery thesecurityservice tovalidate thecredentials.Usually doneby thesecurityauthoritydigitallysigning thecredentials.

16


SAML v1.0SAML – Security Assertions Markup Language

An XML-based framework for exchanging securityinformationA specification published by the OASIS organization

The SAML specification defines:How to represent security credentials (“Assertions” inSAML parlance) using XMLAn XML message exchange protocol for querying a SAMLAuthority service

SAML does not define:How to obtain security credentials (“Assertions”) in thefirst place

17


SAML Assertion TypesSAML Authentication Assertions

The results of an authentication action performedon a subject by a SAML authority

SAML Attribute AssertionsAttribute information about a subject

SAML Authorization AssertionsAuthorization permissions that apply to a subjectwith respect to a specified resource

18


A Username Token in WS-Security SOAPHeader

–

19


A Binary X509 Certificate in WS-SecuritySOAP Header

” ”

20


A SAML Assertion in WS-Security SOAPHeader

21


Single-sign-on ServicesSSO Services provide:

a single point of logon and authenticationa standardized way to obtain suitable credentials toprove the authenticated identity

The main contenders using XML are:Liberty AllianceMicrosoft PassportProprietary security products such as NetegritySiteMinder are adding direct SAML interfacesWS-Trust – new spec for standardized XML interface

Still remains an area needing standardization

22


Liberty AllianceThe Liberty Alliance Project is a cross-industry group aiming to establish an openstandard for federated network identity

http://www.projectliberty.org/

The Liberty specification v1.0 has two mainfacets:

Single sign-onIdentity federation

23


Microsoft .NET PassportMicrosoft .NET Passport is a suite of Web-basedservices that makes using the Internet and purchasingonline easier and faster for users.http://www.passport.com/.NET Passport provides users with

Single sign-in (SSI)Fast purchasing capability at participating sites

Microsoft is upgrading the current Passport facilities toProvide an XML interfaceSupport federationUse Kerberos v5 as the underlying mechanism forsecurely exchanging credentials

24


The Need for a Sign-on Standard– WS-TrustThe need remains for a “sign-on standard” to avoidreliance on proprietary interfaces

WS-TrustA proposed specification in the WS-Security family

Provides a standardized interface for acquiring securitytokens

Still very early in the standardization process, but themost likely candidate for a common interface

http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-trust.asp

25


Identity-awareness in Web ServicesDo web services themselves need to beidentity-aware?

Not really, in most cases

A mature web services platform product such asCape Clear Server can handle almost all the“boilerplate” work of authentication andenforcement of access control lists

26


Identity-awareness in Web Services - 2Most standard authentication and authorizationfunctions are best done in a uniform manner by theplatform, rather than being implemented on anapplication-by-application basis

Interceptor plugins allow this to be a deployment policydecision rather than an implementation decision

Web Service application only needs to be Identity-aware if it needs to use attributes asserted for thecaller

For example, reading the delivery address from theuser’s MS Passport record

27


Ultimate Web Services platform securityUltimate goal will be declarative security functions forweb services just like EJB

So, having declarative statements of:Permitted authentication realms / single-sign-on services

Required transport security attributes(for example, “Callers must use encrypted / SSL connections”)

Required message security attributes(for example, “Messages must be digitally signed”)

Role-based access control lists applied at the granularity of theoperation / method call.

This places control of security to applicationadministrators rather than developers.

28


Summary“Identity” is one of the fundamental concepts in allWeb Service security mechanisms

Having a standard XML-based serialized form ofcredentials is vital for true end-to-end interoperability

Standardization of specifications for credentialexchange and single-sign-on using XML and SOAP arestill incomplete, so true interoperability is not yetpossible.

Use a mature Web Services runtime platform such asCape Clear Server to handle most “boilerplate”security tasks such as enforcing authentication andauthorization requirements.

Documents

Identity, Security and XML Web Services - OMG...any real-world deployment of a Web Services application Ultimately all security policy decisions are based on the caller’s identity