Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

CA_transactionminder_securing_web_services

VIEWS: 63 PAGES: 14

									White Paper

eTrust™ TransactionMinder®: Securing Web Services

March 2005

Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Web Services Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Transport-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Application-Based Authorization and Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Application-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 XML Content Confidentiality, Integrity, and Authenticity . . . . . . . . . . . . . . . . . . .3 Trust Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Introducing eTrust™ TransactionMinder® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 eTrust TransactionMinder Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Shared Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Centralized Management of Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Extends the Existing Enterprise Security Model . . . . . . . . . . . . . . . . . . . . . . . . .5 Open, Platform-Neutral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 The eTrust TransactionMinder Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 eTrust TransactionMinder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 XML Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 eTrust Policy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 eTrust TransactionMinder Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 eTrust TransactionMinder Authentication Schemes . . . . . . . . . . . . . . . . . . . . . . . .6 XML Document Credentials Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Sessioning (using SAML assertions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Patent-Pending Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 WS-Security Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 eTrust TransactionMinder In Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Creating a DCC Authentication Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Creating a WS-Security Authentication Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Creating Authorization Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Defining the Web Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Personalizing Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 eTrust TransactionMinder Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 SSO Between Web Applications and Web Services . . . . . . . . . . . . . . . . . . . . . . . .12 Secure Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 WS-Security / SAML Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

2

Introduction
Companies worldwide are actively deploying Web services, both in intranet and extranet environments. While Web services offer many advantages over current alternatives, they still present key challenges, especially in terms of security. Computer Associates International, Inc. (CA), addresses Web services security with an innovative, standardsbased solution called eTrust™ TransactionMinder®. This document describes eTrust TransactionMinder in detail. This document is intended for technical people already familiar with Web services, XML security and eTrust™ SiteMinder®, the company’s market-leading access management software solution.

Application-Based Authorization and Audit Most companies provide authorization directly in the back-end application, which creates a “silo” infrastructure in which each application performs its own local authorization. Each application’s security needs to be managed independently, thus increasing administration overhead and complex updates. Likewise, each application often includes accounting and audit information which needs to be reconciled with the overall infrastructure to preserve security and consistency across the enterprise. Companies need to be able to validate the content of the message requesting a Web service before that message reaches the Web service, and we need to keep track of who (or what type of application) is trying to access the Web service. Application-Level Security Transport-level SSL can be complemented with XMLbased, application-level security, including message structure, XML content confidentiality, integrity, authenticity, and fine-grained XML content access control. Message Structure • Web Services Security (WS-Security). An XML framework that defines security extensions to the SOAP protocol (described in more detail later in this document).

Web Services Security
Web services security relies on authentication (verifying a user’s identity based on submitted credentials), authorization (granting access to specific resources based on an authenticated user’s entitlements) and accounting or audit (a record of activities). By and large, companies deploying Web services rely on traditional transport-level security for authentication and application-specific security for authorization and accounting or audit. Transport-Level Security Secure Socket Layer (SSL) is the most widely used transport-level data-communication protocol. SSL provides authentication (the communication is established between two trusted parties), confidentiality (the data exchanged is encrypted) and message integrity (the data is checked for possible corruption). SSL supports transport-level security between two SSL-enabled parties. This means that when the data is not “in transit” on the secure communication channel, it’s not encrypted, therefore it’s not secure. This is the case when you have multiple steps in a transaction. For example, when an application invokes Web service A for purchasing and Web service B for shipping, you need two SSL sessions. When the documents involved in the transaction are between two SSL sessions, they are vulnerable to attacks. This is the reason why transport-level security is not enough, particularly in multi-step Web services transactions.

XML Content Confidentiality, Integrity, and Authenticity • XML Encryption. Represents the encrypted content of XML data, the information that enables a recipient to decrypt it, and a mechanism for conveying encryption-key information to the recipient. XML Signature. Defines the representation of signatures on digital content, and procedures for processing those signatures. XML Signature provides detailed elements supporting data integrity, signature assurance, and nonrepudiation for Web services data.

•

Trust Management • Security Assertion Markup Language (SAML). Describes authentication, attributes, and authorization-decision objects (or assertions) that can be exchanged between trusted partners.

3

Figure 1: XML and Web Services Security Stack

Introducing eTrust TransactionMinder
eTrust TransactionMinder is a policy-based platform for securing Web services. eTrust TransactionMinder processes the security information provided in Web services requests. It builds upon the shared-services vision embodied in eTrust SiteMinder, the company’s flagship product for securing access to web-based documents and business applications within a single enterprise and across multiple partners. eTrust TransactionMinder is a layered product designed to be installable on an existing eTrust SiteMinder environment to support message-level XML security.

High-Level Security Frameworks (SAML, XACML, etc.)

Web Services Security (WS-Security)

XML Frameworks

Simple Object Access Protocol (SOAP) XML Digital Signature XML Encryption

Transport Layer (HTTP, FTP, SMTP, JMS, SIP, etc.)

Non-XML Frameworks

Transport-Level Security: Secure Socket Layer (SSL)
Transmission Control Protocol and Internet Protocol (TCP/IP)

Figure 1 shows the various layers involved in securing Web services. As previously mentioned, SSL is designed to encrypt a complete XML document and send it securely to a Web service provider. However, in many cases, there is a need to secure only parts of a document, whether it is being sent to another party or stored before being further processed. In this case, XML Encryption and XML Signature are used.

eTrust TransactionMinder Customer Benefits
Shared Service

The SOAP messaging framework is used to send requests to, and receive responses from, a Web service. SOAP is augmented with a security layer defined in the WS-Security specification. WS-Security is used to implement confidentiality (through XML Encryption) and message-level integrity (through XML Signature). WS-Security also defines 6 security token profiles: • Username token (together with an optional password digest). • XML tokens: SAML assertions, REL (digital rights management) documents, and XCBF (common biometric format) documents. • Binary tokens: X.509 certificates and Kerberos tickets. WS-Security defines how those security tokens are inserted in WS-Security headers sent as part of SOAP messages. The remainder of this document describes the company’s solution for securing Web services implementing the technologies presented above.

Security logic is externalized outside applications • Reduces development costs (developers can concentrate on business logic). Company-wide, policy-based authentication, authorization, and audit • Single point of access control and administration for the whole enterprise. End-to-end solution • Binds XML flows to user identities. Supports fine-grained, document-based credential checking and generation • Checks inbound messages for authentication and authorization (securing access to Web services). • Adds credentials and attributes to outbound messages (Web services requests). Federation • Describes user identities to partners (in WSSecurity headers). • Consumes credentials issued by partners (e.g., SAML assertions in WS-Security headers). Synchronized sessioning • Allows single sign-on (SSO) across multiple Web services used in the same transaction using SAML-based patent-pending sessioning technology. Reliability and high-availability • Load balancing, failover, multiple-level caching.
Centralized Management of Web Services

Single set of policies managed by delegated administrators • Security services enforce and implement security policies uniformly across the enterprise • Provides scalability. • Facilitates compliance with company policies and industry regulations.

4

Extends the Existing Enterprise Security Model Avoids creation of an isolated island of security • Web services are one of many resources that must be secured by the enterprise. Seamless integration with existing eTrust SiteMinderenabled sites • eTrust TransactionMinder leverages eTrust SiteMinder and provides SSO to eTrust SiteMinder-protected applications as well as Web services. Open, Platform-Neutral • Flexible deployment on industry-standard platforms (operating systems, Web services containers). Standards-based solution (XML/SOAP, WS-Security, SAML, XML Signature).

The eTrust TransactionMinder XML Agent intercepts the XML messages sent to a Web service protected by eTrust TransactionMinder, and interacts with the eTrust Policy Server to execute a set of shared services for protecting and managing networks of Web services. The eTrust TransactionMinder XML agent includes two processes that interface with each other through a private inter-communication protocol (please refer to Figure 3 for detail): • Web Agent process, which is a typical eTrust SiteMinder Web Agent. • XML Services (or XML SDK), including the following components: – XML Parser (Apache Xerces) – XSLT Processor (Apache Xalan, for executing XPath expressions) – SOAP Parser (Apache SOAP Toolkit) – XML Encryption and XML Signature libraries – SAML library (for processing SAML session tickets) – SSL library (for establishing SSL connection with the eTrust TransactionMinder optional Client API, described later in this document) – Log library (Apache LOG4J, used for eTrust TransactionMinder logs) – WS-Security handlers The eTrust TransactionMinder XML Agent uses an XML application programming interface (API) exposing an extensible architecture for dealing with various XML message standards. In addition, the XML API allows for code reuse across all of the XML agents, as well as integration with custom Web services environments. The eTrust Policy Server The eTrust Policy Server is the centerpiece of the centralized, policy-based management platform. eTrust TransactionMinder uses the same policy server as eTrust SiteMinder, with additional features designed to support eTrust TransactionMinderspecific functionality (XML-based authentication schemes and XML-specific variables, described later in this document). The eTrust Policy Server integrates with the eTrust TransactionMinder XML Agents as well as the company’s other products and agent types to provide a single platform for securely managing every aspect of a company’s e-business.

•

The eTrust TransactionMinder Solution
eTrust TransactionMinder is designed to be independent of the transport protocol and messaging framework used. eTrust TransactionMinder Overview Figure 2 shows eTrust TransactionMinder at the Web service provider’s site. eTrust TransactionMinder uses specific XML agents in conjunction with the eTrust Policy Server.
Figure 2: eTrust TransactionMinder Overview

Web Service(s) eTrust TransactionMinder XML Agent Internet Policy Server Policies define: – Authentication – Authorization – Audit – Federation – Session Mgt Web Services Consumers Back-end Application

User Directories

XML Agents The eTrust TransactionMinder XML Agent is a component built upon the existing eTrust SiteMinder Web Agent. The eTrust TransactionMinder XML Agent is tightly integrated with a variety of Web services infrastructures.

5

The eTrust Policy Server hosts the set of shared services delivered as part of the eTrust TransactionMinder solution. Its extensible and scalable architecture allows services to be added and enhanced as the security and management needs for Web services evolve. The eTrust Policy Server integrates with industrystandard LDAP implementations as well as relational database systems for centralized management of user identity and entitlement information. This information is used by the eTrust Policy Server for authentication and authorization.

the variable’s metadata to the eTrust TransactionMinder XML Agent: (a) the eTrust SiteMinder Web Agent process calls the XML SDK to resolve the variables that are based on the XML message, (b) another call to authorizeEX() is made to pass the values of the resolved XML variables.
Figure 3: eTrust TransactionMinder Process Flow

Web Service Container (e.g., Web Server) XML Document (SOAP Message)
eTrust TransactionMinder XML Agent eTrust SiteMinder
IPC XML Services (XML SDK) 8 Protected Web Service

1

3-4 6a-7a-7b

eTrust TransactionMinder Process Flow
An example of the steps for securing Web services with eTrust TransactionMinder is described below. The process flow described refers to some of the eTrust TransactionMinder XML Agent API calls. 1. A Web service consumer (or “client”) POSTs a request to a Web service using an XML document (the XML document may or may not be enclosed in a SOAP message). 2. The eTrust TransactionMinder XML Agent (eTrust SiteMinder Web Agent process) intercepts the message, checks the content type of the request provided in an HTTP header (text/xml) and queries the eTrust Policy Server to check whether the requested Web service is protected by eTrust TransactionMinder (this is done using the isProtected() call of the Agent API). 3. If the Web service is protected by eTrust TransactionMinder, the eTrust SiteMinder Web Agent process passes the XML message to the XML SDK. 4. If the authentication scheme used to protect the Web service is based on the XML message, the XML SDK gathers the appropriate credentials (using XPath expressions) and passes the data back to the eTrust SiteMinder Web Agent process. 5. The eTrust SiteMinder Web Agent process makes a login() call to the eTrust Policy Server. The eTrust Policy Server authenticates the user against the user data contained in the user directories configured with eTrust TransactionMinder. 6. If login() succeeds, the authorizeEX() call is made to the eTrust Policy Server to determine if the user is authorized to invoke the requested Web service. If there is an expression (“eTelligent rule,” described later in this document) with XML variables on the policy, the policy server returns

Web Service Consumer

2 5 6-6b-7

isProtected () login () authorizeEX ()

Netegrity eTrust Policy

7. In response to the authorizeEX() call, the policy server passes back a collection of policy server “responses”: (a) if any of the responses are based on the message (e.g., a SAML Session Ticket), the XML SDK is invoked to apply the responses to the message, (b) if the original XML message was modified when the responses were applied, the XML SDK is invoked to get the new XML message. 8. When the user is both authenticated and authorized to access the Web service, the eTrust TransactionMinder XML Agent allows the XML message used for the request to be passed on to the Web service. Note: Steps 6a and 6b only occur when there is an expression (eTelligent rule) configured on the policy server, Steps 7a and 7b only occur when response(s) are added to the policy.

eTrust TransactionMinder Authentication Schemes
eTrust TransactionMinder supports four messagelevel authentication schemes specifically designed to secure the XML documents used in Web services and other business-to-business transactions: • XML Document Credentials Collector (DCC) • XML Signature • Sessioning (expressed as a SAML session assertion)

6

•

WS-Security (supporting three security tokens: Username, X.509 certificate, and SAML assertion)

XML Document Credentials Collector In this authentication scheme, the security information may be contained in the envelope header or the business payload itself. This is the case where two business partners have agreed on a specific XML vocabulary for exchanging business documents. For example, a large online computer vendor may place orders for computer components with its partners using a specific XML format for purchase orders.

ticket. An encrypted security token includes a session ID bound to one or more public keys. The encrypted security token is put in the <saml:SubjectConfirmationData> element of the SAML assertion. If the SAML assertion is signed, the document includes a <Signature> element (imported from the XML Signature namespace). The company’s SAML session assertion can be delivered in three different formats: • HTTP header • SOAP message • Cookie WS-Security As mentioned earlier, eTrust TransactionMinder supports WS-Security 1.0 including three security token profiles: Username (with optional password digest), X.509 certificates, and SAML assertions).

