Skip navigation.

eDocs Home > BEA AquaLogic Service Bus 2.1 Documentation > User Guide > Securing Inbound and Outbound Messages

User Guide

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Securing Inbound and Outbound Messages

This chapter provides the information that you need to secure messages when using BEA AquaLogic Service Bus. AquaLogic Service Bus makes use of the proven WebLogic Security Framework in WebLogic Server 9.1. Before reading this information, and to have a full understanding of security, BEA recommends that you read the BEA WebLogic Server Security documentation.

The intended audience for this information is Application Architects, Security Developers, Application Developers, Server Administrators, and Application Administrators. For a description of these roles, see "Document Audience" in Understanding WebLogic Security.

Configuration of AquaLogic Service Bus is done in the AquaLogic Service Bus Console, which is described in Using the AquaLogic Service Bus Console.

This chapter includes the following topics:

 

AquaLogic Service Bus Security FAQ

What are the security features of AquaLogic Service Bus?

AquaLogic Service Bus is a messaging intermediary. As such, its security features ensure message confidentiality and integrity (message-level security through Web Services Security); secure connections between WebLogic Server, service clients, and business services (transport-level security); and authentication and authorization (access control).

How are AquaLogic Service Bus and WebLogic Server Security related?

AquaLogic Service Bus leverages the WebLogic Security Framework. The details of this framework are described in "WebLogic Security Framework" in WebLogic Security Service Architecture in Understanding WebLogic Security. Before configuring security in AquaLogic Service Bus, you must configure a WebLogic Server security realm and other server configurations (such as SSL) in WebLogic Server, as described in WebLogic Server Prerequisites.

What is Transport-Level Security?

Transport-level security refers to the transport protocols that secure the connection over which messages are transported. An example of transport-level security is HTTPS (HTTP over SSL). SSL provides point-to-point security, but does not protect the message when intermediaries exist in the message path. For more information, see Transport-Level Security.

What is Web Services Security?

Web Services Security (WS-Security) is an OASIS standard that defines interoperable mechanisms to incorporate message-level security into SOAP messages. WS-Security supports message integrity and message confidentiality. It also defines an extensible model for including security tokens in a SOAP envelope and a model for referencing security tokens from within a SOAP envelope. WS-Security token profiles specify how specific token types are used within the core WS-Security specification. Message integrity is achieved through the use of XML digital signatures; message confidentiality is accomplished through the use of XML encryption. WS-Security allows you to specify which parts of a SOAP message are digitally signed or encrypted. AquaLogic Service Bus supports WS-Security over HTTP, HTTPS, and one-way JMS. For more information on WS-Security see Web Service Security: SOAP Message Security 1.0 (WS-Security 2004) at the following URL:

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Which version of WS-Security does AquaLogic Service Bus support?

AquaLogic Service Bus supports Web Services Security 1.0.

Which WS-Security token profiles does AquaLogic Service Bus support?

AquaLogic Service Bus supports the following profiles:

Web Services Security: Username Token Profile 1.0, at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

Web Services Security X.509 Token Profile 1.0, at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

Web Services Security SAML Token Profile 1.0, at http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

What is Web Service Policy?

The Web Services Policy Framework (WS-Policy) provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web service specifications to describe a broad range of service requirements, preferences, and capabilities. For more information, see Web Service Policy.

What are Web Service Policy assertions?

The Web Services Policy Assertions Language (WS-PolicyAssertions) specifies a set of common message policy assertions that can be specified within a security policy. The specification defines general messaging-related assertions for use with WS-Policy. Separate specifications describe the syntax and semantics of domain-specific assertions for security assertions and reliable-messaging assertions.

Which version of WS-Policy does AquaLogic Service Bus support?

The policy assertions used in WS-Policy to configure message-level security in AquaLogic Service Bus are based on the assertions described in the December 18, 2002 version of the Web Services Security Policy Language (WS-SecurityPolicy) specification. This means that although the exact syntax and usage of the assertions in AquaLogic Service Bus is different from the specification, they are similar in meaning to those described in the specification. Note that the assertions in AquaLogic Service Bus 2.1 are not based on the latest update of the specification (13 July 2005). The policy assertions used in AquaLogic Service Bus are fully compatible with policy assertions used in WebLogic Server 9.0 and 9.1 Web services.

Are Access Control Policy and Web Service Policy the same?

No. Access control policy is a boolean expression that is evaluated to determine which requests to access a particular resource (such as a proxy service, Web application, or EJB) are granted and which should be denied access. Typically access control policies are based on the roles of the requestor. WS-Policy is metadata about a Web service that complements the service definition (WSDL). WS-Policy can be used to express a requirement that all service clients must satisfy, such as, all requests must be digitally signed by the client.

What is Web Services Security Pass-Through?

In a WS-Security pass-through scenario, the client applies WS-Security to the request and/or response messages. The proxy service does not process the security header, instead, it passes the secured request message untouched to a business service. Although AquaLogic Service Bus does not apply any WS-Security to the message, it can route the message based on values in the header. After the business service receives the message, it processes the security header and acts on the request. The business service must be configured with WS-Policy security statements. The secured response message is passed untouched back to the client. For example, the client encrypts and signs the message and sends it to the proxy service. The proxy service does not decrypt the message or verify the digital signature, it simply routes the message to the business service. The business service decrypts the messages and verifies the digital signature, and then processes the request. The response path is similar. This is sometimes called a passive intermediary.

What is a Web Services Security Active Intermediary?

In an active intermediary scenario, the client applies WS-Security to the request and/or response messages. The proxy service processes the security header and enforces the WS-Security policy. For example, the client encrypts and signs the message and sends it to the proxy service, the proxy decrypts the message and verifies the digital signature, then routes the message. Before the proxy service sends the response back to the client, the proxy signs and encrypts the message. The client decrypts the message and verifies the proxy's digital signature.

What is outbound Web Services Security?

Outbound WS-Security refers to security between AquaLogic Service Bus proxy services and business services. It includes both the request and response between business applications and proxy services. For more information, see About Outbound Web Services Security.

What is SAML?

SAML (Security Assertion Markup Language) is an OASIS standards-based extensible XML framework for exchanging authentication and authorization information, allowing single sign-on capabilities in modern network environments.

Which version of SAML does AquaLogic Service Bus support?

AquaLogic Service Bus supports SAML 1.1.

What WebLogic security providers does AquaLogic Service Bus support?

AquaLogic Service Bus supports the security providers included with WebLogic Server, such as the WebLogic authentication providers, identity assertion providers, authorization providers, role-mapping providers, credential mapping providers, and Certificate Lookup and Validation (CLV) providers. Additionally, AquaLogic Service Bus 2.1 supports the WebLogic SAML Identity Assertion Provider V2 and WebLogic SAML Credential Mapping Provider V2.

AquaLogic Service Bus 2.1 supports the new WebLogic XACML Authorization Provider. By default, the AquaLogic Service Bus 2.1 domains include only the WebLogic XACML Authorization Provider. However, if you desire, you can replace the XACML provider with the WebLogic Default Authorization provider, which is also supported in this release. BEA recommends using the XACML provider. For more information, see "WebLogic Security Providers" in the WebLogic Security Service Architecture in Understanding WebLogic Security.

What out-of-the box authorization providers are available?

AquaLogic Service Bus includes both the XACML Authorization provider and the WebLogic Authorization provider. By default, security realms in newly-created domains include the XACML Authorization provider. The XACML Authorization provider uses XACML, the eXtensible Access Control Markup Language.

Important: The WebLogic Authorization provider, which uses a proprietary policy language is named DefaultAuthorizer, is no longer the default authorization provider.

Does AquaLogic Service Bus support third-party security providers?

Third-party security providers, such as Netegrity, Oracle-Oblix, and RSA have not been tested and therefore have not been certified in AquaLogic Service Bus 2.1. However, the AquaLogic Service Bus security architecture supports the use of third-party authentication, authorization and role-mapping providers. Contact BEA customer support if you are interested in third-party security provider support in AquaLogic Service Bus 2.1.

What is the Certificate Lookup And Validation Framework?

