Web Services Security Tutorial - Object Management Group

1

Copyright © 2003 Jorgen Thelin / Cape Clear Software

Web Services Security Tutorial

A Web Services Security Overview andImplementation Tutorial

2


Copyright NoticeCopyright © 2003 Cape Clear Software.All rights reserved.The document is not intended for production and is furnished “as is”without warranty of any kind.All warranties on this document are hereby disclaimed including thewarranties of merchantability and fitness for a particular purpose.The presentation content is provided for your personal informationonly. Any commercial or non-commercial use of the presentation in fullor part, including use of any text or graphics requires a license fromCape Clear Software Inc.This presentation is protected by the US and EU copyright regulationsand international treaties.Trademarks

Cape Clear, Cape Clear Software, Cape Clear Studio, Cape Clear Server, andCape Clear Manager are trademarks of Cape Clear Software in the UnitedStates and other countries.Other company, product, and service names mentioned in this product maybe trademarks or service marks of others.

3


AbstractThis tutorial provides an assessment of the various security concerns andimplications for XML Web Services, and the different means to addressthem.A framework is presented outlining the variety of measures and approachesfor achieving end-to-end security for Web Services, leveraging any pre-existing security environments where possible.The various technical security aspects of authentication, authorization,confidentiality and integrity are explored, along with how they affect WebServices and how they relate to the business-driven security concepts ofidentity, single-sign-on, privacy, trust and non-repudiation.An overview is provided of the emerging XML security standards such asXML Digital Signatures (XML-DSIG), XML Encryption, Security AssertionsMarkup Language (SAML) and WS-Security, including how they combine toaddress the fundamental security requirements of line-of-business WebServices.Examples are shown of a common technique for implementing the securityrequirements for a Web Service application through the use of custom orpre-built client-side and server-side interceptor plugins, in a manner similarto existing Aspect-oriented programming concepts.Finally, some lessons from the initial experiences implementing and usingWeb Services security are provided, along with advice and guidance forfuture projects.

4


ModulesWeb Services Security RequirementsWeb Services Security FrameworkWeb Services Usage ScenariosSecurity Credentials and IdentityEmerging XML Security StandardsSecurity Implementation using InterceptorsLessons from Implementing Web ServicesSecurity

5


Resources

CapeSciencePapers, articles, tutorials, and webcasts for WebServices developershttp://www.capescience.com

Jorgen Thelin’s WeblogWeblog covering enterprise systems development,and especially Web Serviceshttp://www.TheArchitect.co.uk/weblog/

6


A Web Services Security Framework

Jorgen ThelinChief Scientist

Cape Clear Software Inc.

7


4 Main Concerns of a Security FrameworkAuthentication – identity

Who is the caller?How do we prove they are who they say they are?

Authorization – access controlWhat is the caller authorized to do?Is the caller permitted by perform the operation it isrequesting?

Confidentiality – encryptionHow do we prevent snoopers viewing our messages anddata?

Integrity – tamper-proofingHow do we prevent messages being tampered withbetween sender and receiver?

8


Non-RepudiationThis is ultimately the major businessrequirement for a security framework

Can a trading partner possibly claim that:They didn't send a messageThey sent a different message from the one youreceived

Requires framework support for:Authentication – we know who sent the messageIntegrity – the message did not change in transitAudit record storage – we can prove whathappened

11


Web Service Interaction Levels

12


Transport Level SecurityUses existing Web tier technology such as HTTP andSSLAuthentication

HTTP authentication schemes – Basic or DigestSSL client side certificates

AuthorizationURL access control policies in the web tierJ2EE Servlet declarative security constraints

ConfidentialitySSL encrypted connections

IntegrityPoint-to-point SSL encryption to avoid data interception

13


Message level securitySecurity data built in to the XML message text – usuallyas additional SOAP header fieldsAuthentication

SSO (single sign-on) header tokensSAML authentication assertions

AuthorizationSSO session detailsSAML attribute assertions

ConfidentialityXML Encryption specification

IntegrityXML Digital Signatures specification

14


Application level securityA Web Service application handles its own security scheme – forexample, UDDIAuthentication

App specific authentication messagesApp specific credential headers in other messagesApp maintains its own security domain

AuthorizationApp performs its own access control checks

ConfidentiallyApp can apply an encryption scheme to some or all data fields

IntegrityXML Digital Signature can be used for tamper detectionApp specific integrity data such as MD5 hash can be sent for some or all datafields

15


Conclusions – Key IssuesA Web Services security framework must supportexisting security products

Must be an end-to-end framework to avoid anysecurity gaps

New XML security specifications are not yet stabilizedor proven

Use existing proven Web tier security infrastructureuntil XML security specifications and infrastructure isvalidated