eTrust TransactionMinder XML document credentials collector allows the Web service provider to define how the Web service consumer’s credentials are gathered and processed. The eTrust Policy Server provides the query to search for security information, encoded in an XML technology called XML Path (or XPath). Once collected, the credentials are checked against the user stores used by the eTrust Policy Server.
XML Signature Digitally-signed XML messages require a user directory containing identifications and public keys. The eTrust Policy Server uses these keys to verify that the message is unaltered and authenticated through the private key of the Web service requester. The eTrust TransactionMinder XML Agent verifies the signature and passes the certificate to the eTrust Policy Server. The eTrust Policy Server maps the Distinguished Name (DN) field of the certificate to the user store information and matches the request certificate to the certificate stored in the user directory. Sessioning (Using SAML Assertions) The Security Assertion Markup Language (SAML) is the basis for the eTrust TransactionMinder sessioning model. If several Web services are involved in a single transaction, eTrust TransactionMinder can set a policy server response to generate a SAML assertion including the encrypted eTrust SiteMinder session specification. eTrust TransactionMinder can sign the SAML assertion or the whole document. The eTrust TransactionMindergenerated SAML assertion is used as a session ticket across the Web services involved in the transaction, thus providing SSO to those Web services. Patent-Pending Technology The company has filed a patent application for its innovative sessioning technology based on a SAML