The Certificate Lookup and Validation (CLV) providers complete certificate paths and validate X509 certificate chains. The two types of CLV providers are:

CertPath Builder—receives a certificate, a certificate chain, or certificate reference (the end certificate in a chain or the Subject DN of a certificate) from a Web service or application code. The provider looks up and validates the certificates in the chain.

CertPath Validator—receives a certificate chain from the SSL protocol, a Web service, or application code and performs extra validation, such as revocation checking.

At least one CertPath Builder and one CertPath Validator must be configured in a security realm. Multiple CertPath Validators can be configured in a security realm. If multiple providers are configured, a certificate or certificate chain must pass validation with all the CertPath Validators for the certificate or certificate chain to be valid. WebLogic Server provides the functionality of the CLV providers in the WebLogic CertPath provider and the Certificate Registry. For more information see "The Certificate Lookup and Validation Process" in WebLogic Security Service Architecture in Understanding WebLogic Security.

Does AquaLogic Service Bus support identity propagation in a proxy service?

Yes, AquaLogic Service Bus supports propagating identities by generating SAML 1.1 assertions in conformance with the Web Service Security: SAML Token Profile 1.0 specification (http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf). This is done by setting a SAML holder-of-key or sender-vouches WS-Policy on the business service routed to by the proxy.

If both transport-level authentication and message-level authentication exist on inbound messages to the proxy service, which identity is propagated?

If both transport authentication and message-level authentication exist, the message-level subject identity is propagated.

Is it possible to customize the format of the subject identity in a SAML assertion?

By default, the subject identity within an outbound SAML token is the same as the inbound username. The format of the subject identity can be customized by writing a custom SAML name mapper-provider. For more information, see Configuring a SAML Credential Mapping Provider in Securing WebLogic Server.

Is single sign-on supported in AquaLogic Service Bus?

Strictly speaking single sign-on (SSO) is not applicable to AquaLogic Service Bus messaging scenarios for several reasons. First, AquaLogic Service Bus is stateless; there is no notion of a session or conversation among multiple parties. Second, AquaLogic Service Bus clients are typically other enterprise software applications, not users behind a Web browser. Therefore, it is acceptable to require that these clients send credentials such as username and password on every request, provided that the communication is secured by means such as SSL or WS-Security. However, SSO between the AquaLogic Service Bus Console and the WebLogic Server Administration Console is supported. For more information, see "Single Sign-On" in Security Fundamentals in Understanding WebLogic Security.

Are security errors monitored?

Only WS-Security errors are monitored by the AquaLogic Service Bus monitoring framework. Transport-level security errors such as SSL handshake errors, transport-level authentication and transport-level access control are not monitored in this release. For more information, see Service Monitoring Details. However, it is possible to configure an Auditor provider to audit transport-level authentication and authorization.

Can I configure security for MBeans?

WebLogic Server enforces MBean access control. In AquaLogic Service Bus 2.1, a client must be in a WebLogic Server administrator role to invoke AquaLogic Service Bus MBeans. MBean access control is not configurable in this release.

 

About AquaLogic Service Bus Security

AquaLogic Service Bus uses the WebLogic Security Framework as building blocks for higher level security services, including authentication, identity assertion, authorization, role mapping, auditing, and credential mapping.

You configure AquaLogic Service Bus security in the AquaLogic Service Bus Console (see Figure 3-1). This console provides predefined rules that make it simple to secure messages; use secure transport protocols; manage users, groups, and roles; and view and add credentials. Before configuring AquaLogic Service Bus security, you need to configure some aspects of WebLogic Server security (see WebLogic Server Prerequisites).

Figure 3-1 AquaLogic Service Bus Console

AquaLogic Service Bus Console


 

To access the AquaLogic Service Bus Console, see "Starting the BEA AquaLogic Service Bus Console" in the Introduction of the Using the AquaLogic Service Bus Console.

 

WebLogic Server Prerequisites

AquaLogic Service Bus leverages the WebLogic Security Framework. To take full advantage of all the security features in AquaLogic Service Bus, you must perform some security configuration in WebLogic Server before configuring security in AquaLogic Service Bus. What you need to configure in WebLogic Server depends on your business needs. To make these WebLogic Server configurations, use the WebLogic Server Administration Console. For more information, see Securing WebLogic Server.

This section contains the following topics:

Main Steps for Securing AquaLogic Service Bus Domains

The main steps to configure WebLogic security for AquaLogic Service Bus domains are as follows:

WebLogic Server Administration Console

Details and Options for Securing AquaLogic Service Bus Domains

The following provides more detail and other possible security properties that you may need to configure in WebLogic Server besides those listed in Main Steps for Securing AquaLogic Service Bus Domains before configuring security in AquaLogic Service Bus. You can use the WebLogic Server Administration Console to make these changes.

 

Transport-Level Security

Transport-level security ensures that the connection is secure. You can configure transport security between client applications and AquaLogic Service Bus proxy services and between AquaLogic Service Bus and business services.

The following types of transport security are supported:

HTTPS Transport-Level Security

AquaLogic Service Bus supports HTTPS proxy services and HTTPS business services. HTTPS proxy services receive client requests over the HTTPS protocol. The response to the client is sent over the same HTTPS connection. Throughout this document this is referred to as inbound HTTPS.

Proxy services route messages to HTTPS business services over the HTTPS protocol. In this case, the proxy service is acting as an HTTPS client, opening an HTTPS connection to the business service. The response from the business service is received over the same HTTPS connection. Throughout this document, this is referred to as outbound HTTPS.

Note: AquaLogic Service Bus supports only one SSL network channel. This is called the default WebLogic Server (SSL) secure network channel.

The inbound and outbound scenarios are described in the following sections:

Inbound HTTPS Transport-Level Security

Inbound transport-level security applies to the connection between client applications and AquaLogic Service Bus proxy services.

You configure transport-level security for the proxy endpoints using the AquaLogic Service Bus Console while configuring proxy services. For information on how to do this, see Proxy Services in the Using the AquaLogic Service Bus Console.

The AquaLogic Service Bus Console allows you to configure HTTPS proxy endpoints for the following security levels:

None—Inbound HTTPS

When you specify HTTPS without BASIC or CLIENT CERT authentication, you secure your messages with one-way SSL. In one-way SSL, the client initiates the connection and WebLogic Server sends its certificate to the client. In other words, the client authenticates WebLogic Server. For information about configuring SSL certificates in WebLogic Server, see WebLogic Server Prerequisites.

Basic—Inbound HTTPS

When you specify HTTPS with BASIC authentication, authentication takes place over an encrypted channel so passwords are secure. After the one-way SSL connection is established, the client authenticates to WebLogic Server with a username and password. Trust is established by validating the username and password using the authentication providers configured in the WebLogic Server security realm. The client must send its username and password on the HTTP request header.

Warning: When creating an HTTPS proxy service endpoint, the initial transport access-control policy grants access to all requests. To enforce BASIC authentication, you must define a transport-authorization policy for the endpoint.

As mentioned in the warning, if a transport-authorization policy (security policy) for the inbound endpoint is not associated with the endpoint URL, authentication will not occur—the server will accept HTTPS requests without the username and password header and will not challenge the client to provide the username and password. Moreover, authentication will not take place if the client has preemptively included the BASIC username and password header in the request—the server will accept requests with invalid usernames or invalid passwords. After you configure a transport-authorization policy on the proxy service endpoint, the client will be forced to properly authenticate and the server will enforce this access-control policy. For information about security policies, see Configuring Proxy Service Access Control.

Client Certificates—Inbound HTTPS

Client Certificate authentication provides the highest level of transport security. In addition to the client authenticating WebLogic Server, WebLogic Server will authenticate the client application during the SSL handshake. This is sometimes called two-way SSL. For more information about SSL, see "Secure Sockets Layer (SSL)" in Security Fundamentals in Understanding WebLogic Security.

