|
|
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 HTTP 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.
AquaLogic Service Bus also supports client-specified custom authentication tokens for inbound transport-level requests.
For information about configuring transport-level security for each supported protocol, see Configuring Transport-Level Security.
For information on configuring custom authentication transport- and message-level security, see Configuring Custom Authentication.
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 custom authentication token that is supported by an Identity Assertion provider that you configure.
For message-level security, AquaLogic Service Bus supports the Username Token, X.509 Token, any other type of custom authentication token that is supported by an Authentication or Identity Assertion provider that you configure, 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.
|
|
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 custom authentication tokens 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.
|
|
If a custom username/password token is used, as described in What Are Custom Authentication Tokens?, then the username and password in the custom token can be used for outbound HTTP BASIC or outbound WS-Security Username Token authentication if a pass-through service account is used.
|
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.
|
||
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. If you require clients to provide credentials at both levels, AquaLogic Service Bus uses the message-level credentials for identity propagation and credential mapping.
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 or a custom authentication token. If a client sends an X.509 certificate token or a custom 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.
The AquaLogic Service Bus roles have permission to modify only AquaLogic Service Bus resources; they do not have permission to modify WebLogic Server or other resources on WebLogic Server. When assigning administrative users to roles, assign at least one user to the WebLogic Server Admin role. The WebLogic Server security roles are described in Table 9-2.
For more information, see Configuring Administrative Security.
Access control determines who has access to the resources in AquaLogic Service Bus. An access control policy specifies conditions under which users, groups, or roles can access a proxy service. For example, you can create a policy that always allows users in the GoldCustomer role to access a proxy service and that allows users in the SilverCustomer role to access the proxy service only after 12pm on weeknights.
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.
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, as described in Administrative Security Roles and Privileges. When a user attempts to access an 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. |
For all proxy services, you can create a transport-level policy, which applies a security check when a client attempts to establish a connection with the proxy service. Only requests from users who are listed in the transport-level policy are allowed to proceed.
For proxy services that are WS-Security active intermediaries, or that implement message-level custom authentication, you can also create a message-level policy. This type of policy applies a security check when a client attempts to invoke one of the secured operations. Only users who are listed in the message-level policy are allowed to invoke the operation.
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.
| Note: | 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. |
You can configure transport-level access control for all proxy services. You can also configure access control at the message-level for any WS-Security active intermediary proxy service, or for any proxy service that implements message-level custom authentication,. 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.
You configure transport-level and message-level access control policies in the AquaLogic Service Bus Console, as described in Editing Transport-Level Access Policies and Editing Message-Level Access Policies respectively.
Access control policies are persisted in authorization providers and not in the repository governed by the AquaLogic Service Bus sessions. Consequently, proxy service access-control policies are independent of the session in which the associated proxy service is created.
| WARNING: | Before deleting, moving, renaming, cloning or deleting a proxy service (or deleting, renaming, or moving a project or folder), delete all associated Transport-level and Service-level access control security policies. |
| WARNING: | Failure to delete these policies will leave the policies in the Authorization provider database and potentially cause unexpected results and potential security vulnerabilities, such as leaving unprotected a service that was previously protected. |
| WARNING: | For example, when you create a new proxy service whose full-path (and possibly operations) matches the path in an orphan policy, the proxy is implicitly reconnected to the policy. |
| Note: | When you clone a service, access control policies are not cloned. |
If you want to delete a proxy service:
If you want to move or rename a proxy service:
If you want to rename a proxy service operation:
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 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 supports the WebLogic SAML Identity Assertion Provider V2 and WebLogic SAML Credential Mapping Provider V2.
AquaLogic Service Bus supports the WebLogic XACML Authorization provider and XACML Role Mapping provider, which use the OASIS standard eXtensible Access Control Markup Language (XACML). Support for the WebLogic Default Authorization provider and Default Role Mapping provider was deprecated in AquaLogic Service Bus 2.5. These providers are not supported anymore. 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 have not been tested and therefore have not been certified in AquaLogic Service Bus. 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.
For more information about the security providers, see “WebLogic Security Providers” in the WebLogic Security Service Architecture in Understanding WebLogic Security.
Check the provided WebLogic Server Authentication providers to see if one meets your needs. WebLogic Server includes a broad array of Authentication providers, including the following:
If one of the bundled Authentication providers meets your needs, see Configuring Authentication Providers for instructions on how to configure this Authentication provider in the WebLogic Server Administration Console.
If none of the Authentication providers included in WebLogic Server suits your needs, you (or a third-party) must first write a custom Authentication provider and then use the WebLogic Server Administration Console to add that provider to the security realm. To do this, follow these steps:
| Note: | Only a broad overview of the required tasks is included here. You will need to consult the WebLogic Server documentation to actually complete the tasks. |
See Authentication Providers in Developing Security Providers for WebLogic Server for additional information.
You can use AquaLogic Service Bus resources with custom Authorization providers, but those providers must understand the type and format of the AquaLogic Service Bus resources.
There are three possible resource objects for AquaLogic Service Bus that an Authorization provider must be able to detect and handle:
These resource objects are described in the sections that follow.
This section briefly describes the WebLogic Server Authorization provider SSPI. See Developing Security Providers for WebLogic Server for complete information.
You protect resources by binding access control policies to resources via the AquaLogic Service Bus console, third-party tools or scripts. The WebLogic Server Security Service Provider Interface (SSPI) requires containers, such as AquaLogic Service Bus, to implement the Resource SPI. These implementations represent concrete resources.
The Authorization provider database contains a map from resource to policy. When an attempt is made to access a resource, the container calls the runtime SSPI to get an access control decision. The container passes a resource instance indicating which resource is being accessed.
An Authorization provider has one method, getAccessDecision(). The getAccessDecision() method obtains the implementation of the AccessDecision SSPI. The AccessDecision SSPI itself has one method, isAccessAllowed(). isAccessAllowed has five parameters, one of which is the Resource object for which access is being requested.
isAccessAllowed determines if the requestor should be allowed to access the named resource. To do this, the Authorization provider must find the right access control policy to evaluate. The provider must first look for a policy bound to the resource passed in. The lookup can use either the
Resource.getId() or
Resource.toString() method as a lookup key. If no policy is found, the Authorization provider must then get the parent resource and look again. This process is repeated until a policy is found or the parent is null, in which case no policy is found. When no policy is found, isAccessAllowed must return false.
This algorithm allows you to create coarse-grained policies that protect all proxy services in a given project or folder, all resources in a project, or all AquaLogic Service Bus proxy services in an AquaLogic Service Bus domain. More specific, finer-grained policies take precedence over coarse-grained policies.
| Note: | The AquaLogic Service Bus console user interface does not provide pages for protecting proxy services at the folder, project or domain level. |
The ALSBProxyServiceResource object is used for transport-level and message-level access control to ALSB proxy services. The ALSBProxyServiceResource resource extends
weblogic.security.service.ResourceBase, which itself implements
weblogic.security.spi.Resource.
ALSBProxyServiceResource implements the following methods, as described in
weblogic.security.spi.Resource:
path, proxy, action, and operation. The properties are defined as follows:
path is the full-name of the proxy service. For example, path=project/folder1/folder2proxy is the name of the proxy service. For example, proxy=myProxyaction is one of two values, invoke or wss-invoke. For example, action=invoke
invoke is used for transport-level access control. wss-invoke is used for message-level access control; that is, access control on WS-Security active intermediaries or proxies with custom message-level authentication. The operation attribute is only allowed when action is wss-invoke.operation is the name of the operation to invoke, and is used only when action is wss-invoke. For example, operation=processPO. The operation attribute is only allowed when action is wss-invoke. ALSBProxyServiceResource has from 1 to 4 keys. The following table explains how the various combinations protect proxy services. The most specific policies take precedence.
wss-invoke. For example, operation=processPO.
ALSBProxyServiceResource object that represents the parent of the current ALSBProxyServiceResource resource. makeParent() uses the path of the proxy service to create the parent.
The following examples show various uses of the ALSBProxyServiceResource object.
type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=invoke
project/folder/myProxy:
type=<alsb-proxy-service>, path=project/folder, proxy=myProxy, action=wss-invoke, operation=processPO
type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke, operation=foo
type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy, action=wss-invoke
type=<alsb-proxy-service>, path=myProject/f1/f2, proxy=myProxy
type=<alsb-proxy-service>, path=myProject/f1/f2
type=<alsb-proxy-service>, path=myProject/f1
type=<alsb-proxy-service>, path=myProject
The ProjectResourceV2 is the root resource for all ALSBProxyServiceResource objects in a given project. ProjectResourceV2 extends ResourceBase.
Setting an access control policy on a ProjectResourceV2 provides a coarse-grained access control policy for all proxy services in the given project that do not have more specific policies.
ProjectResourceV2 has the following methods:
ProjectResourceV2 object. This method therefore returns the object name that was used to create the ProjectResourceV2 object, or null if ProjectResourceV2 does not exist.
The com.bea.wli.security.resource.ConsoleResource object is used for access control to the ALSB console. However, we do not recommend that you set access control policies for ConsoleResource objects via a custom Authorization provider. This is because these policies are subject to change in future AquaLogic Service Bus releases.
We instead recommended that even if you need to use a custom Authorization provider, you also continue to use the WebLogic Server XACML Authorization provider to maintain the policies for the ConsoleResource object. In this case of two Authorization providers, you must also configure an Adjudication provider.
|