WS-I Basic Security Profile will deliver a standardizedXML security infrastructure over time

16


Web Service Usage Scenarios

17


Current Usage Scenarios

18


Web Services – Current Usage Scenarios

Enterprise Application Integration

Re-use of Existing Business Logic

Deploying Applications across Firewalls

EJB Component Reuse

Ad-hoc Reuse

19


Enterprise Application IntegrationUsage Scenario Description:

SOAP can be used to integrate Java and EJBs with logicdeployed in other enterprise systems such as CORBA and.NET.The best initial projects for Web Services in organizations ofteninvolve the reuse of existing back-end systems – with WebServices used to expose them in a new way.This approach has the added benefit that the focus of theproject has been the Web Services rather than developingsome new business logic.

Security Implications:For internal integration, the security implications for this havetended to depend on factors such as the sensitivity of theinternal information being passed around and whether theinformation ever moves beyond the internal firewall at anypoint (which can happen if, for example, branch offices areconnected over the Internet).

20


Re-use of Existing Business LogicUsage Scenario Description:

Exposing back-end logic to multiple types of clients at thesame time, such as Visual Basic and Java GUIs.Many projects have an attractive value proposition for usingmainstream developers (Visual Basic programmers, forexample) to develop the front-end clients while reserving theEJB programmers (a relatively small percentage of the verybest software developers) for developing business logic.

Security Implications:The security implications for this have tended to depend onfactors such as the sensitivity of the internal information beingpassed around (with authentication and access control beingcommon security solutions) and whether the information evermoves beyond the internal firewall at any point (which canhappen if, for example, branch offices are connected over theInternet) SSL has tended to be used in the cases wheredeployments have been across a combination of intranets andthe Internet.

21


Deploying applications across firewallsUsage Scenario Description:

SOAP (when HTTP is used as the transport layer) can beused to integrate applications or clients across firewalls.This has been particularly useful for projects deadlinesthat need to avoid the organizational issues usuallyinvolved with firewalls.This also has been useful for projects that involvedintegrating with business partners with heterogeneousfirewall security requirements.

Security Implications:The security implications of what is essentially ashortcut are often ignored due to tight deadlines.

22


EJB Component ReuseUsage Scenario Description:

The UDDI repository can be used by organizationsto make their existing business systems availablefor reuse within their organizations.The value proposition to organizations for suchprojects is not just the rapid return on investmentbut also new opportunities.

Security Implications:Because this is for internal use, organizations todate have been happy with the various useridentification systems in the UDDI registries.

23


Ad-hoc ReuseUsage Scenario Description:

Web Services technology allows organizations to exposeexisting (business) logic for reuse in ad-hoc EAIprojects.This is done by generating WSDL for existing logic(typically component-based logic such as Java, CORBA,or Enterprise JavaBeans) and registering them in aUDDI registry.An EAI project can then be reduced to looking up theregistry for a suitable service. An example is acompany implementing the logic for credit cardvalidation once, but making it available for reuseanywhere it is needed.

Security Implications:The security implications for such projects have tendedto be as varied as the projects.

24


Emerging Usage Scenarios

25


Web Services – Emerging Usage Scenarios

Point-to-point system integrationEnterprise application integrationTechnology integrationBusiness partner collaborationComposite business processesReducing I.T. lifecycle costsI.T. investment protection

26


Point-to-point system integrationUsage Scenario Description:

Web Services are ideal when ‘Lite’ internal integration needs existwithin an organization. ‘Lite’ integration is the transfer of data betweentwo or more systems. A typical scenario is when a company’s employeeinformation needs to be passed into various downstream applications.The threshold, however, stands at more complex integrationtechnology: for example, transaction processing, business processautomation, and so on. Web Services excels at communicating data,but currently not at operational processing. When composition ofbusiness services is required in a single atomic operation with complexworkflow, Web Services do not yet provide such mechanisms.

Security Implications:The security implications for such point-to-point integration projects willlargely depend on factors such as the sensitivity of the internalinformation being passed around and whether the information evermoves beyond the internal firewall at any point (which can happen if,for example, branch offices are connected over the Internet).Simple communication security technology such as SSL is usuallysufficient to address the security problems here.

27


Enterprise application integrationUsage Scenario Description:

Bridging across a complex architecture comprised of multiple systemsresiding on multiple platforms using different object models based ondifferent programming languages has previously required complex andexpensive EAI technology, but Web Services provides a more effectivecommunication technology for this than traditional EAI technology.However in many instances, Web Services currently lack many of theenterprise features of an EAI solution, especially around processmanagement, transactions, administration, and so on, although this willchange over time.