Although a full description of CLIENT CERT authentication for inbound HTTPS is out of scope in this document, the essentials are as follows: The SSL engine validates the client certificate, which includes making sure that the client holds the private key (via the SSL protocol), establishing a chain of trust from the client certificate to one of the trusted CAs (Certificate Authority) in the trust keystore, checking the certificate expiration, and so on. Additional validation can be performed by configuring WebLogic Server SSL to invoke the Certificate Lookup and Validation Framework during the SSL handshake. After trust in the certificate has been established, the certificate is passed to the identity assertion providers to extract the client identity.

Identity assertion providers are another component of the WebLogic Security Framework. Identity asserters can be configured to extract a field in the certificate to use as the client identity, typically the CN (common name) or E (email) of the SubjectDistinguishedName in the certificate. After extracting the field from the certificate, the extracted client identity is compared to the registered users in the authentication provider. If the client identity matches, the authentication provider collects all groups to which the user belongs. The end result is a signed Java Authentication and Authorization Service (JAAS) Subject with one principal that holds the client identity and one principal for each group to which the user belongs.

Note: If you have configured your server for two-way SSL with Client Certificate Requested But Not Enforced and you have not assigned a transport-level access control policy to the proxy service, the proxy service will accept requests over HTTPS without any client certificates. You must assign a transport-level access control policy to the proxy service.

For more information about identity assertion providers, see Security Fundamentals in Understanding WebLogic Security.

Outbound HTTPS Transport-Level Security

Outbound transport security applies to the connections between AquaLogic Service Bus proxy services and business services.

You configure transport-level security for the outbound endpoints while creating or editing a business service on the Transport Configuration page. For information on how to do this, see Business Services in the Using the AquaLogic Service Bus Console.

The AquaLogic Service Bus Console allows you to configure HTTPS outbound endpoints for the following security levels:

In None, Basic, and Client Certificate, the remote server certificate is validated during the SSL handshake. Hostname verification, if enabled, checks the SubjectDistinguishedName in the server certificate against the business service URL. For more information, see "Hostname Verification" under "Secure Sockets Layer (SSL)" in Security Fundamentals in Understanding WebLogic Security.

Note: Hostname verification should be enabled in a production environment.

None—Outbound HTTPS

When you specify HTTPS without BASIC or CLIENT CERT authentication, you secure your messages with one-way SSL. In one-way SSL, the proxy service initiates the connection, but does not authenticate itself to the business service.

Basic—Outbound HTTPS

When you specify HTTPS with BASIC authentication, authentication takes place over an encrypted channel so that passwords are secure. After the one-way SSL connection is established, the proxy service authenticates itself to the business service with a username and password. The proxy service uses the username and password associated with the service account that is defined for the business service. You specify the service account on the business service HTTPS Transport Configuration page and associate the username and password with the service account in the Credentials section of the Security Configuration module. For more information on credentials and service accounts, see Credentials.

Client Certificate—Outbound HTTPS

Client Certificate authentication provides the highest level of transport security. In this case, two-way SSL is established. During the SSL handshake, the proxy service authenticates itself to the business service with an SSL certificate. The SSL private-key and corresponding certificate that the proxy service uses to authenticate to the business service is supplied by the proxy service provider defined for that proxy service. This means that before specifying CLIENT CERT authentication, you must configure a proxy service provider and associate an SSL client key-pair with that proxy service provider. For more information, see Proxy Service Providers.

HTTP Transport-Level Security

The AquaLogic Service Bus Console allows you to configure AquaLogic Service Bus to require BASIC authentication for inbound and outbound endpoints. In inbound BASIC authentication, the client authenticates to WebLogic Server with a username and password. In outbound BASIC authentication, the proxy service authenticates itself to the business service using a username and password. Unlike HTTPS transport-level security, when using HTTP the business service does not authenticate itself to the proxy service.

Warning: Although, the AquaLogic Service Bus Console allows you to specify BASIC authentication for HTTP connections, this is strongly discouraged because the password is sent in clear text. However, it is safe to send passwords over HTTPS, as HTTPS provides an encrypted channel.

If you do use BASIC Authentication for HTTP outbound endpoints, you must specify a Service Account. This service account maps the username and password that AquaLogic Service Bus uses to connect to the business service. For more information, see Service Accounts.

Also if you use BASIC Authentication for HTTP inbound endpoints, you must associate a transport-authorization policy with the proxy service URI. For more information, see Basic—Inbound HTTPS.

Security for JMS, Email, FTP, and File Transport

This section provides information about protecting JMS, email, FTP, and file transport:

JMS Transport-Level Security

You can configure AquaLogic Service Bus to provide transport security over JMS for inbound messages to a proxy service and outbound messages from a proxy service. The connection to JMS servers can be secured using the T3S protocol (T3 over SSL). While this does not provide end-to-end security for JMS messaging, it does provide the following:

For a description of the T3 protocol, see Using WebLogic RMI with T3 Protocol in Programming WebLogic RMI.

Inbound JMS Transport-Level Security

As previously mentioned, for inbound transport, you can designate that the connection to the JMS server uses the T3S protocol. This is done while creating or editing a proxy service by selecting the Use SSL check box on the Transport Configuration page. For information on how to do this, see Proxy Services in the Using the AquaLogic Service Bus Console.

If the JMS administrator has restricted access to a JMS connection pool, you need to configure your proxy service to authenticate when connecting to the JMS server, as follows:

  1. To supply the username and password to the JMS server, create a (JMS) service account in the Project Explorer module in the AquaLogic Service Bus Console.
  2. While creating or editing a proxy service, designate the JMS service account on the JMS Transport Configuration page.
  3. Specify the username and password for the JMS service account using the Credentials section of the Security Configuration module. If the JMS server is in a remote WebLogic Server domain, trust must be established between the domains.

For information on how to configure service accounts, see Service Accounts in the Using the AquaLogic Service Bus Console.

Outbound JMS Transport-Level Security

For outbound messages, you can designate that the connection to the JMS server uses the T3S protocol. This is done while creating or editing a business service by selecting the Use SSL check box on the Transport Configuration page. For specific information on how to do this, see Business Services in the Using the AquaLogic Service Bus Console.

AquaLogic Service Bus supports access control for both the JMS connection pool and the JNDI entry for the JMS destination (queue or topic). You can configure the access-control policies for these two resources independently. When access control to the JMS connection pool has been configured, AquaLogic Service Bus must authenticate while establishing the connection to the JMS server. When access control to the JNDI entry has been configured, AquaLogic Service Bus must authenticate during the JNDI lookup. You must specify which service account to use for authentication when accessing either resource.

AquaLogic Service Bus can communicate with the local JMS server or a foreign JMS server.

For information on configuring access control to a WebLogic JMS Server and the JNDI entry, see Configuring JMS System Resources in Configuring and Managing WebLogic JMS and Securing WebLogic Resources.

To configure AquaLogic Service Bus to authenticate while establishing the connection to the JMS server, take the following steps:

  1. To supply the username and password to the JMS server, create a service account for the JMS server in the Project Explorer module of the AquaLogic Service Bus Console.
  2. Specify the username and password for the JMS service accounts using the Credentials section of the Security Configuration module.
  3. While creating or editing the business service, designate this service account as the JMS service account on the JMS Transport Configuration page, as shown in Figure 3-3.

To configure AquaLogic Service Bus to authenticate while looking up the JNDI entry for the JMS queue or topic, take the following steps:

  1. To supply the username and password for the JNDI entry, create a service account for the JNDI entry in the Project Explorer module of the AquaLogic Service Bus Console.
  2. Specify the username and password for the JNDI service accounts using the Credentials section of the Security Configuration module.
  3. While creating or editing the business service, designate this service account as the JNDI service account on the JMS Transport Configuration page, as shown in the following figure.

    4. Figure 3-3 JMS Transport Configuration Page

    JMS Transport Configuration Page


     

For specific information on how to configure service accounts, see Service Accounts in the Using the AquaLogic Service Bus Console.

Warning: When you employ a service account for authentication on outbound JMS transports, it can take up to 60 seconds for any changes you make to that service account (or to the policy) to take effect on the server.

Warning: By default, WebLogic Server JMS checks the ACL for each destination every 60 seconds. You can change this default time or ensure security checks are performed on JMS resources for every send, receive, and getEnumeration action on a JMS resource. To do so, set the weblogic.jms.securityCheckInterval attribute. A value of zero for this attribute ensures that an authorization check is performed for every send, receive, and getEnumeration action on a JMS resource.