eTrust TransactionMinder WS-Security / SAML support has been thoroughly tested with multiple third-party vendors.
Interoperability tests included the following scenarios (described later in this document): • Sender-Vouches over SSL (trusting client certificate on SSL line) • Sender-Vouches, signed (over SSL or not) • Holder-Of-Key, signed (over SSL or not)

eTrust TransactionMinder supports encryption (WSSecurity producer) and decryption (WS-Security consumer) through specific eTrust Policy Server XML responses. • Using the WS-Security Username Token Profile, users can encrypt the SOAP envelope body and/or the username itself. • Using the WS-Security X.509 Certificate Token Profile, users can encrypt the SOAP envelope body. • Using the WS-Security SAML Token Profile, users can encrypt the SAML assertion and/or the SOAP envelope body. • eTrust TransactionMinder can decrypt any WSSecurity-compliant encrypted data.
WS-Security Process

Figure 4 describes how eTrust TransactionMinder processes incoming WS-Security-compliant requests (WS-Security consumer) and how eTrust TransactionMinder generates WS-Security-compliant requests (WS-Security producer).

7

1. The XML SDK uses the WS-Security Authentication Handler (WS-Security consumer service) to process the request: It parses the WSSecurity token, verifies required signatures, and decrypts encrypted content. It then passes the information to the eTrust Policy Server, which validates the certificate containing the public key used to verify the signature. If the protected Web service is expecting an encrypted message, the XML SDK can re-encrypt the message as it was before it originally processed it.
Figure 4: WS-Security Process