Security Implications:The security implications for such technology integration projects willprobably be the most critical technical issue. There are currently nostandards for mapping security features across all the different possibletechnologies being integrated, and this is even true when usingestablished EAI technology to some extent.Web services platform products are now starting to provide a unifyingsecurity layer when integrating disparate technologies by includingimplementations of all the basic security features such as userauthentication, access control, activity auditing and reporting that arerequired for enterprise applications.

28


Technology integrationUsage Scenario Description:

One of the largest categories of usage scenarios for web services at the moment isabout the integration of diverse applications build on various differentimplementation technologies – i.e. true technology integration. This can involvesuch simple things are Microsoft VB clients talking to Java EJB systems – somethingthat just 12 months ago was considered virtually impossible to achieve.

Security Implications:Crossing a technology gap such as this usually highlights a corresponding securitygap that needs to be addresses also.So for example, a Microsoft VB (Visual Basic) program will most likely be obtaininguser identity information from the Windows ActiveDirectory system and the nativeNT Authentication scheme, while a Java program this VB program needs to talk tomay be using JAAS (Java Authentication and Authorization Services) technology toaccess an LDAP repository and the EJB (Enterprise JavaBeans) declarative securitysystem to control access.Web service platforms and security product vendors typically need to address thesecurity gap associated with the technology gap being bridged in one of two ways:

Use products and technology that can “map” credentials and user information between thedifferent security schemes (e.g. mapping Windows ActiveDirectory credentials to LDAPcredentials). This can obviously prove increasingly harder as the number of technologiesbeing used increases. This is where products such as Quadrasis’ EASI product can add greatvalue in an organization.Provide a unifying security layer in the web services platform that to a large extent canreplace the other existing security control mechanisms.

29


Business partner collaborationUsage Scenario Description:

Until the introduction of Web Services standards, business partnersfaced a difficult task to integrate their systems. Solutions were almostalways once-off, customer integrations. They were difficult toimplement and difficult to maintain. Changes at either partner couldeasily unravel the entire system. Collaboration between multiplepartners was strictly the domain of very large companies.For example, a yellow-pages site may be created for automotive partsvendors. A parts-provider may thus desire to provide a Web Service tointegrate their services into the marketplace through the UDDI registry.Web Services offer a standards-based way for business partners tocollaborate. The usual business and organizational issues will still bethe substantive amount of work that is done with a new businesspartnership. However, a common technology framework ensures thatthe focus is the business benefits rather than resolving technologicalintegration problems.

Security Implications:The key security requirement here is for standards to exist to avoid theneed to implement a custom security solution for each different partnerbeing communicated with, in the same way that the interactiontechnology has typically converged to SOAP and WSDL.

30


Composite business processesUsage Scenario Description:

Once backend services are available in a standardized mannerthrough exposing them with XML Web Services technologiesand standards like SOAP and WSDL, it makes the task ofreusing these core business services in new applications andnew usage scenarios significantly simpler.New business processes can be created by combining togetherthe existing business process components in innovative andexciting new ways, without having to worry about thetraditional technology barriers that have hindered much of thiswork in the past.

Security Implications:However, this can easily lead to exactly the same sorts ofproblems with security gaps as found in the TechnologyIntegration usage scenarios unless all the web services beingcomposed utilize the same set of XML security standards. Thisclearly highlights the importance of mature implementations ofstandards that have been widely adopted in the industry.

31


Reducing I.T. lifecycle costsUsage Scenario Description:

There are a number of factors that make Web Services abetter choice than older technologies from the perspective oflifecycle costs:Web Services are comparatively cheaper to implement, loweringthe investment part of any return-on-investment calculation.Web Services are generally quicker to implement (assumingproductivity tools like CapeStudio are used). This results in a fastertime to market and lower development costs.Lower ongoing maintenance and transaction costs. For example,because tools like CapeStudio automatically expose applicationlogic without coding, changes can be implemented quickly andseamlessly.

Security Implications:The trend towards the web services platform providing theunified security policy enforcement layer also createsconsiderable cost savings in that using a single security systemconsiderably reduces staff training and operations costs.

32


I.T. investment protectionUsage Scenario Description:

By allowing the functionality of existing I.T. systems to bepublished and re-used through SOAP, WSDL and UDDI isconsiderably more cost effective than re-designing fromscratch. Adding a web services interface onto an existinglegacy system can provide a new lease of life for the system,and take away much of the immediate pressure to replacehighly complex systems immediately.Using web service technology as the standardized form forpublishing and re-using application services also helps toprotect future I.T. investment, by providing a degree ofseparation between the interface definition and the underlyingimplementation.