Warning: For complete information about securing your applications, see Ensuring the Security of Your Production Environment in Securing a Production Environment.

Email and FTP Transport-Level Security

The supported security method for email or FTP transport is the username and password needed to connect to the email or FTP server.

To secure email, you must designate a service account as an alias for the username and password in the AquaLogic Service Bus Console. The service will use the username and password to authenticate to the SMTP server.

To secure FTP, in the AquaLogic Service Bus Console, select external_user and designate a service account as an alias for the username and password. The service will use the username and password to authenticate to the FTP server.

For information about how to add security to email and FTP transport, see "Adding a Business Service" in Business Services in the Using the AquaLogic Service Bus Console.

File Transport Security

The supported security method for file transport is the user login to the computer on which the files are located.

Transport-Level Security in Message Flow and Service Callout Actions

Transport-level security is available from within the proxy service pipeline from the following:

 

Message-Level Security (Web Services Security)

This section includes information on the following topics:

About Web Services Security

Web Services Security (WS-Security) is an OASIS standard that defines interoperable mechanisms to incorporate message-level security into SOAP messages. WS-Security supports message integrity and message confidentiality. It also defines an extensible model for including security tokens in a SOAP envelope and a model for referencing security tokens from within a SOAP envelope. WS-Security token profiles specify how specific token types are used within the core WS-Security specification. Message integrity is achieved through the use of XML digital signatures. Message confidentiality is achieved through the use of XML encryption. WS-Security allows you to specify the parts of the SOAP message that are digitally signed or encrypted. AquaLogic Service Bus supports Web Service Security over HTTP, HTTPS, and one-way JMS. AquaLogic Service Bus supports version 1.0 of WS-Security. For more information on WS-Security, see Web Service Security: SOAP Message Security 1.0 (WS-Security 2004) at the following URL:

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

AquaLogic Service Bus supports the following WS-Security token profiles:

Message-level security provides a level of flexibility not present in transport-level security. It can ensure that SOAP messages are secure even when the transmission involves one or more intermediaries and because the security measures are built into the message, the message can be protected point-to-point or end-to-end. The ability to specify which parts of the message are signed or encrypted is useful for routing messages in AquaLogic Service Bus. Message-level security provides confidentiality and integrity of the protected information where needed and along the entire message path.

Message-level security is configured using security policy statements, as specified by the Web Service Policy (WS-Policy). WS-Policy statements are bound to a business or proxy service. The mechanism that binds policies to services is called WS-PolicyAttachment. This mechanism describes how to bind the policies by adding policy references to WSDL documents. These policy references may point to policies included in the WSDL document or may be URL references to external policies. A WSDL may import other WSDLs containing policy attachments, either inlined or external. For more information about WS-Policy, see Web Service Policy.

When Web services security (WS-Security) is applied to a message, a new SOAP header is added to the message envelope. The new header includes the XML-DSIG digital signatures, security tokens, and other constructs. These security tokens can be used for the following:

When the recipient consumes the secured envelope, the cryptographic operations are performed in reverse order and the security header is removed. The recipient then verifies that the message conforms to its policy. For example, the recipient confirms that the required message parts were signed and/or encrypted and that the required tokens are present with the required claims.

Inbound Web Services Security

This section includes information on the following topics:

About Inbound Web Services Security

Inbound WS-Security applies to messages between client applications and AquaLogic Service Bus proxy services. It applies to both the request and the response between the client application and AquaLogic Service Bus.

As previously mentioned, you specify the details for inbound message-level security using WS-Policy statements, which are inlined within or referenced through WSDLs. AquaLogic Service Bus provides two types of inbound message security: active intermediary and pass-through.

Note: For SOAP-JMS, WS-Security is supported only for one-way messages. It is not supported for request/response messaging.

Client Request and Proxy Service Response

When a client makes a request to a proxy service and the proxy service responds to the request, two security scenarios are available:

Warning: Encrypted inbound response messages: If the response policy of the proxy service specifies encryption, the client must send its certificate to the proxy service on the request. The proxy service will encrypt its response using the client's public key. The client certificate must not be the same as the proxy service's encryption certificate. The client cannot be configured to use the same encryption credentials as the proxy service.

How to Configure a WS-Security Pass-Through Scenario

This following steps outline the basic steps for configuring a pass-through WS-Security scenario. Some steps are optional.

  1. Import the WSDL for the WS-Security-enabled business service into the AquaLogic Service Bus WSDL repository. This WSDL must have the Web service security policies attached to it. The policies may be inlined within the WSDL or the WSDL may have references to external policies.
  2. If the WSDL has external policy references, you must import these policies into the AquaLogic Service Bus WS-Policy repository and resolve the WSDL dependencies. For more information see "Resolving Unresolved WSDL References" in WSDLs in Using the AquaLogic Service Bus Console.
  3. If any operation request policy requires encryption, you must make sure the encryption certificate is embedded in the policy. Otherwise you will get an error message while creating the business service from this WSDL.
  4. When you create a business service, if any operation request policy includes an Identity assertion with Username Token as one of the supported token types, you must define a service account; map a username and password to this service account; and in the Service Account field, specify this service account for the Web Service Security Username Token. For information on how to perform these actions, see Service Accounts and Business Services in the Using the AquaLogic Service Bus Console.
  5. Create a business service from the WSDL you imported in step 4. For information on how to do this, see Business Services in the Using the AquaLogic Service Bus Console.
  6. Create a proxy service that routes to the business service created in the previous step. Typically this proxy service is created from the same WSDL as the business service. In the Web Services Security Configuration page, make sure that the Process WS-Security Header check box is not selected. For more information, see Proxy Services in Using the AquaLogic Service Bus Console.
  7. If routing is based on the operation being invoked when the request SOAP body is encrypted, you must specify a proxy service operation selection algorithm other than the SOAP body algorithm. Make sure the actions in the proxy service pipeline do not modify the WS-Security header or any parts of the SOAP envelope that are signed or encrypted. Changes to clear-text message parts covered by digital signatures almost always break the digital signature because the signature cannot be verified later.

How to Configure an Active Intermediary WS-Security Proxy Service

The following steps outline the basic steps for configuring a pass-through Web Service Security scenario. Some steps are optional.

  1. Import the WSDL for the WS-Security-enabled proxy service into the AquaLogic Service Bus WSDL repository. This WSDL must have the WS-Security policies attached to it. The policies may be inlined within the WSDL or the WSDL may have references to external policies.
  2. If the WSDL has external policy references, you must import these policies into the AquaLogic Service Bus WS-Policy repository and resolve the WSDL dependencies. For more information see "Resolving Unresolved WSDL References" in WSDLs in the Using the AquaLogic Service Bus Console.
  3. If any operation request policy requires encryption, you must make sure that the Confidentiality assertion is an abstract assertion (in other words, the certificate must not be embedded in the policy). Otherwise, you will get error messages while creating the proxy service from this WSDL. You must configure a proxy service provider and you must assign an encryption credential to the proxy service provider. For information on how to do this, see "Adding a Credential" in Security Configuration in the Using the AquaLogic Service Bus Console.
  4. If any operation response policy requires digital signatures, you must configure a proxy service provider and you must assign a digital signature credential to the proxy service provider. For information on how to do this, see "Adding a Credential" in Security Configuration in the Using the AquaLogic Service Bus Console.
  5. If any operation request policy requires digital signatures, you must register the accepted client signature verification certificates in the WebLogic Server Certificate Registry. The certificate registry in part of the WebLogic Certificate Lookup and Validation Framework. (See What is the Certificate Lookup And Validation Framework?.) The certificate in the message signature will be verified against the certificate registry. For information on how to do this, see "Configuring the Certificate Lookup and Validation Framework" in Configuring WebLogic Security Providers in Securing WebLogic Server.
  6. If any operation request policy requires authentication with a WS-Security Username/Password token with password digest, make sure to enable password digests. For more information, see "Domain-Wide Web Service Security Configuration," "Password Digests," and "Digest Authentication" in WebLogic Server Prerequisites.
  7. If any operation request policy requires authentication with a WS-Security X.509 certificate token, make sure to enable the UseX509ForIdentity property of the WebserviceSecurityMBean named __SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__ in the WebLogic Server Administration Console. For more information, see "Domain-Wide Web Service Security Configuration," in the WebLogic Server Prerequisites.
  8. Create a proxy service from the WSDL imported in step 1. If you configured a proxy service provider, specify that service provider in the General Configuration page of the AquaLogic Service Bus Console. Select the Process WS-Security Header check box in the Web Services Security Configuration page. For more information, see Proxy Services in Using the AquaLogic Service Bus Console.
  9. If any operation request policy specifies the use of SAML tokens, you must configure a SAML asserting party for this proxy service. For more information, see Inbound Authentication with a SAML WS-Security Token.