eTrust TransactionMinder In Action
This section describes typical eTrust TransactionMinder usage scenarios: • Creating a DCC authentication scheme • Creating a WS-Security authentication scheme • Setting up an authorization policy based on the SOAP message • Constructing and POSTing the SOAP message using the eTrust TransactionMinder Client Toolkit

Creating a DCC Authentication Scheme
The screenshots below show the creation of an XML Document Credential Collector authentication scheme. We map the credentials that will be used to authenticate the user at runtime. Partners (i.e., Web service consumer and Web service provider) agree on a schema defining authentication elements. In the example above, we use the CredentialHeader.xsd schema as shown in the Field Mapping window. To configure this authentication scheme, the eTrust TransactionMinder administrator opens the credentials schema and chooses the particular fields that contain the data that maps to the information of the user context (user name / password in this case). In effect, the eTrust TransactionMinder administrator creates an XPath expression that is executed at runtime, when the consumer invokes the Web service. In the snapshot below, we choose to put the user context in the SOAP envelope header. That information could also be in the SOAP envelope body.

Web Service Container (e.g., Web Server) XML/SOAP Inbound Request
eTrust TransactionMinder XML Agent
XML Services (XML SDK)

eTrust SiteMinder

IPC

WS-Security Authentication Handler

WS-Security Response Handler

