|
|
AquaLogic Service Bus supports open industry standards for ensuring the integrity and privacy of communications and to ensure that only authorized users can access resources in an AquaLogic Service Bus domain. It uses the underlying WebLogic security framework as building blocks for its security services. The WebLogic security framework divides the work of securing a domain into several components (providers), such as authentication, authorization, credential mapping, and auditing. You configure only those providers that you need for a given AquaLogic Service Bus domain.
The following sections introduce the AquaLogic Service Bus security model and its features:
Inbound security ensures that AquaLogic Service Bus proxy services handle only the requests that come from authorized clients. (By default, any anonymous or authenticated user can connect to a proxy service.) It can also ensure that no unauthorized user has viewed or modified the data as it was sent from the client.
Proxy services can have two types of clients: service consumers and other proxy services. Figure 2-1 illustrates that communication between proxy services and their clients is secured by inbound security, while communication between proxy services and business services is secured by outbound security.
You set up inbound security when you create proxy services and you can modify it as your needs change. For outward-facing proxy services (which receive requests from service consumers), consider setting up strict security requirements such as two-way SSL over HTTPS. For proxy services that are guaranteed to receive requests only from other AquaLogic Service Bus proxy services, you can use less secure protocols.
If a proxy service uses public key infrastructure (PKI) technology for digital signatures, encryption, or SSL authentication, create a proxy service provider to provide private keys paired with certificates. For more information, see Proxy Service Providers in Using the AquaLogic Service Bus Console.
For each proxy service, you can configure the following inbound security checks:
For example, for proxy services that communicate over the HTTPS protocol, you can require that all clients authenticate against a database of users that you create in the Security Configuration module of the AquaLogic Service Bus Console. You then create an access control policy that specifies conditions under which authenticated users are authorized to access the proxy service.
For information about configuring transport-level security for each supported protocol, see Configuring Transport-Level Security.
Part of the configuration for message-level security is embedded in the WSDL document and WS-Policy document that are associated with the Web service. These documents specify whether SOAP messages must be digitally signed and encrypted and which Web service operations can be invoked only by authorized users.
If a proxy service or business service uses a WS-Policy statement to secure access to one or more of its operations, and if you have configured the service as an active intermediary (as opposed to a pass-through service), you use the AquaLogic Service Bus Console to create a message-level access control policy. The policy specifies conditions under which users, groups, or security roles are authorized to invoke the protected operations.
For more information about configuring message-level security, see Configuring Message-Level Security for Web Services.
Outbound security secures communication between a proxy service and a business service. Most of the tasks that you complete for outbound security are for configuring proxy services to comply with the transport-level or message-level security requirements that business services specify.
For example, if a business service requires user name and password tokens, you create a service account, which either directly contains the user name and password, passes along the user name and password that was contained in the inbound request, or provides a user name and password that depend on the user name that was contained in the inbound request. For more information, see Service Accounts in Using the AquaLogic Service Bus Console.
If a business service requires the use of PKI technology for digital signatures, or SSL authentication, you create a proxy service provider, which provides private keys paired with certificates. For more information, see Proxy Service Providers in Using the AquaLogic Service Bus Console.
A key group of decisions that you must make when designing security for AquaLogic Service Bus is how to handle (propagate) the identities that clients provide. You can configure AquaLogic Service Bus to do any of the following:
Table 2-1 describes the decisions that affect how AquaLogic Service Bus propagates client identities to business services.
For transport-level security, AquaLogic Service Bus adapts to your existing security requirements. Clients of AquaLogic Service Bus can supply user name and password tokens, SSL certificates, or any other type of token that is supported by an authentication provider that you configure.
For message-level security, AquaLogic Service Bus supports the Username Token, X.509 Token, and SAML Token profiles (see Supported Standards and Security Providers).
If you are establishing security requirements for a new business service that uses Web Services Security, BEA recommends that you require clients to provide SAML tokens. SAML is the emerging standard for propagating user identities within Web services. See Using SAML for Authentication.
|
|
BEA recommends that you require clients to authenticate with AquaLogic Service Bus and that you modify the default access-control policies to allow (authorize) only specific, authenticated users access to your proxy services.
To authenticate and authorize clients who supply X.509 certificates, SAML tokens, or other types of credentials other than user names and passwords, you must configure an identity assertion provider that maps the client's credential to an AquaLogic Service Bus user. AquaLogic Service Bus will use this user name to establish a security context for the client.
|
|
Table 2-2 describes all combinations of the requirements that you can impose for inbound and outbound transport-level security.
|
||
|
||
|
||
Create a pass-through service account and attach the account to the business service. See "
Service Accounts" in Using the AquaLogic Service Bus Console.
|
||
Create a pass-through service account and attach the account to the business service. See "
Service Accounts" in Using the AquaLogic Service Bus Console.
|
||
Create a user-mapping service account and attach the account to the business service. See "
Service Accounts" in Using the AquaLogic Service Bus Console.
|
Table 2-3 describes all combinations of the requirements that you can impose for inbound and outbound message-level security. In some cases, the inbound requirement for transport-level security affects the requirements that you can impose for outbound message-level security.
|
||
|
||
|
||
|
||
|
||
Create an active intermediary proxy service with a WS-Policy statement that requires passwords (not password digests). See Creating an Active Intermediary Proxy Service: Main Steps.
|
||
|
||
|
||
|
||
|
For inbound Tuxedo requests, you can configure any of the following security requirements:
For information about using Tuxedo with AquaLogic Service Bus, see Interoperability Solution for Tuxedo.
Figure 2-2 illustrates how user identities flow through AquaLogic Service Bus when you configure AquaLogic Service Bus as follows:
You can require Web services clients to provide credentials at the transport level, the message level, or both levels. If you require clients to provide credentials at both levels, AquaLogic Service Bus uses the message-level credentials for inbound authentication and authorization.
The illustration begins with the inbound request and ends with the outbound request:
Clients can send other types of tokens for authentication, such as an X.509 certificate. If a client sends a certificate token, you must configure an identity assertion provider to map the identity in the token to an AquaLogic Service Bus security context.
If the user exists, the proxy service asks the domain's authorization provider to evaluate the access control policy that you have configured for the proxy service.
The business service asks its service account for the credentials. Depending on how the service account is configured, it does one of the following:
To secure access to administrative functions, such as creating proxy services or business services, AquaLogic Service Bus provides four security roles with pre-defined access privileges:
A security role is an identity that can be dynamically conferred upon a user or group at runtime. You cannot change the access privileges for these administrative security roles, but you can change the conditions under which a user or group is in one of the roles.
When assigning administrative users to roles, assign at least one user to the WebLogic Server Admin role, which has complete access to all WebLogic Server and AquaLogic Service Bus resources.
For more information, see Configuring Administrative Security.
Many of the initial configuration tasks for AquaLogic Service Bus security require you to work in the WebLogic Server Administration Console to configure the WebLogic security framework. After these initial tasks, you can complete most security tasks from the AquaLogic Service Bus Console.
To configure the WebLogic security framework for AquaLogic Service Bus:
In AquaLogic Service Bus, all HTTPS communication must use the default WebLogic Server (SSL) secure network channel. This is the only SSL network channel that AquaLogic Service Bus supports.
Table 2-4 describes the authentication providers that are commonly configured for AquaLogic Service Bus. For a description of all authentication providers that you can configure, see Security Providers in Securing WebLogic Server.
The WebLogic Authentication provider and use the AquaLogic Service Bus Console to enter the user names and passwords of the clients that you want to allow access.
See "Adding a User" under
Security Configuration in Using the AquaLogic Service Bus Console.
|
|
|
|
If any of your proxy services or business services are Web services that use abstract WS-Policy statements, you must also configure the following:
|
|
See Configure Certification Path Providers in WebLogic Server Administration Console Online Help.
UsePasswordDigest property to true.
The AquaLogic Service Bus Web Service security configurations are named:__SERVICE_BUS_INBOUND_WEB_SERVICE_SECURITY_MBEAN__ and __SERVICE_BUS_OUTBOUND_WEB_SERVICE_SECURITY_MBEAN__
For information on setting the values in Web Service security configurations, see Use a Password Digest in SOAP Messages in the WebLogic Server Administration Console Online Help.
wsse:PasswordDigest as one of the active token types.A PKI credential mapping provider maps AquaLogic Service Bus proxy service providers to key-pairs that can be used for digital signatures and encryption (for Web Services Security) and for outbound SSL authentication. For more information, see "Configuring a PKI Credential Mapping Provider" in Configuring WebLogic Security Providers in Securing WebLogic Server.
You store the key-pairs and trusted Certification Authority (CA) certificates that the PKI credential mapping provider uses in a keystore. You can store the PKI credential mappings in the identity keystore that WebLogic Server uses (which is typically the same keystore that you use to store key-pairs for SSL communication) or in a separate keystore. Configure each WebLogic Server instance to have access to its own copy of each keystore. All entries referred to by the PKI credential mapper must exist in all keystores (same entry with the same alias). For information about configuring keystores in WebLogic Server, see "Identity and Trust" in Security Fundamentals in Understanding WebLogic Security.
| Note: | When you create an AquaLogic Service Bus domain, by default the domain contains a user name/password credential mapping provider, which you can use if you need credential mapping for user names and passwords. In addition to this user name/password credential mapping provider, you can add one PKI credential mapping provider. An AquaLogic Service Bus domain can contain at most one user name/password credential mapping provider, one PKI credential mapping provider, and multiple SAML credential mapping providers. |
| Note: | -Dcom.bea.wli.sb.security.AuditWebServiceSecurityErrors=true |
AquaLogic Service Bus supports the auditing of security events but it does not support configuration auditing, which emits log messages and generates audit events when a user changes the configuration of any resource within a domain or invokes management operations on any resource within a domain. See Configuration Auditing Securing WebLogic Server.
This release of AquaLogic Service Bus supports the following standards.
For information about the standards that WebLogic Server supports, see "Standards Support" under What's New in WebLogic Server in WebLogic Server Release Notes.
AquaLogic Service Bus supports the security providers that are 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.5 supports the WebLogic SAML Identity Assertion Provider V2 and WebLogic SAML Credential Mapping Provider V2.
As of release 2.5, AquaLogic Service Bus deprecates support for the WebLogic Default Authorization provider and Default Role Mapping provider, which use a proprietary policy language. Instead, BEA recommends that you use the WebLogic XACML Authorization provider and XACML Role Mapping provider, which use the OASIS standard eXtensible Access Control Markup Language (XACML). If you are upgrading from a previous release of AquaLogic Service Bus in which you used the WebLogic Default Authorization provider and Default Role Mapping provider, use the WebLogic Server Administration Console to import authorization and role-mapping data into the XACML providers. See Upgrading AquaLogic Service Bus Environments in AquaLogic Service Bus Upgrade Guide.
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.5. 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.5.
For more information about the security providers, see "WebLogic Security Providers" in the WebLogic Security Service Architecture in Understanding WebLogic Security.
|