Outbound Web Services Security

This section contains information on the following topics:

About Outbound Web Services Security

Outbound WS-Security refers to security between AquaLogic Service Bus proxy services and business services. It includes both the request and response between business applications and proxy services. Outbound WS-Security applies only to SOAP-HTTP or SOAP-JMS business services. You specify the details for outbound message-level security using WS-Policy statements attached (inlined or referenced) from the WSDL of the business service.

Note: For SOAP-JMS, WS-Security is supported only for one-way messages. It is not supported for request/response messaging.

Warning: Encrypted back-end response messages: If the response policy of the business service specifies encryption, the proxy service will send its encryption certificate to the business service on the request. The business service will encrypt its response using the proxy service's public key. The proxy service encryption credential must not be the same as the business service encryption credential.

How to Configure Outbound Web Services Security

This section outlines the basic steps to configure an outbound Web Service Security scenario. Some steps are optional.

  1. Import a WSDL with WS-Policy statements attached (inlined or referenced) from the business service. If the security policies are referenced, they must be resolved. For information about resolving WSDL references, see "Resolving Unresolved WSDL References" in WSDLs in the Using the AquaLogic Service Bus Console.
  2. Define the business service in AquaLogic Service Bus using the WSDL as a template. If the WS-Policy of the business service requires UsernameToken authentication, you must specify a service account and assign a username and password to the service account. Proxy services that route to this business service will get the username and password for WS-Security Username Token authentication from the service account.
  3. If the business service request operation policy specifies a digital signature, you must configure a proxy service provider and assign a digital signature credential to the proxy service provider.
  4. If the business service response operation policy specifies encryption (that is, the business service encrypts the response with the proxy's encryption public key), you must configure a proxy service provider and assign an encryption credential to the proxy service provider.
  5. If the business service request operation policy specifies an Identity assertion and X.509 token is one of the supported tokens, you may have to configure a proxy service provider and assign a WS-Security X.509 Token credential to that proxy service provider. Whether this is required or optional depends on the identity policy. If X.509 token is the only supported token type, the X.509 credential is required. If the policy accepts other token types besides X.509 tokens, at least one of the requirements must be met by the proxy configuration.
  6. If any operation request policy requires authentication with a WS-Security Username/Password token with password digest, make sure to enable password digests. For more information, see "Domain-Wide Web Service Security Configuration," "Password Digests," and "Digest Authentication" in WebLogic Server Prerequisites.
  7. In the proxy service, configure the route node and operations on the business service.
  8. If the WS-Policy specifies using SAML assertions, you must also configure a WebLogic SAML Credential Mapping Provider V2 asserting party. For more information, see SAML Credential Mapping.

Note: When the WS-Policy of a business service requires messages to be encrypted, you must make sure that the policy of the business service with the encryption certificate embedded is inlined in the WSDL. Additionally, you must refer to this WSDL when defining the business service in the AquaLogic Service Bus Console. If the business service is a WebLogic Server 9.0 or 9.1 Web service or an AquaLogic Service Bus proxy service, you can get its WSDL by pointing a browser to <service-url>?WSDL. WebLogic Server will automatically inline the Web service policies in the WSDL and, if any policy specifies an encrypted request, the encryption certificate will be automatically embedded in the WSDL. Listing 3-1 shows an example WSDL with an inlined policy inlined and an embedded encryption certificate. Pay special attention the KeyInfo element inside the policy and the SecurityTokenReference. The value of the BinarySecurityToken element is the base-64 encoded encryption certificate (the value is truncated in the sample). If your certificate is in PEM format, the content of the PEM file (without the PEM prefix and suffix) is the base-64 encoded representation of the certificate. If your encryption certificate is stored in a JDK keystore, you can easily export it to a PEM file.

Listing 3-1 Example of WSDL with Policy Inlined and Embedded Encryption Certificate 

<definitions name="WssServiceDefinitions"
  targetNamespace="http://com.bea.alsb/tests/wss"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  ...
  >

  <wsp:UsingPolicy xmlns:n1="http://schemas.xmlsoap.org/wsdl/" n1:Required="true"/>

  <wsp:Policy wsu:Id="Encrypt.xml">
    <wssp:Confidentiality xmlns:wssp="http://www.bea.com/wls90/security/policy">
      <wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
      <wssp:Target>
        <wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
        <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>
      </wssp:Target>
      <wssp:KeyInfo>
        <wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
        <wssp:SecurityTokenReference>
          <wssp:Embedded>
            <wsse:BinarySecurityToken
                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
MIICfjCCAeegAwIBAgIQV/PDyj3...
            </wsse:BinarySecurityToken>
          </wssp:Embedded>
        </wssp:SecurityTokenReference>
      </wssp:KeyInfo>
    </wssp:Confidentiality>
  </wsp:Policy>

  <binding name="WssServiceSoapBinding" type="tns:WssService">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="getPurchaseOrder">
      <soap:operation soapAction="" style="document"/>
      <input>
        <soap:body parts="parameters" use="literal"/>
        <wsp:Policy>
          <wsp:PolicyReference URI="#Encrypt.xml"/>
        </wsp:Policy>
      </input>
      <output>
          <soap:body parts="parameters" use="literal"/>
        </output>
      </operation>
    </binding>

    ...

</definitions>

Disabling Outbound WS-Security in the Pipeline

The doOutBoundWSS property of the security element in the message context controls outbound WS-Security. If doOutboundWss is true, the proxy service applies WS-Security, that is, it signs and/or encrypts and/or add security tokens, to the outbound message according to the WS-Policy for the target service. If doOutboundWss is false, the proxy service does not apply WS-Security to the outbound message.

In a WS-Security pass-through scenario, the proxy service receives a request that already has WS-Security applied by the client, but the proxy does not process the WS-Security payload. The proxy service simply routes this request to the back-end service. This is also called a passive intermediary scenario. When the proxy service is a passive intermediary, an incoming secured message remains signed/encrypted in the AquaLogic Service Bus message flow and must therefore not be re-signed or re-encrypted on outbound dispatch.

During routing or publishing, the route node automatically initializes this property when a routing destination is set. The default value for doOutboundWss depends on the WS-Security configuration of both proxy and target services as follows:

You can modify the value of the doOutboundWss element in a routing (or publish) outbound request action.

 

Web Service Policy

This section contains information on the following topics:

About Web Service Policy

Web Services Policy (WS-Policy) is an extensible XML-based framework that extends the configuration of a Web service with domain specific assertions and specifies the requirements, expectations, and capabilities of Web services. In AquaLogic Service Bus, WS-Policy is used for configuration of message-level security in business and proxy services using security policy statements. For more information, see Configuring Security in Programming Web Services for WebLogic Server.

Note: The policy assertions used in WS-Policy to configure message-level security in AquaLogic Service Bus are based on the assertions described in the December 18, 2002 version of the Web Services Security Policy Language (WS-SecurityPolicy) specification. This means that although the exact syntax and usage of the assertions in AquaLogic Service Bus is different from the specification, they are similar in meaning to those described in the specification. Note that the assertions in this release of AquaLogic Service Bus are not based on the latest update of the specification (13 July 2005). The policy assertions used in AquaLogic Service Bus are fully compatible with policy assertions used in WebLogic Server 9.0 and 9.1 Web services.

WS-Policy statements ensure message integrity, confidentiality, and message origin authentication by specifying signing, encryption, application of security algorithms, and authentication mechanisms. A WS-Policy statement may include both security and reliable messaging assertions. At this time, AquaLogic Service Bus supports only security assertions, not reliable messaging assertions.

WS-Policy statements are XML documents, which may be inlined or referenced from WSDLs. A WSDL may import other WSDLs containing policy attachments, either inlined or referenced. You can associate one or more WS-Policy statements to different WSDL constructs as described later in this chapter.

In AquaLogic Service Bus, WS-Policies are required to have a wsu:Id attribute from the following namespace:

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd

The value of this attribute must be unique across all WS-Policy statements in the AquaLogic Service Bus repository. Note that this attribute is optional in the WS-Policy schema.

Listing 3-2 shows a WS-Policy with a security policy assertion that specifies encryption of the SOAP body.

Listing 3-2 Sample WS-Policy

<wsp:Policy
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:wssp="http://www.bea.com/wls90/security/policy"
   xmlns:wsu=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
   wsu:Id="encryptWithX509Token">

   <wssp:Confidentiality>
      <wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
      <wssp:Target>
         <wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
         <wssp:MessageParts>wsp:GetBody(.)</wssp:MessageParts>
      </wssp:Target>
      <wssp:KeyInfo>
         <wssp:SecurityToken TokenType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
      </wssp:KeyInfo>
   </wssp:Confidentiality>
</wsp:Policy>

For information on using WS-Policy in the AquaLogic Service Bus Console, see WS-Policies, especially "Resolving Unresolved WSDL References," in Using the AquaLogic Service Bus Console.

Web Services Policy Attachment

WS-Policy Attachment, defines the mechanisms for assigning policies to Web services. WebLogic Server 9.0, and subsequently, AquaLogic Service Bus, implements WSDL policy attachment. Policies statements may be inlined in a WSDL document by adding a <wsp:Policy> element as a child of the <wsdl:definition> element. An XML fragment identifier is used to reference inlined policies.

Referenced WS-Policy statements are associated with a Web service by adding one or more of the following policy URI attributes or policy reference elements to WSDL elements (which type depends on what the WSDL schema allows):

Using PolicyURIs or PolicyReference, you can reference one or more policies. The references may be local to the WSDL document (fragment URIs) or external.

WS-Policy Attachment also defines a <wsp:UsingPolicy/> element that must appear as a child to the <wsdl:definitions> element whenever a WSDL has policy attachments. To ensure that proxy and business services are capable of processing the policy attachments, this element can be marked as a mandatory extension (wsdl:required="true") in the WSDL.

Warning: If the UsingPolicy tag is missing from the WSDL, AquaLogic Service Bus ignores any WS-Policy present in the WSDL.

Listing 3-3 shows a WSDL with two inlined policies. One inlined policy, policy1, is referenced from the input part of operation doFoo on portType Sample using the policyURIs syntax with a fragment identifier. The other inlined policy, policy2, is referenced from operation doFoo in binding SampleBinding using the nested PolicyReference syntax.

Listing 3-3 WSDL with Policy References to Inline Policy

<definitions
   ...
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <wsp:UsingPolicy
      wsdl:Required="true"
      xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"/>
<wsp:Policy wsu:Id="policy1">...</wsp:Policy>
<wsp:Policy wsu:Id="policy2">...</wsp:Policy>
...
   <portType name="Sample">
      <operation name="doFoo" parameterOrder="data">
         <input message="tns:foo" wsp:PolicyURIs="#policy1"/>
         <output message="tns:fooResponse"/>
      </operation>
   </portType>
   <binding name="SampleBinding" type="tns:Sample">
      <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="doFoo">
         <wsp:Policy>
            <wsp:PolicyReference URI="#policy2"/>
         </wsp:Policy>
         <soap:operation
            soapAction="http://com.bea.samples/sample/doFoo" style="document"/>
         <input>
            <soap:body namespace="http://com.bea.samples/sample" use="literal"/>
         </input>
         <output>
            <soap:body namespace="http://com.bea.samples/sample" use="literal"/>
         </output>
      </operation>
   </binding>
   ...
</definitions>

Effective Policy

You can associate WS-Policies statements with the different policy subjects. A policy subject is an entity, such as service, endpoint, operation, or message, with which a policy can be associated. A policy scope is the collection of policy subjects to which a policy applies. For example, the policy scope implied by a policy attached to wsd:binding/wsdl:operation/wsdl:input is the input message, the operation, the endpoint, and the service.

The effective policy for a given policy subject is the merge of all policies whose scopes contain that policy subject. In other words, a policy scope is the collection of policy subjects to which a policy applies. For example, the effective policy of the input message of a binding operation is the merge of the following:

Note: When a proxy service is defined from a binding, any WS-Policy attached to the service or port is ignored.

The AquaLogic Service Bus Console displays the effective policy (read only) when configuring a business or proxy service with WS-Policy statements, as shown in the following figure.

Figure 3-4 Effective Policy

Effective Policy


 

Out-of-the-Box WS-Policy Statements

WebLogic Server includes three out-of-the-box WS-Policy statements. Most of the time a combination of one or more of these policies will address your requirements. However, you can write your own WS-Policies, import them to AquaLogic Service Bus, and refer to them from the WSDL.

To use the out-of-the-box policies, reference them from any WSDL using URIs, such as policyURIs="policy:Auth.xml". The following policies are included with WebLogic Server.

The out-of-the-box policies are located in the BEA_HOME/weblogic90/server/lib/weblogic.jar, where BEA_HOME is the directory in which your BEA products are installed. For more information on these policies, see "Use of WS-Policy Files for Message-Level Security Configuration" in Configuring Security in Programming Web Services for WebLogic Server.

Listing 3-4 shows a WSDL with references to two of the out-of-the-box policies.

Listing 3-4 WSDL with Policy References to Out-Of-The-Box Policies

<definitions
   ...
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <wsp:UsingPolicy
      wsdl:Required="true"
      xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"/>
   ...
   <portType name="Sample">
      <operation name="doFoo" parameterOrder="data">
         <input message="tns:foo" wsp:PolicyURIs="#policy1"/>
         <output message="tns:fooResponse"/>
      </operation>
   </portType>
   <binding name="SampleBinding" type="tns:Sample">
      <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="doFoo">
         <wsp:Policy>
            <wsp:PolicyReference URI="policy:Sign"/>
            <wsp:PolicyReference URI="policy:Auth"/>
         </wsp:Policy>
         ...
      </operation>
      </binding>
   ...
</definitions>

 

SAML Support

AquaLogic Service Bus provides support for Security Assertion Markup Language (SAML), which defines a framework for exchanging information between online business partners. For an overview of SAML, see the OASIS technical overview at the following URL:

http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf

The complete SAML specification set of documents are available at the following URL:

http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip

This section contains the following topics:

Identity Propagation

AquaLogic Service Bus uses SAML as the enabling technology to support identity propagation. Identity propagation governs secure passage of the AquaLogic Service Bus client's identity to the business service routed to by the proxy service. The identity is propagated in a SAML token inside the WS-Security security header included in the SOAP message. The following figure provides a graphic representation of identity propagation.

Figure 3-5 Identity Propagation

Identity Propagation


 

Pass-Through Identity Propagation

A SAML token is included in the client request that authenticates the client to the back-end service. The message is routed through an AquaLogic Service Bus proxy service. However, WS-Security processing for the proxy service is disabled.

This type of identity propagation is based on the following assumptions:

SAML Credential Mapping

The client authenticates to AquaLogic Service Bus through one of the supported authentication mechanisms, and the proxy service propagates the client identity to the back-end service. AquaLogic Service Bus acts as the asserting party. The authentication mechanism can be the following:

On the outbound request, the proxy service generates a SAML assertion on behalf of the client by including a SAML token in the WS-Security header inside the message to the back-end service. The back-end service acts as a relying party and must have a trust relationship with AquaLogic Service Bus. While the back-end service processes the WS-Security header, it validates the SAML assertion. A security context is created for the identity in the SAML assertion and the Web service is invoked with this security context.

Note: The target URL is normally the absolute URL of the first address in the business service. However, in the case where the proxy service is doing dynamic routing, by specifying the URI element in $outbound, the target URL is the dynamic address specified in the message context. If the assertion is signed, you must configure the certificate. For more information, see Configuring a SAML Credential Mapping Provider in Securing WebLogic Server.

Note: If the client request includes a WS-Security security header, the proxy service must process this header on the inbound side of the message. This is due to the fact that WebLogic Server WS-Security run time does not support multiple WS-Security headers in one SOAP envelope, or the addition of security tokens to an existing security header.

This type of identity propagation makes the following assumptions:

Inbound Authentication with a SAML WS-Security Token

The client request authenticates the client to the proxy service via the WS-Security SAML token profile. The client request includes a SAML token in the WS-Security header and the proxy service asserts the client's identity while processing the security header in the request. This scenario is an active intermediary scenario. This is what distinguishes this scenario from Pass-Through Identity Propagation.

This type of identity propagation makes the following assumptions:

If your active intermediary proxy service has a WS-Policy that specifies SAML, use the WebLogic Server Administration Console to configure the SAML asserting party for the WebLogic SAML Identity Assertion Provider V2. The confirmation method from the WS-Policy must match the SAML profile in the SAML asserting party. For more information, see Configuring a SAML Identity Assertion Provider in Securing WebLogic Server. Note that the asserting party target URL is the relative URL of the proxy, not including the protocol and host information. For signed assertions, add the certificate to the Identity Asserter registry.

Troubleshooting SAML Web Services Security

Question: I am trying to propagate my inbound transport identity to a destination business service and keep receiving error, Unable to add security token for identity. What does this mean?

Answer: There are various causes for this error. Generally this means one of the following problems:

Question: I am trying to propagate my inbound transport identity to a destination business service using SAML holder-of-key and keep receiving error, Failure to add signature. What does this mean?

Answer: There are various causes for this error, but most likely is that the credentials are not configured for the business service's proxy service provider. When AquaLogic Service Bus generates an outbound holder-of-key assertion, it generally also generates a digital signature over the message contents, so that the recipient can verify not only that a message is received from a particular user, but that the message has not been tampered with. To generate the signature, the business service must have a proxy service provider with a digital signature credential associated with it. For more information on configuring credentials, see "Adding a Credential" in Security Configuration in Using the AquaLogic Service Bus Console.

Question: I am trying to configure an active intermediary proxy service that receives SAML identity tokens and keep receiving errors that look like: The SAML token is not valid. How do I fix this?

Answer: This is generally caused by a lack of a SAML Identity Asserter or SAML Identity Asserter asserting party configuration for the proxy. For a proxy service to receive SAML assertions in active intermediary mode, it must have a SAML Identity Asserter configured. For more details, see Configuring a SAML Identity Assertion Provider in Securing WebLogic Server.

 

Access Control

This section contains information on the following topics:

About Access Control

Access control determines who has access to the resources in AquaLogic Service Bus. AquaLogic Service Bus relies on WebLogic Server security realms to protect its resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and (access control) security policies. To access any resources belonging to a realm, a user must be assigned a security role and defined in that realm. When a user attempts to access a AquaLogic Service Bus resource, WebLogic Server authenticates and authorizes the user by checking the security role assigned to the user in the relevant security realm and relevant security policy.

Note: Only a WebLogic Server administrator can define security policies or edit security roles in the AquaLogic Service Bus Console.

AquaLogic Service Bus Console and MBean access are secured with built-in role-based access-control security policies. These security policies are not WS-Policy statements. Recall that in this release, MBean access control is not configurable. Message flow can also be controlled by configuring security policies on proxy services. For more information, see Configuring Proxy Service Access Control.

The AquaLogic Service Bus Console contains a Security Configuration module for viewing and configuring users, groups, and security roles. Additionally, the AquaLogic Service Bus Console allows you to view and configure credentials. You configure security policies in the WebLogic Server Administration Console.

Warning: Before making changes within the Security Configuration module in the AquaLogic Service Bus Console, you must activate your configuration. For information about how to activate a session, see Using the Change Center in the Using the AquaLogic Service Bus Console.

Users

Users are entities that can be authenticated in a security realm. A user can be a person, such as an application end-user, or a software entity, such as a client application, or other instances of WebLogic Server. As a result of authentication, a user is assigned an identity, or principal. Each user is given a unique identity within the security realm. Users may be placed into groups that are associated with security roles, or be directly associated with security roles.

Groups

To make users easier to manage, users can be grouped. Groups are logically ordered sets of users, usually having something in common. Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for multiple users at one time by placing the users in a group, assigning the group to a security role, and then associating the security role with a WebLogic resource via a security policy. All user and group names must be unique within a security realm.

AquaLogic Service Bus includes predefined groups, as described in Table 3-1.

Table 3-1 AquaLogic Service Bus Groups

Property

Description

IntegrationAdministrators

Has complete access to all AquaLogic Service Bus resources, except cannot create, edit, or delete users, groups, roles, credentials, or access control policies.

IntegrationDeployers

Has complete access to all AquaLogic Service Bus resources, except cannot create, edit, or delete users, groups, roles, credentials, or access control policies.

IntegrationMonitors

Has read access to all AquaLogic Service Bus resources.

IntegrationOperators

This group has the following privileges:

  • Has read access to all AquaLogic Service Bus resources

  • Has access to create, view, edit and delete alert rules

  • Has access to session management, including create, commit, discard and undo of sessions.

Administrators

Has complete access to all AquaLogic Service Bus objects and functions.

Deployers

Has read access to all objects. Can create, delete, edit, import or export resources, services, proxy service providers, or projects.

Monitors

Has read access to all objects. Can export any resource, service, proxy service provider, or project.

Operators

Has read and export access to all objects. Can configure alerts, enable or disable metric collection, and suspend or resume services.


 

Security Roles

As previously mentioned, AquaLogic Service Bus supports role-based authorization using the WebLogic Security Framework. Authorization involves granting an entity permissions and rights to perform certain actions on a resource. In role-based authorization, security policies define the roles that are authorized to access the resource.

The difference between groups and security roles is that a group is a static identity assigned by an administrator, while membership in a security role is dynamically calculated based on data such as username, group membership, or the time of day. Security roles can be granted to individual users or to groups.

AquaLogic Service Bus includes built-in roles that are associated with certain administrative and monitoring privileges, as described in Table 3-2.

Table 3-2 AquaLogic Service Bus Security Roles

Type

Name

Description

IA

Integration Administrator

Has complete access to all AquaLogic Service Bus resources, except cannot create, edit, or delete users, groups, roles, credentials, or access control policies.

ID

Integration Deployer

Has complete access to all AquaLogic Service Bus resources, except cannot create, edit, or delete users, groups, roles, credentials, or access control policies.

IM

Integration Monitor

Has read access to all AquaLogic Service Bus resources.

IO

Integration Operator

This group has the following privileges:

  • Has read access to all AquaLogic Service Bus resources

  • Has access to create, view, edit and delete alert rules

  • Has access to session management, including create, commit, discard and undo of sessions.


 

For information on how to configure users and groups, see Security Configuration in Using the AquaLogic Service Bus Console.

For more information about security roles, see Users, Groups, and Security Roles, in Securing WebLogic Resources.

Role-Based Access in AquaLogic Service Bus Console

Table 3-4 shows the matrix of the actions that can be carried out in the console modules by users in the various roles:

Table 3-3 AquaLogic Service Bus Roles and Types

Role

Type

Integration Administrator

IA

Integration Deployer

ID

Integration Monitor

IM

Integration Operator

IO


 

Note: Permission to perform an action is indicated by a check mark () in the Role Type columns in the table.

In the Security Configuration section of this table, there are no check marks for create, edit, and delete users, groups, and roles, or for create, edit, view, and delete credentials and access control policies. The reason for this is that only WLS Administrators have access to these functions. Note that the WLS Administrator role is different from the IntegrationAdministrator role.

Table 3-4 Role-Based Access in AquaLogic Service Bus Console

Console Module 

Actions

Role Types

IA

IO

IM

ID

Monitoring Dashboard






Services

View Statistics

Alerts

View Alerts

Message Reports

View Message Reports







Reporting






Message Reports

View Message Reports







Resource Browser






Services






Business Service Definition

Create Service




View Service


Edit Service




Delete Service



Proxy Service Definition

Create Proxy Service




View Proxy Service


Edit Proxy Service




Delete Proxy Service



Alert Rule

Create Alert Rule



View Alert Rule


Edit Alert Rule



Delete Alert Rule


Operational Configuration

View...


Create/Update/Delete


WS-Policies

Create WS-Policy




View WS-Policy


Edit WS-Policy




Delete WS-Policy



WSDLs

Create WSDLs




View WSDLs


Edit WSDLs




Delete WSDLs



XML Schemas

Create XML Schemas




View XML Schemas


Edit XML Schemas




Delete XML Schemas



XQuery Transformations

Create XQuery




View XQuery


Edit XQuery




Delete XQuery



XSLTs

Create XSLT




View XSLT


Edit XSLT




Delete XSLT



MFLs

Create MFL




View MFL


Edit MFL




Delete MFL



Proxy Service Providers

Create Proxy Service Provider




View Proxy Service Provider


Edit Proxy Service Provider




Delete Proxy Service Provider









Project Explorer






Projects

Create Project




View Project


Edit Project




Delete Project



Folders

Create Folder




View Folder


Edit Folder




Delete Folder









Security Configuration






Users

Create User






View User


Edit User






Delete User





Groups

Create Group






View Group


Edit Group






Delete Group





Roles

Create Role






View Role


Edit Role






Delete Role





Credentials

Create Credential






View Credential






Edit Credential






Delete Credential





Access Controls

Create Policy






View Policy






Edit Policy






Delete Policy











System Administration






Configuration Repository

Import Resources




Export Resources

Global Settings

View State


Edit State


Tracing Configuration

View Tracing


Edit Tracing


UDDI

UDDI Configuration




Import from UDDI




Publish to UDDI









Change Center






Session Management

Begin Session



View Session



Undo Task



Discard Session



Commit Session



 

Credentials

You can configure AquaLogic Service Bus with the credentials it needs to securely interact with clients and business services. AquaLogic Service Bus credentials are built on top of the WebLogic Security Framework. To set up credentials, you use the Credentials section of the Security Configuration module in the AquaLogic Service Bus Console. For information on using the console to configure credentials, see Security Configuration in the Using the AquaLogic Service Bus Console. AquaLogic Service Bus supports the following types of credentials:

This section includes information on the following topics:

Service Accounts

A service account is an alias resource for a username and password. AquaLogic Service Bus uses service accounts to provide authentication when connecting to a business service or server. For example, when configuring FTP transport-level security for a business service, you may need to provide a username and password to authenticate to the FTP server.

Service accounts are used when configuring transport protocols for business services. They are also used for outbound Web Services Security Username Token authentication. Before configuring your business services, you have to define a service account. You can use the same service account for multiple purposes. After you define a service account, you can specify the associated username and password to the service account using the Credentials section of the Security Configuration module in the AquaLogic Service Bus Console. For more information, see Configuring Credentials.

For information on how to create a service account, see Service Accounts in the Using the AquaLogic Service Bus Console.

Proxy Service Providers

Some security scenarios require the use of PKI key-pair credentials. A key-pair credential is a private key and certificate pair. The certificate includes the public key corresponding to the private key. Whenever a proxy service must have access to PKI key-pairs, a proxy service must be assigned to the proxy. You must configure a PKI credential mapper in your security realm before using proxy service providers. No PKI credential mapping provider is configured out-of-the-box in ALSB 2.1 domains. For more information, see "Configuring a PKI Credential Mapping Provider" in Configuring WebLogic Security Providers in Securing WebLogic Server.

Warning: After adding or deleting a security provider, such as a PKI credential mapper, you must reboot the server for the security changes to take effect.

The proxy service obtains PKI credentials from the proxy service provider when needed. For example, to open an HTTPS connection with client-certificate authentication, the proxy service retrieves the SSL client key-pair from the proxy service provider. Multiple proxy services can use the same proxy service provider. You can assign different PKI key-pair credentials to a proxy service provider for different purposes. Proxy service providers supply credentials for the following purposes:

Before configuring security for a proxy service, you first need to create a proxy service provider. This allows you to designate the proxy service provider while configuring the proxy service. After you activate the proxy service in the AquaLogic Service Bus Console, you can associate PKI credentials to the proxy service provider using the Credentials section of the Security Configuration module. For more information, see Configuring Credentials.

For more information on how to create a proxy service provider, see Proxy Service Providers in the Using the AquaLogic Service Bus Console. For information about credential mapping providers, see
Security Providers in Understanding WebLogic Security and WebLogic Server Prerequisites.

Configuring Credentials

Credentials are persisted in security providers and not in the repository governed by the AquaLogic Service Bus sessions. This means that credentials are independent of the session in which the associated service account or proxy service provider are created. Be sure to follow these guidelines:

For information on how to perform the steps described in this section, see Service Accounts, Proxy Service Providers, and Using the Change Center in the Using the AquaLogic Service Bus Console.

Configuring Proxy Service Access Control

You can configure transport-level access control for HTTP and HTTPS proxy services. You can also configure access control at the message-level for any WS-Security active intermediary proxy service. To configure access control, you must assign an access control policy to the proxy service, either at the transport-level or message-level (or both).

The default transport-level and message-level access control policy for all proxy services is to allow access to all requests. You must assign an access control policy to the proxy service to protect it.

Note: No support for access control to JMS, FTP, email or file proxy services exists. These protocols have protocol-independent mechanisms to protect the underlying resources.

An access control policy is an association between a WebLogic resource and one or more users, groups, or security roles. A security policy protects the WebLogic resource against unauthorized access. Access control policies are boolean expressions assigned to specific resources. When there is an attempt to access the resource, the expression is evaluated. The expression consists of one or more conditions joined by boolean operators, such as a role (operator) and access time (8am to 5pm). For more information about access control policies, see Security Fundamentals in Understanding WebLogic Security and Components of a Security Policy: Policy Conditions, Expressions, and Statements in Securing WebLogic Resources.

You configure transport-level and message-level access control policies in the AquaLogic Service Bus Console. Additionally, you can assign access control policies to WebLogic resources in theWebLogic Server Administration Console. For more information, see Security Policies in Securing WebLogic Resources and Manage Security Policies in the WebLogic Server Administration Console Online Help.

Access control policies are persisted in authorization providers and not in the repository governed by the AquaLogic Service Bus sessions. Subsequently, proxy service access-control policies are independent of the session in which the associated proxy service is created. If you make changes to your proxy services, be sure to follow these guidelines:

If you want to delete a proxy service:

  1. Create a session if you have not already done so.
  2. Delete any transport security policy assigned to the proxy URL.
  3. Delete any service security policies assigned to the proxy or its operations.
  4. Delete the proxy service.
  5. Activate the session.

If you want to move or rename a proxy service:

  1. Create a session if you have not already done so.
  2. Delete any service security policies assigned to the proxy service or its operations.
  3. Move or rename the proxy service.
  4. Active the session. The proxy service will now be moved or renamed.
  5. Locate the renamed or moved proxy service and re-assign any service security policies deleted in step 2.

If you want to change the proxy service URL:

  1. Create a session if you have not already done so.
  2. Delete any transport security policy assigned to the proxy service's URL.
  3. Edit the proxy service's URL.
  4. Active the session.
  5. Re-assign the transport security policy deleted in step 2.

If you want to rename a proxy service operation:

  1. Create a session if you have not already done so.
  2. Delete any service security policy assigned to the operation you are renaming.
  3. Change the operation name.
  4. Active the session.
  5. Re-assign the service security policy deleted in step 2 to the new operation.

 

Securing AquaLogic Service Bus for a Production Environment

To prepare an AquaLogic Service Bus installation for production, you must pay special attention to your security needs. The following list outlines some of the tasks you need to perform:

 

Skip navigation bar  Back to Top Previous Next