Security Implications:The use of web service security standards based on XMLsimilarly provide a level of future proofing as theimplementation of this security framework can be changedwhile still relying on the technology-neutrality of standardsbased on XML communications.

33


Identity, Securityand XML Web Services

Jorgen ThelinChief Scientist

Cape Clear Software Inc.

E-mail: [email protected]

34


AbstractThe use of security credentials and conceptsof single-sign-on and “identity” play a bigpart in Web Services as developers startwriting enterprise-grade line-of-businessapplications. An overview is provided of theemerging XML security credential standardssuch as SAML, along with various “identity”standards such as Passport and Liberty. Weexamine how “identity aware” Web Serviceimplementations need to be, and the valuea Web Services platform can add in reducingcomplexity in this area, with lessons drawnfrom experiences using J2EE technology forreal-world security scenarios.

35


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

36


A Definition of IdentityDefinition from Cambridge DictionariesOnline:

Identity

[ noun ]

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

37


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

38


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 agentcomponent

Subjects must be distinguishable

39


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

40


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

41


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?

42


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.

43


Web Services and Identity 2Security and identity considerations for a WebServices 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 theapplication?

For example, customizing the data returned based on displaypreferences

44


Web Services and Identity 3To achieve interoperable security and identity, webservices require the followingStandard ways to:

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

Obtaining credential dataEg. Single-sign-on services such as Microsoft Passport orLiberty Alliance specifications

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

45


Types of Security TokensThe WS-Security specification set definesthe following tokens:

Unsigned security tokensUsername

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

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

46


Typical XML Security Dialogue– Non Self-Validating Credentials

Need toquery thesecurityservice tovalidate thecredentials

47


Typical XML Security Dialogue– Self Validating Credentials

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

48


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 aSAML Authority service

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

49


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

50


A Username Token in WS-Security SOAPHeader

<SOAP:Envelope xmlns:SOAP="..."><SOAP:Header>

<wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">

<wsse:UsernameToken><wsse:Username>jthelin</wsse:Username><wsse:Password Type="wsse:PasswordDigest">XYZabc123</wsse:Password><wsse:Nonce>h52sI9pKV0BVRPUolQC7Cg==</wsse:Nonce>

</wsse:UsernameToken>...

</wsse:Security></SOAP:Header><SOAP:Body Id="MsgBody">

<!–- SOAP Body data --></SOAP:Body></SOAP:Envelope>

51


A Binary X509 Certificate in WS-Security SOAPHeader

<wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"><wsse:BinarySecurityToken Id="X509Token"

xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"ValueType="wsse:X509v3"EncodingType="wsse:Base64Binary"

>MIIEZzCCA9CgAwIBAgIQEmtJZc0...

</wsse:BinarySecurityToken><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo> ... </ds:SignedInfo><ds:SignatureValue> ... </ds:SignatureValue><ds:KeyInfo>

<wsse:SecurityTokenReference><wsse: Reference URI=”#X509Token” />

</wsse:SecurityTokenReference></ds:KeyInfo>

</ds:Signature>...

</wsse:Security>

52


A SAML Assertion in WS-Security SOAP Header<wsse:Securityxmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"><saml:Assertion

xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"MajorVersion="1"MinorVersion="0"AssertionID="SecurityToken-mc375268"Issuer="mycompany"IssueInstant="2002-07-23T11:32:05.6228146-07:00" >...

</saml:Assertion><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo> ... </ds:SignedInfo><ds:SignatureValue> ... </ds:SignatureValue><ds:KeyInfo>

<wsse:SecurityTokenReference><saml:AssertionIDReference>

SecurityToken-mc375268</saml:AssertionIDReference>

</wsse:SecurityTokenReference></ds:KeyInfo>

</ds:Signature>...

</wsse:Security>

53


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

54


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

55


Microsoft .NET PassportMicrosoft .NET Passport is a suite of Web-basedservices that makes using the Internet andpurchasing online 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 facilitiestoProvide an XML interfaceSupport federationUse Kerberos v5 as the underlying mechanism forsecurely exchanging credentials

56


The Need for a Sign-on Standard– WS-Trust

The 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

57


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

58


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

59


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 / SSLconnections”)

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

Role-based access control lists applied at the granularity ofthe operation / method call.

This places control of security to applicationadministrators rather than developers.

60


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

61


XML Security Standards

Current and Emerging Specificationsattempting to provide standardization of

XML security infrastructure

62


Specifications and StandardsThere are lots of specifications flying aroundconcerning Web Services

Not all specifications are, or will be, “real”standards

The hard part is working out whichspecifications will “win” and become part ofthe standard infrastructure

Vendors and Architects need to plot an“intercept trajectory” for emergingstandards

63


“Real” Standards

64