Web service(s) protected bt eTrust TransactionMinder

XML/SOAP Outbound Request

eTrust Policy Server

2. eTrust TransactionMinder is able to produce WSSecurity information using the XML SDK’s WSSecurity Response Handler. This is the case when a Web service protected by eTrust TransactionMinder needs to make a request to another Web service (not necessarily protected by eTrust TransactionMinder). In this case, the WS-Security Response Handler processes the outbound request by creating the required WSSecurity token (Username, X.509 certificate, or SAML assertion), creating the timestamp (if required), signing the document (if required), and encrypting the security token and/or the SOAP envelope body (if required). eTrust TransactionMinder then wraps up the WSSecurity information in a SOAP message that the Web service can POST to another Web service within the same company or outside the company, to a partner or supplier.

8

Creating a WS-Security Authentication Scheme The following snapshot shows the consumer properties of the WS-Security authentication scheme.

Listing 1: WS-Security Header <SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/ envelope/ xmlns:xsd="http://www.w3.org/1999/XMLSchema xmlns:xsi="http://www.w3.org/1999/XMLSchemainstance"> <SOAP-ENV:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/0 6/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/ utility"> <wsu:Timestamp wsu:Id="WSdaf01a0f-c2246c1b-90c5-418500160b95"> <wsu:Created wsu:Id="WS7672d762-f43a79c9-2ef8-a8baae0a7e2d">2003-0330T17:08:20Z</wsu:Created> <wsu:Expires wsu:Id="WSae428212-e8dc-8dc7f19f-13c644a9738c">2003-0901T18:28:20Z</wsu:Expires> </wsu:Timestamp> <wsse:UsernameToken wsu:Id="WS3d7dbfc8e0d0-f5c4-0484-62313ebe5c8a"> <wsse:Username>mchanliau</wsse:Username> <wsse:Password Type="wsse:PasswordDigest">GMqyWWZ8xnxuoBw /XpHUAm3CYCE=</wsse:Password> <wsse:Nonce>8929265</wsse:Nonce> <wsse:Created>2003-0330T17:08:20Z</wsse:Created> </wsse:UsernameToken> </wsse:Security> <BillingInformation> <CustomerCredentials> <username>mchanliau</username> </CustomerCredentials> </BillingInformation> </SOAP-ENV:Header>

