Upload
dangkhanh
View
215
Download
0
Embed Size (px)
Citation preview
1
Copyright © 2003 Jorgen Thelin / Cape Clear Software
Web Services Security Tutorial
A Web Services Security Overview andImplementation Tutorial
2
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
ModulesWeb Services Security RequirementsWeb Services Security FrameworkWeb Services Usage ScenariosSecurity Credentials and IdentityEmerging XML Security StandardsSecurity Implementation using InterceptorsLessons from Implementing Web ServicesSecurity
5
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
A Web Services Security Framework
Jorgen ThelinChief Scientist
Cape Clear Software Inc.
7
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
12
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
18
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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.
25
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
Identity, Securityand XML Web Services
Jorgen ThelinChief Scientist
Cape Clear Software Inc.
E-mail: [email protected]
34
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
AgendaThe Concept of IdentityWeb Services and IdentityInteroperable XML Security and IdentityExamples of Security Credentials in SOAPSingle-sign-onIdentity Awareness in Web Services
36
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
Typical XML Security Dialogue– Non Self-Validating Credentials
Need toquery thesecurityservice tovalidate thecredentials
47
Copyright © 2003 Jorgen Thelin / Cape Clear Software
Typical XML Security Dialogue– Self Validating Credentials
No need toquery thesecurityservice tovalidate thecredentials.Usually doneby thesecurityauthoritydigitallysigning thecredentials.
48
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
XML Security Standards
Current and Emerging Specificationsattempting to provide standardization of
XML security infrastructure
62
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
64
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
Customization Using Interceptors
Using an interceptor-based frameworkfor providing customized client-side and
server-side Web Service extensionbehaviour
81
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
85
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
Web Services Security Tutorial - Wrap-up
A Web Services Security Overview andImplementation Tutorial
107
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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
Copyright © 2003 Jorgen Thelin / Cape Clear Software
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