Skip navigation.

eDocs Home > BEA AquaLogic Service Bus 2.0 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.0. 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 the AquaLogic Service Bus Console Online Help.

This chapter includes the following topics:

 

AquaLogic Service Bus Security FAQ

What does AquaLogic Service Bus secure?

AquaLogic Service Bus is a messaging intermediary. As such, AquaLogic Service Bus utilizes the security features of WebLogic Server to ensure message confidentiality and integrity (message-level 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 security in WebLogic Server as described in WebLogic Server Prerequisites and Web Service Policy.

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 Provider, Identity Assertion Provider, Authorization Provider, and Credential Mapping Provider. However, the Security Assertion Markup Language (SAML) Identity Assertion provider is not supported in this release. It will be supported in a future release.

For more information, see "WebLogic Security Providers" in the WebLogic Security Service Architecture in Understanding WebLogic Security.

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 are not supported in this release of AquaLogic Service Bus. Additionally, AquaLogic Service Bus does not support third-party token handlers, such as Kerberos tokens, since they have not been tested.

Does AquaLogic Service Bus support identity propagation in a proxy?

The client identity is available to the AquaLogic Service Bus message flow in the message context. However, AquaLogic Service Bus does not propagate the client identity to the target service. This capability will be added in a future release. For more information about message identity, see Security for JMS, Email, FTP, and File Transport.

What kind of Web Service security policies and credentials does AquaLogic Service Bus support?

AquaLogic Service Bus supports integrity and confidentiality policies through the use of digital signatures and encryption. It also supports message origin authentication through username and password tokens, X.509 certificate chains, and trusted X.509 certificates. AquaLogic Service Bus is built on the WebLogic Security Framework. This framework implements the OASIS Web Service Security Standard, the Username Token Profile, and the X.509 Certificate Token Profile. Back-end services, such as clients and proxy services are configured with optional Web Service security policies, which are modeled after the Web Services Policy Framework (WS-Policy) specification developed by BEA, IBM, Microsoft, SAP, Sonic Software, and VeriSign. Because the WS-Policy specification has not been fully standardized, AquaLogic Service Bus supports a WebLogic Server-proprietary format. For more information, see Web Service Policy.

Is single sign-on supported in AquaLogic Service Bus?

Single sign-on is not relevant to securing messages. However, in a message intermediary, such as AquaLogic Service Bus, the related concept of identity propagation is relevant, but as previously mentioned, identity propagation is not supported in this release. For the AquaLogic Service Bus Console and WebLogic Server, single sign-on is supported. For more information, see "Single Sign-On" in Security Fundamentals in Understanding WebLogic Security.

What types of security should I configure?

AquaLogic Service Bus uses the WebLogic Security Framework to configure the following types of security:

Access Control—Access control security involves granting an entity permissions and rights to perform certain actions on a resource. AquaLogic Service Bus supports authorization using the default WebLogic Authorization Provider. In role-based authorization, security policies define the roles that are authorized to access the resource. The AquaLogic Service Bus Console and MBean access are also secured with built-in role-based access-control security policies. For more information see, Access Control Security.

Transport-Level Security—With transport-level security, you secure the connection over which messages are transported. HTTPS connections are secured with SSL. JMS connections can be optionally secured with T3S (T3 over SSL). SSL provides point-to-point security, it does not protect the message when intermediaries exist in the message path. FTP, email, and file transports can also be protected. For more information, see Transport-Level Security.

Message-Level Security—Message-level security includes the security benefits of SSL, but with additional flexibility and features. Message-level security can be end-to-end, which means that a SOAP message is secure even when the transmission involves one or more intermediaries. The SOAP message itself is digitally signed and encrypted over the connection. And finally, message-level security allows you to specify that only parts of the message are signed or encrypted. Note also that SSL only works for synchronous communication, whereas message-level security can be used with asynchronous transports such as JMS. Currently, AquaLogic Service Bus supports message-level security over HTTP, HTTPS, and JMS; other transports may be added in the future. For more information, see Message-Level Security.

Are security errors monitored?

Yes, for more information, see Service Monitoring Details.

Can I configure security for MBeans?

WebLogic Server enforces MBean access control. In this release of AquaLogic Service Bus, 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 AquaLogic Service Bus Console Online Help.

 

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.

Figure 3-2 WebLogic Server Administration Console

WebLogic Server Administration Console

The following lists the possible security properties that you may need to configure in WebLogic Server 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.

Securing the connection includes authenticating the identity of the users by various means. If any part of authentication fails, the overall authentication will fail, and the message will be rejected. Whether or not authentication succeeds or fails, WebLogic Server generates an audit event (if audit providers are configured in the security realm). Each audit provider can be configured to filter specific event types. For example, a filter may specify that the audit provider write only failed authentication events, not successful ones.

The following types of transport security are supported:

HTTPS Transport-Level Security

AquaLogic Service Bus relies on WebLogic Server for server-side SSL support, including session management, client certificate validation and authentication, trust management, and server SSL key and certificate configuration. Currently, AquaLogic Service Bus supports only the default WebLogic Server (SSL) secure network channel. AquaLogic Service Bus supports both inbound and outbound HTTPS proxy endpoints, as 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 AquaLogic Service Bus Console Online Help.

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 that requires BASIC authentication, a transport-authorization policy is not automatically associated with the inbound endpoint URI. 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 Access Control Security Policies.

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.

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 AquaLogic Service Bus Console Online Help.

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 is 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 AquaLogic Service Bus Console Online Help.

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 AquaLogic Service Bus Console Online Help.

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 AquaLogic Service Bus Console Online Help.

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 AquaLogic Service Bus Console Online Help.

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 AquaLogic Service Bus Console Online Help.

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 WS-Callout

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

 

Message-Level Security

This section includes information on the following topics:

About Message-Level Security

Message-level security specifies whether the SOAP messages between a client application and a Web service should be digitally signed or encrypted or both. It is also used to specify Username Token authentication and X.509 certificate authentication. Signing insures message integrity, that is, it ensures that the message wasn't tampered with. However, signing does not prevent the message from being read. Encryption prevents the message from being read by unauthorized persons.

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. Additionally, you can specify that only parts of the message be signed or encrypted. This ability is useful for routing messages in AquaLogic Service Bus. Message-level security provides confidentiality 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's WSDLs. These policies may be referenced XML documents from within the WSDL or included as part of the WSDL. 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. In the active intermediary scenario, the proxy service is configured with WS-Policy statements. In the pass-through scenario, the proxy service is configured with WS-Policy statements, but processing is disabled. In the active intermediary scenario, the WS-Policy statement is publicized to clients (from the WSDL) and the proxy service processes the header and enforces the policy. In the pass-through scenario, the WS-Policy statement is publicized to clients but not enforced by the AquaLogic Service Bus proxy; the client application enforces the policy.

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:

Configuring Inbound Web Services Security

You configure inbound message-level security while creating or editing an AquaLogic Service Bus proxy service. Use the following steps as a guideline. The particular steps you need to perform depend on whether you are configuring an active-intermediary or pass-through scenario.

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.

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

As with inbound Web service security, outbound WS-Security has both an active intermediary scenario and the pass-through scenario.

Proxy Service Request and Business Service Response

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

Configuring Outbound Web Services Security

You configure outbound message-level security while creating or editing a business service. Use the following steps as a guideline. The particular steps you need to perform depend on whether you are configuring an active-intermediary or pass-through scenario.

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. You must refer to this WSDL when defining the business service in the AquaLogic Service Bus Console. Otherwise, AquaLogic Service Bus will not be able to retrieve the public key to use for encrypting the messages to the business service.

 

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 proxy and business services using security policy statements. Because the specification has not been fully standardized, AquaLogic Service Bus supports a WebLogic Server-proprietary format. For more information, see Configuring Security in Programming Web Services for WebLogic Server.

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 security assertions, but 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-1 shows a WS-Policy with a security policy assertion that specifies encryption of the SOAP body.

Listing 3-1 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 the following in AquaLogic Service Bus Console Online Help:

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 only 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-2 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-2 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 proxy or business service with WS-Policy statements, as shown in the following figure.

Figure 3-5 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-3 shows a WSDL with references to two of the out-of-the-box policies.

Listing 3-3 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>

 

Access Control Security

This section contains information on the following topics:

About Access Control Security

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 Access Control Security Policies.

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 AquaLogic Service Bus Console Online Help.

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 the following predefined groups:

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 follows:

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

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

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 AquaLogic Service Bus Console Online Help. 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. 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 AquaLogic Service Bus Console Online Help.

Proxy Service Providers

To configure security for a proxy service, you must designate a proxy service provider. Proxy service providers provide credentials for inbound and outbound messages from a proxy service. You must configure a PKI credential mapper in your security realm when using a proxy service provider. 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 the needed PKI credentials from the proxy service provider. For example, to open an HTTPS connection with client-certificate authentication, the designated proxy service provider supplies the key-pair that the proxy service uses for SSL authentication. Multiple proxy services can use the same proxy service provider. You can assign different PKI credentials, such as private-key and certificate pairs, to a proxy service provider for different purposes. Proxy service providers supply the following types of security:

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 AquaLogic Service Bus Console Online Help. 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 AquaLogic Service Bus Console Online Help.

Access Control Security Policies

An (access control) security 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. Security 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 security 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 security policies in the WebLogic 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.

Security policies are persisted in security providers and not in the repository governed by the AquaLogic Service Bus sessions. Subsequently, security 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 or its operations.
  3. Move or rename the proxy.
  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 URL.
  3. Edit the proxy 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