As with any other eTrust TransactionMinder authentication scheme, messages can be signed and sent/received over SSL. The following snapshot shows an eTrust TransactionMinder WS-Security response defining the producer properties. The response is set in the eTrust Policy Server to insert a WS-Security token in a SOAP document.

Using the policy server response set above, eTrust TransactionMinder produces the following Username token example.

<SOAP-ENV:Body> <purchaseOrder orderDate="2002-03-06" xmlns="urn:po-processor"> <shipTo country="US">Shipping Information inserted here</shipTo> </purchaseOrder> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

9

Creating Authorization Variables Authorization variables are based on the company’s eTelligent rules. eTelligent rules include a set of services designed to enhance the eTrust Policy Server’s authorization functionality. With eTelligent Rules, security administrators define specific security logic using graphical editors that don’t require custom development. The purpose of such security logic is to dynamically gain access to attributes about the user requesting a protected resource, the resource itself, and the remote services optionally invoked in the authorizationdecision process. Security administrators can use different types of variables in order to create security rules based on Boolean expressions evaluated at runtime. If a Boolean expression is evaluated as true by the eTrust Policy Server, the security policy to which it is attached is enforced. In this example we create an XML Body Variable that we call SumOfPrice. The Web service provider has defined the format of the business payload in an XML schema. In this case, the business payload is a purchase order (PO). We create an XPath expression by selecting the desired element(s) from the PurchaseOrder.xsd schema (<price> in our example), and we select the sum function (to add up the values of all the <price> elements in the PO). The result of this XPath expression is stored in the SumOfPrice variable.

Using the Advanced tab in the XML Body Variable Editor shown below, you can directly type in the XPath expression if you're familiar with XPath syntax. The following screenshot shows a policy expression using the Sum OfPrice variable we just created. The policy expression above defines the limit of the PO amount (5,000 in a pre-defined currency). We also specify a SOAP Action (Purchasing). If this expression is evaluated to true at runtime, i.e., if the total amount of the PO is equal to or less than 5,000 and the SOAP action is “Purchasing”, the policy fires, thus providing the authorization to process the PO. The PO is then handed over to the backend business application that will process it and a SOAP message will be returned by the Web service to the user indicating that the PO has been accepted by the Web service provider. Defining the Web Service Request

eTrust TransactionMinder provides a Client Toolkit (TK) that allows Web services consumers to make requests to the Web services provider. The eTrust TransactionMinder Client TK is a Java API including four public classes. We also provide a sample application (shown below) with a graphical user interface to help users understand the eTrust TransactionMinder Toolkit API. Typically, a client application makes calls to the eTrust TransactionMinder Client API to define a Web service request.

10

The screenshot below shows the WS-Security tab allowing you to define the security tokens to be enclosed in a WS-Security header.

The Web service can be personalized through user entitlement information passed to the Web service by eTrust TransactionMinder. The information to be passed is configured as responses to a successful authorization in the eTrust Policy Server. When a user has successfully been authenticated and authorized for that Web service, the eTrust Policy Server identifies which entitlements should be obtained about that user, retrieves them from the user store, and associates them with the Web service request by binding them to the XML message. This powerful feature eliminates the need for a Web service to keep its own entitlement database and handle the retrieval of entitlements in the application logic. Through eTrust TransactionMinder, these entitlements can be centrally and securely managed and associated directly with the user identity.

The eTrust TransactionMinder Client API allows a Web service consumer application to wrap XML documents in messages, and POST those messages to the Web service provider. The eTrust TransactionMinder Client API provides supports for: • Client-side and server-side SSL. • XML Signature: eTrust TransactionMinder supports the standard specification for signing XML documents. • Private / Public Keys: The eTrust TransactionMinder Client API allows you to generate private-public key pairs. • X.509 Certificate: The eTrust TransactionMinder Client API allows you generate self-signed X.509 certificates. Optionally you can generate a certificate signing request (CSR) for the private key and then submit the CSR to a certificate authority (CA). • WS-Security tokens. Note: The Basic Information, SSL, WS-Security, and XML Signature tabs are runtime features. The Private / Public Keys and X.509 Certificate tabs are utilities that generate keys and certificates to be used with the Basic Information, SSL, and XML Signature features. Personalizing Web Services Once eTrust TransactionMinder has successfully identified, authenticated, and authorized a user for a particular Web service, it has the ability to leverage the user identity (centrally managed by the eTrust Policy Server) to personalize the behavior of the Web service.