When is a Specification not a Standard?Real standards are:

Published by a “recognized” standards developmentorganization – eg. W3C, OASISCreated through a process that allows public commentand feedbackAgreed and approved by a committee or groupconsisting of wide and diverse membershipPublished at a final or definitive status, such as "W3CRecommendation"Publicly available for reference - most usually bypublication on the Internet.Achieving both traction (usage) and sanction (backing)

Everything else is just a specification hoping tobecome a standard!

65


Security Standards OverviewThere are several specifications for various aspects ofXML and Web Services Security

The standardization process is still at a very earlystage in the evolution

The front runner specifications are:XML Digital SignaturesXML EncryptionSAMLWS-SecurityWS-TrustWS-PolicyWS-Secure ConversationWS-Security Policy

66


XML Digital SignaturesSource: W3CStatus: Final

Purpose:Specifies a process for digitally signing data andrepresenting the result in XMLDefine the processing rules and syntax for XML digitalsignatures

Notes:A serialised form in XML is defined for the signatureThe signatures can be applied to information in anyform, not just XML-formatted informationThe specification specifically excludes encryption.

67


XML EncryptionSource: W3CStatus: FinalPurpose:

Specifies a process for encrypting data and representingthe result in XML such that it is only discernable to theintended recipients and opaque to all others

Notes:The information that is encrypted can be arbitrary data(including an XML document), an XML element, or XMLelement contentThe result is an XML Encryption element that containsor identifies the cipher dataThe standard is generally accepted in the industry,although not yet in widespread use

68


SAMLSource: OASISStatus: FinalPurpose:

Uses XML to encode authentication and authorizationinformation in “assertions”

Notes:Defines a standardized XML format for credential andsecurity assertion dataThe authentication and authorization information can bemoved around systems within or between organizationsSAML is platform-independent and language-independentA key objective of SAML is to allow organizations toexchange date regardless of the security system theyuse

69


WS-SecurityOwner: Microsoft/IBM/Verisign – Now OASIS WSS-TCStatus: WIP for OASIS standardization processPurpose:

Provides a model for many levels of security needed for web services.A general-purpose mechanism to associate security-tokens with messagesDescribes how to encode binary security tokens in messages using SOAP HeadersIncludes enhancements to SOAP to provide quality of protection mechanisms

Notes:Builds on top of XML Digital Signatures and XML Encryption specificationsWS-Security Addendum adds

Facility for timestamp and TTL headersProvides greater protection when passing around passwords and security certificates

More Info:http://www-106.ibm.com/developerworks/library/ws-secure/http://www-106.ibm.com/developerworks/library/ws-secureadd.htmlWS-Security AppNotes - provide guidance to implementers of the WS-Securityspecification:http://www-106.ibm.com/developerworks/webservices/library/ws-secapp/

70


WS-Security - Security Token TypesThe WS-Security specification set definesthe following tokens:

Unsigned security tokensUsername

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

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

71


WS-Security Profile for XML-based TokensOwner: Microsoft/IBM/Verisign – Now OASIS WSSStatus: WIP for OASIS standardization processPurpose:

Describes a general framework to enable XML-basedsecurity tokens to be used with WS-Security

Notes:Two profiles that use this general framework areprovided for:

Security Assertion Markup Language (SAML)eXtensible rights Markup Language (XrML).

More Info:http://www-106.ibm.com/developerworks/library/ws-sectoken.html

72


WS-TrustOwner: Microsoft/IBM/Verisign/RSAStatus: Initial public draft release – SolicitingcommentsPurpose:

Uses the secure messaging mechanisms of WS-Securityto define additional primitives and extensions for theissuance, exchange and validation of security tokens.

Notes:WS-Trust also enables the issuance and disseminationof credentials within different trust domains.

More Info:http://www-106.ibm.com/developerworks/webservices/library/ws-trust/

73


WS-PolicyOwner: BEA/Microsoft/IBM/SAPStatus: Initial public draft release – Soliciting commentsPurpose:

WS-Policy FrameworkDefines a general purpose model and corresponding syntax to describe andcommunicate Web services policiesAllows Service consumers can discover the information they need to know tobe able to access services from a Service Providerhttp://www-106.ibm.com/developerworks/webservices/library/ws-polfram/

WS-Policy AttachmentsProvides a general-purpose mechanism for associating policy assertions withsubjects (services).Provides two approaches for making assertions:

policy assertions defined as part of the definition of the subjectpolicy assertions defined independently of and associated through an external bindingto the subject

http://www-106.ibm.com/developerworks/webservices/library/ws-polatt/

WS-Policy AssertionsSpecifies a set of common message policy assertions that can be specifiedwithin a policyhttp://www-106.ibm.com/developerworks/webservices/library/ws-polas/