eTrust TransactionMinder Use Cases
eTrust TransactionMinder can be used in various business situations to meet customers' requirements: • Authentication Service • SSO to web applications and Web services • Secure Transaction Flow • Federation over Web services flows, based on the WS-Security SAML Token Profile: – Sender-Vouches: The intermediary uses WSSecurity / SAML credentials to access Web services on behalf of the user – Holder-Of-Key: The user obtains WS-Security / SAML credentials from a home site and accesses Web services at other sites
Authentication Service 1. The end-user (directly through a browser or indirectly through an application) visits the Authentication Service providing username / password or other cryptographic credentials (e.g., XML Signature). The Authentication Service can be a Portal application or a simple Web service. 2. eTrust TransactionMinder authenticates the enduser, creates a SAML session ticket and passes it to the Authentication Service. 3. The Authentication Service returns the session ticket to the end-user (in a SOAP message, HTTP header, or cookie). 4. The end-user invokes a Web service protected by eTrust TransactionMinder using the SAML session ticket (in a SOAP message, HTTP header, or cookie).

11

Figure 5: Authentication Service

3 1 Client 2 TxMinder Agent Authentication Service

4 TxMinder Agent 5
eTrust Policy Server

Web Service(s)

6. The portal application returns the SMSESSION and TMSAMLSESSION tickets to the end-user’s browser. 7. The end-user can access from her browser any .Net or J2EE web application protected by eTrust TransactionMinder using the SMSESSION ticket (SSO to web applications) or any .Net or J2EE Web service protected by eTrust TransactionMinder using the TMSAMLSESSION ticket (SSO to Web services). Secure Transaction Flow The end-user places a purchase order (business payload) by invoking a Purchasing Web service. The Purchasing Web service invokes the Shipping Web service to ship the items ordered in the purchase order. eTrust TransactionMinder protects both Web services and provides synchronized sessioning between them using a SAML session assertion. 1. eTrust TransactionMinder authenticates the enduser with the Document Credentials Collector (DCC) authentication scheme. 2. eTrust TransactionMinder creates the SAML session ticket and inserts it in the SOAP envelope header. 3. The Purchasing Web service invokes the Shipping web Service by posting a SOAP message that includes the SAML session assertion generated by eTrust TransactionMinder. 4. eTrust TransactionMinder processes the SAML session ticket.
Figure 7: Secure Transaction Flow

5. eTrust TransactionMinder processes the SAML session ticket. SSO Between Web Applications and Web Services 1. The end-user logs on to her Windows desktop providing username / password and accesses the portal via a browser.
Figure 6: SSO Between Web Apps and Web Services
Enterprise or Department Portal Portal app. that creates web service request 6 4 3 TxM Agent 5 .Net Web Service (IIS Web Server)

2

9

Portal log-in (using Windows log-in info) 1 Users (Internal & External)

7

.Net or J2EE Web Application or Web Service TxM Agent

eTrust Policy Server

Active Directory

SOAP Response

2. The portal authenticates the user using the Windows log-in information (NTLM). 3. The portal application creates a Web service request (XML document) and POSTs it to the .Net Web service protected by eTrust TransactionMinder. 4. The eTrust TransactionMinder agent intercepts the request using the Document Credential Collector (DCC) authentication scheme. 5. Upon successful authentication, eTrust TransactionMinder provides an SMSESSION ticket (eTrust SiteMinder session information) and a TMSAMLSESSION ticket (eTrust TransactionMinder session information) via HTTP headers that the .NET Web service returns to the portal application.

1 DCC Authentication Scheme

User

SOAP Message
<user creds> -----------------<Business Payload>

TxMinder Agent 2

Purchasing Web Service SOAP Message
<SAML Assertion> -----------------<Business Payload>

3

SOAP Response

TxMinder Agent 4 Netegrity Policy Server

Shipping Web Service