74


WS-Secure ConversationOwner: Microsoft/IBM/Verisign/RSAStatus: Initial public draft release – Soliciting commentsPurpose:

Defines mechanisms for establishing and sharing securitycontexts, and deriving keys from security contexts, to enable asecure conversation

Notes:Built on top of the WS-Security and WS-Policy models toprovide secure communication between servicesWS-Security focuses on the message authentication model butnot a security context, and thus is subject to several forms ofsecurity attacks which this specification deals with

More Info:http://www-106.ibm.com/developerworks/webservices/library/ws-secon/

75


WS-Security PolicyOwner: Microsoft/IBM/Verisign/RSAStatus: Initial public draft release – Solicitingcomments

Purpose:Defines a model and syntax to describe andcommunicate security policy assertions within a largerPolicy FrameworkCovers assertions for security tokens, data integrity,confidentiality, visibility, security headers and the ageof a message.

More Info:http://www-106.ibm.com/developerworks/webservices/library/ws-secpol/

76


The Extensibility / Composability of XMLXML is designed to be inherently extensible

XML allows composable data structures bysupporting nested content

Extra data can be

Namespaces allow unique identification ofdata content

Composability does not require anyregistration with a central authority, just aunique namespace

77


Combining Standards / SpecificationsDue to the extensibility features of XML and SOAP, allXML and Security Specifications can generally becombined independently of each other

For example, add SOAP Headers for:WS-Security X509 Token header to assert identityWS-Policy header to signify:

Text encoding requirementsSupported languages

On occasions, ordering of combinations can besignificant

For example, do you “encrypt” then “digitally sign”, or“digitally sign” then “encrypt”

78


WS-I Basic Security ProfileFrom the charter for the new WS-I BasicSecurity Profile work group:

The BSP-WG will develop an interoperabilityprofile dealing with transport security, SOAPmessage security, and other Basic Profile-orientedsecurity considerations of Web Services

Although this will not cover all aspects ofthe emerging XML Security specifications, itwill certainly solidify the base levels.

79


ConclusionOnly partial agreement on the “realstandards” at the moment

Rival XML security specifications are still emergingXML security standards have not yet been widelyadopted

New XML security standards are not yetproven (so probably contain “holes”)

WS-I Basic Security Profile will deliver astandardized XML security infrastructure

80


Customization Using Interceptors

Using an interceptor-based frameworkfor providing customized client-side and

server-side Web Service extensionbehaviour

81


Interceptors

Interceptors are a general purpose conceptfor customizing and controlling messageprocessing

Interceptors provide a framework forchanging the steps involved in processing amessage

Interceptors can be used both server-sideand client side

82


Interceptor Plugin Architecture

83


Interceptor Plugins – Server-side

84


Interceptor Plugins – Client-side

85


ServerClient

Inbound and Outbound Interception PointsOften have similar functionality at “opposite” interceptor points

Eg. Server-side response interceptor may encrypt data in the reply just like theclient-side request interceptor encrypted data in the request message

The request message is:Outbound for the clientInbound for the server

The response message is:Inbound for the clientOutbound for the server

Encrypt Decrypt

Decrypt Encrypt

MessageProcessor

ClientProgram

MessageTransport

MessageTransport

86


The “Interceptor-Pair” ConceptUsually require a pair of interceptors to fulfil a task

One on the client sideeg. Request interceptor which encrypts the data in a field

One on the sever sideeg. Request interceptor which decrypt the field data

The functions of the interceptor pair need to match upEg. Both request interceptors cannot both encrypt or both decrypt

This is often referred to as an input-output interceptor pair

ServerClientEncrypt Decrypt

Decrypt Encrypt

MessageProcessor

ClientProgram

MessageTransport

MessageTransport

Interceptor pair #1

Interceptor pair #2

87


JAX-RPC Handlers (aka “SOAP Interceptors”)JAX-RPC Handlers

Provide a standardized interface for a “SOAPinterceptor” in Java

Operate on the SOAP object model defined bySAAJ (SOAP with Attachments API for Java)

Are part of the JAX-RPC extension module whichwill be in J2SE 1.4 and J2EE 1.4

Provides a MessageContext object for passing call-related context information between interceptorsand callbacks

88


JAX-RPC handler interface:javax.xml.rpc.handler.Handler

JAX-RPC interface javax.xml.rpc.handler.HandlerInterception Operations:

boolean handleRequest( MessageContext context )Called with each request message

boolean handleResponse( MessageContext context )Called with each response message

boolean handleFault( MessageContext context )Called with each fault message

Interrogation Operations:QName[] getHeaders()

The names of the header blocks processed by this Handler

Lifecycle Operations:void init( HandlerInfo config )

Called at the start of the lifecycle of the Handler instance

void destroy()Called at the end of the lifecycle for the Handler instance.

89


Microsoft Web Service Extensions (WSE)Web Services Enhancements 1.0 for Microsoft .NET

WSE is a class library that implements additional WebServices functionality and advanced protocols

Diagnostics and tracingWS-SecurityWS-RoutingWS-Referral

Provides a SoapContext object for passing call-related context information between interceptors andcallbacks

90


WSE Filter InterfacesInterface SoapOutputFilter

Interception Operations:void ProcessMessage( SoapEnvelope envelope)

Lifecycle Operations:Standard object constructorStandard object destructor

Interface SoapInputFilterInterception Operations:

void ProcessMessage( SoapEnvelope envelope )

Interrogation Operations:bool CanProcessHeader( XmlElement header, SoapContext context )

Lifecycle Operations:Standard object constructorStandard object destructor

91


Microsoft Web Service Extensions (WSE)Framework

WSE is based on thearchitectural model of apipeline of filters thatprocess inbound andoutbound SOAP messages

The pipeline controlsexecution order

Output filters are called inreverse order

Filters can be integratedwith ASP.NET or used instandalone code

Source: MSDN

More info: http://msdn.microsoft.com/library/en-us/dnwebsrv/html/insidewsepipe.asp

Filter ordering in the WSE pipeline

92


WSE Built-in Filters

Message routing(WS-Routing)

RoutingOutputFilterRoutingInputFilterMicrosoft.Web.Services.Routing

Dynamic updates torouting paths(WS-Referral)

ReferralOutputFilterReferralInputFilterMicrosoft.Web.Services.Referral

Timestamp support(WS-Security)

TimestampOutputFilterTimestampInputFilterMicrosoft.Web.Services.Timestamp

Authentication,signature andencryption support(WS-Security)

SecurityOutputFilterSecurityInputFilterMicrosoft.Web.Services.Security

Write messages to logfiles to help withdebugging

TraceOutputFilterTraceInputFilterMicrosoft.Web.Services.Diagnostics

PurposeOutputFilter

InputFilter

Namespace

93


Server-side InterceptorsBoth JAX-RPC Handlers and .NET WSEFilters fit naturally as server-sideinterceptors

Inbound interception points handle requests

Outbound interception points handle response

94


Client-side Interceptors – WSE Filters.NET WSE Filters fit innaturally as client-sideinterceptors too

Output filters handlerequestsInput filters handleresponses

Can directly reusefilters written forserver-side use

Eg. Decryptioninterceptor is alwaysan input filter

Source: MSDN

The WSE filter model

95


ServerClientRequestHandler

RequestHandler

ResponseHandler

ResponseHandler

MessageProcessor

ClientProgram

MessageTransport

MessageTransport

Client-side Interceptors – JAX-RPC HandlersJAX-RPC Handlers do not fit so cleanly as client-side interceptors:

handleRequest needs to do different things on the client-side(outbound) and server-side (inbound)handleResponse needs to do different things on the client-side(inbound) and server-side (outbound)

Need to write different JAX-RPC Handlers for client and server-side, or use a “configuration flag” to swap behaviour round

96


Combining Interceptors in “Chains”Interceptors are usually independent so canbe combined to achieve a desired function

For example, implementing a security policyfor a Web Service:

An interceptor to decrypt a SOAP message whichwas transmitted using XML EncryptionAn interceptor to recognise and decode SAMLauthentication assertion carried in the WS-Security header of the SOAP messageAn interceptor to perform a role-based accesscontrol check that the caller is a member of thegroup of people permitted to call this operation

97


Aspect-oriented Programming (AOP)Aspect-oriented Programming (AOP) is a way ofimplementing separation of concerns (SOC) insoftware.

AOP make it possible to modularize crosscutting“aspects” or “concerns” of a system.

For example:Logging policiesDiagnosticsTransactional contextsSecurity policy checks

Separation of Concerns (SOC) makes software mucheasier to develop, construct and understandMore info on AOP / AOSD at: http://aosd.net/

98


Interceptors as AOPInterceptors are a form of Aspect-oriented Programming(AOP)

Plug in an interceptor to deal with a specific function such asmessage validation or loggingCan change the external visible behaviour by adding aninterceptor to modify data before or after processingCan change the external visible behaviour by adding aninterceptor to “short-circuit” processing

Interceptors provide an ideal way to implement reusable“policy” aspects of a systemFor example: Access-control checks

Interceptors provide an extensibility framework for WebService protocols and applicationsFor example: Adding WS-Security credentials

99