WS-Security / SAML Scenarios The WS-Security / SAML Security Token use cases described below illustrate support for cross-domain Web services chaining (Sender-Vouches scenario) and document-based federation (Holder-Of-Key scenario).

12

The SAML profile of WS-Security requires that security systems (such as eTrust TransactionMinder) support the Sender-Vouches and Holder-Of-Key subject confirmation methods in SAML assertions as defined in the WS-Security specification. Sender-Vouches Scenario In Figure 8, eTrust TransactionMinder is shown to be at both the Purchasing web site and Shipping web site. It doesn’t have to be the case. This scenario illustrates that eTrust TransactionMinder can be both a WS-Security / SAML consumer and/or producer. 1. eTrust TransactionMinder authenticates the user request using the Document Credentials Collector (DCC) authentication scheme. 2. eTrust TransactionMinder generates a SAML assertion and inserts it in the WS-Security header as part of the SOAP message. 3. eTrust TransactionMinder signs both the SAML assertion and the body of the message with the Enterprise private key (in this case, the Enterprise is the site that is exposing the Purchasing Web service). 4. The Purchasing Web service POSTs the SOAP message authorized by eTrust TransactionMinder to the Shipping Web service.
Figure 8: Sender-Vouches Scenario

Holder-Of-Key Scenario In Figure 9, eTrust TransactionMinder is shown to be at both the SAML Producer web site and Purchasing web site. It doesn’t have to be the case. This scenario illustrates that eTrust TransactionMinder can be both a WS-Security / SAML consumer and/or producer. The Web service consumer and the SAML Producer Web service may or may not be part of the same company (or Internet domain). 1. The user’s application (Web service consumer) signs the request using the user’s private key and posts it to the SAML Producer Web service. 2. eTrust TransactionMinder authenticates the user request using the XML Signature (DSIG) authentication scheme.
Figure 9: Holder-Of-Key Scenario

1 Web Service Consumer XML Request (XML Signature) Response (including SAML assertion)

SAML Producer Web Service 2, 3, 4

eTrust TransactionMinder XML Agent

5 SOAP Request (including SAML Assertion)

6

Purchasing Web Service

eTrust TransactionMinder XML Agent

Purchasing Web Service XML Request (DCC AuthN Scheme) 1 2, 3, 4

Web Service Consumer

eTrust TransactionMinder XML Agent

SOAP Request (WSS/SAML)

Shipping Web Service 5

eTrust TransactionMinder XML Agent

5. At the Shipping Web service, eTrust TransactionMinder authenticates the request using the WS-Security SAML Sender-Vouches authentication scheme (eTrust TransactionMinder checks the signature covering the SAML assertion and the message body, validates that the SAML assertion was issued by a trusted partner, and validates that the user is in the user store).

3. eTrust TransactionMinder generates the SAML assertion, inserts the user’s certificate into the SAML assertion, and then signs the SAML assertion with the Enterprise private key. 4. The SAML Producer Web service returns the signed SAML assertion just created (in a raw XML document or a SOAP response). 5. The user’s application inserts the SAML assertion in a WS-Security header as part of a SOAP request, and posts the request to the Purchasing Web service. 6. At the Purchasing Web service, eTrust TransactionMinder authenticates the request using the WS-Security SAML Holder-of-Key authentication scheme (eTrust TransactionMinder checks the SAML assertion signature and the user’s signature on the message body, validates that the SAML assertion was issued by a trusted partner, and validates that the user is in the user store).

13

Conclusion
eTrust TransactionMinder is designed to provide message-level, content-based security for authenticating and authorizing users and applications accessing Web services. It leverages eTrust SiteMinder, the company’s flagship product for managing and securing e-business environments, and extends it by providing capabilities to process XML documents used in Web service requests. eTrust TransactionMinder provides synchronized sessioning amongst multiple Web services used in a single transaction, both inside the company and between the company and its business partners. It fully supports XML and Web services security industry standards, which makes it interoperable with other standards-compliant third-party security applications.

For more information, call 1- 800-875-9659 or visit ca.com

© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informational purposes only. To the extent permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties of merchantability or fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, business interruption, goodwill or lost data, even if CA is expressly advised of such damages. MP276060405

14


								
To top