Example – Custom Authentication HeadersScenario:

Client program needs to communicate with a WebService which requires an session-basedauthentication dialog

When calling a “start session” operation, theresponse message contains a custom headerwhich must be resubmitted with all futurerequests

100


Example – Custom Authentication HeadersImplementation:

A custom client-side interceptor can be written todeal with this specific situation

Client-side response interceptor:Preserve the authentication token found in the SOAPheader of the response message

Client-side request interceptor:Add any preserved authentication token into a SOAPheader of the next request message

101


Example Code – Custom Auth Headerspublic class SoapCorrelationHeaderInterceptor

implements Handler{

SOAPHeaderElement correlationHeader; // OK for single-threaded clientString correlationHeaderElementNamespace;String correlationHeaderElementName;Name correlationHeaderName;public void init( HandlerInfo info ){

Map cfg = info.getHandlerConfig();correlationHeaderElementNamespace = (String) cfg.get( "header.ns" );correlationHeaderElementName = (String) cfg.get( "header.name" );

}public void destroy(){}public QName[] getHeaders(){

return new QName[] {new QName( correlationHeaderElementNamespace, correlationHeaderElementName )

};}// More below

}

102


Example Code – Custom Auth Headerspublic boolean handleResponse( MessageContext context ){

try {// Dig into the response message and extract the contents of the token headerSOAPMessage soapMessage = ((SOAPMessageContext)context).getMessage();SOAPEnvelope soapEnvelope = soapMessage.getSOAPPart().getEnvelope();SOAPHeader soapHeaders = soapEnvelope.getHeader();if (this.correlationHeaderName == null) {

this.correlationHeaderName = soapEnvelope.createName(correlationHeaderElementName, null,correlationHeaderElementNamespace );

}if (soapHeaders != null) {

this.correlationHeader =extractNamedHeader( correlationHeaderName, soapHeaders );

}}catch (SOAPException se) {

throw new JAXRPCExceptionImpl( se );}return true; // Continue processing

}

103


Example Code – Custom Auth Headersprotected SOAPHeaderElement extractNamedHeader(

Name headerName, SOAPHeader soapHeaders )throws SOAPException

{Iterator iter =

soapHeaders.getChildElements( headerName );if (iter.hasNext()) {

SOAPHeaderElement soapHeaderField =(SOAPHeaderElement) iter.next();

// Remove from SOAP Message element treereturn soapHeaderField.detachNode();

}else {

return null;}

}

104


Example Code – Custom Auth Headerspublic boolean handleRequest( MessageContext context ){

if (this.correlationHeader != null) {try {

// Dig into the request message and add the contents of the token headerSOAPMessage soapMessage = ((SOAPMessageContext)context).getMessage();SOAPEnvelope soapEnvelope = soapMessage.getSOAPPart().getEnvelope();SOAPHeader soapHeaders = soapEnvelope.getHeader();if (soapHeaders == null) { soapHeaders = soapEnvelope.addHeader(); }soapHeaders.addChildElement( this.correlationHeader );

}catch (SOAPException se) {

throw new JAXRPCExceptionImpl( se );}

}return true; // Continue processing

}public boolean handleFault( MessageContext context ){

return true; // Continue processing}

105


ConclusionInterceptors provide a highly extensibleprocessing architecture

Interceptors allow incrementalenhancements to functionality throughwriting small amounts of code

Interceptors are the way enhanced protocolsupport is being added to SOAP platforms

Interceptors provide an ideal way toimplement custom security logic for WebServices

106


Web Services Security Tutorial - Wrap-up

A Web Services Security Overview andImplementation Tutorial

107


Modules CoveredWeb Services Security RequirementsWeb Services Security FrameworkWeb Services Usage ScenariosSecurity Credentials and IdentityEmerging XML Security StandardsSecurity Implementation using InterceptorsLessons from Implementing Web ServicesSecurity

108


Lessons from the First WaveExisting Web tier security infrastructure usuallysufficient for many internal projectsNecessary to accommodate third-party securityproducts already in use in the organizationEnd-to-end framework is necessary to avoid securitygapsOperational security procedure best practices forWeb services have yet to be developedXML security specifications have not yet been widelyadoptedRival XML security specifications are still emergingLack of experience and training on XML securitystandards is holding back adoption

109


Recommendations for the futureTrack usage scenarios in an organization todetermine security levelsStart with “proof-of-concept” projects togain experienceIntegration with Microsoft .NET securityschemes will be vitalWS-I Basic Security Profile will reduceinteroperability problems with current XMLSecurity standards.Don’t throw away the organization’s existingsecurity infrastructurePlan to implement end-to-end security

Documents

Web Services Security Tutorial - Object Management Group