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 service key provider to provide private keys paired with certificates. For more information, see Service Key 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 can be 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.
In ALSB 3.0 there is an alternative way to bind WS-Policy to services. The WS-Policy console page allows you to bind policies to the service as a whole, to individual operations in the service, or to the request message or response message of individual operations.
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 service key provider, which provides private keys paired with certificates. For more information, see Service Key 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 (8 am to 5 pm). 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 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.
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. However, as of ALSB 3.0 there is now a reference to them in the ALSB repository.
Access control policies are managed within an ALSB design session and not outside the session, as was the case in releases prior to 3.0. Because the changes are made within a session, you can commit or discard the changes as with other resources.
Although ACLs can be managed from the ALSB console, you can change policies outside ALSB. However, changing policies outside of ALSB can make the reference in ALSB out-of-date and invalid.
Therefore, for consistent management, either completely manage ACLs outside of ALSB sessions (using the authorization provider MBeans or third-party authorization provider tools) or completely manage them from within ALSB sessions. Any combination of the two approaches can result in an inconsistent view of policies.
ALSB manages access control policy only for proxy services. You must manage access control policy management for other server resources, such as JMS queues, JNDI entries, EJBs, applications, WebLogic Server instances, data sources, and so forth from the WebLogic Server console.
Note: | When you clone a service, ACLs are also cloned in the session. If the user commits the session, ACLs on the service will be committed to the authorization provider. Therefore, when you clone a service you need to decide if you want the clone to have the same ACLs as the original. If you do not want this, then make sure to edit the ACLs of the clone. |
Note: | In ALSB releases prior to 3.0, when you cloned a service, access control policies were not cloned. |
Deleting a proxy service deletes all of the ACLs referenced by the proxy from the repository controlled by ALSB, as well as from the appropriate authorization provider.
You can also delete the access control policies assigned to a service without deleting the service. To do this:
Renaming a proxy service correctly moves all of the policies. You need only rename or move the service in an ALSB session.
When an operation is renamed, the existing operation is transparently deleted and a new operation is created.
However, when an operation name is changed by changing the WSDL, ALSB considers any policies for the old operation to be invalid, removes the reference from the ALSB repository, and deletes the policies from the appropriate authorization provider.
In this case ALSB does not know that the old operation is renamed to the new operation, and it does not add anything new for the new operation. That is, ALSB considers that there are no policies for this new operation.
You need to add the appropriate policy to the new operation manually. You can do this in the same session as the rename of operation, after the rename is done.
As of this release of ALSB, you can export or import ALSB resources without losing any associated security configuration data.
ALSB includes import check boxes that you can use to determine whether to preserve or overwrite the existing security configuration.
For example, assume that you want to configure your credentials in a staging area, export a project that contains these credentials, and then import the project in your production environment. When you export the project, the security configuration is included in the ALSB configuration jar. When you then import the project on your target system, how the resources are treated depends on whether they already exist on the target system:
The three import check boxes allow you to decide which, if any, aspects of the security configuration must be preserved during import:
Note: | These check boxes work the same way for ALSB configuration files created for a project-level export and for an individual resource export. |
These check boxes are described in more detail in the sections that follow.
When the Preserve Security and Policy Configuration check box is set (the default), the following configuration parameters are preserved:
Note: | If the service is using WSDL-based policies, the policies are not preserved by this check box. This is because the WSDL might itself be updated and the service must reflect the WSDL. |
The control also preserves the type of the WS-Policy Binding, either Custom (through the Policies tab) or WSDL-based.
When the Preserve Credentials check box is set (the default), the following credentials are preserved during the import process:
A PKI credential mapping provider maps AquaLogic Service Bus service key 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 Securing WebLogic Server.
When the Preserve Access Control Policies check box is set (the default), all access control policies for the imported proxy services are preserved during the import process.
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:
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 service key 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 WebLogic Server’s identity keystore 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.
Context Properties provides a way (the ContextHandler interface) to pass additional information to the WebLogic Security Framework so that a security provider can obtain contextual information beyond what is provided by the arguments to a particular provider method. A ContextHandler is a high-performing WebLogic class that obtains additional context and container-specific information.
ALSB makes use of the ContextHandler interface and passes several context properties to the security framework for transport-level and message-level authentication, transport-level and message-level access control, and credential mapping.
This section describes the situations in which ALSB-specific context properties are used.
When an HTTP proxy service is configured for authentication, the HTTP transport provider passes an ALSB implementation of the WebLogic Server ContextHandler. There is no user configuration required for this feature.
The ContextHandler properties in Table 2-5 are passed at runtime, under the following conditions:
The ContextHandler properties shown in Table 2-6 are passed at runtime, under the following conditions:
In addition to the properties in Table 2-6, other transport-specific properties may be present. For each transport request-header (see the transport SDK), a property with the name
com.bea.contextelement.alsb.router.inbound.request.headers.<provider-id>
.<header-name>
is present, where provider-id
is the transport provider id, and header-name
is one of the request-headers declared in the provider's schema file.
The type and semantics of these properties is transport-specific. For HTTP proxy services, the properties in Table 2-7 are also available.
Both custom username/password authentication and custom token authentication allow users (who are in the IntegrationAdmin or IntegrationDeployer roles) to pass additional context information to the security provider in the Context Properties field on the Security tab.
You can configure additional context properties by entering the Property Name as a literal string, and the Value Selector as a valid XPath expression. (XPath expressions can also be literal strings.)
The XPath expression is evaluated at runtime against the same message part that is used for the custom token or custom username/password. That is, the Value Selector XPath expressions are evaluated against the header for SOAP-based proxy services, and against the body for non-SOAP-based proxy services.
A ContextHandler is essentially a name/value list and, as such, it requires that a security provider know what names to look for. Therefore, for both transport- and message-level custom authentication, the XPath expressions are evaluated only if an Authentication provider or Identity Assertion provider asks for the value of one of these properties.
This means that your configured Authentication or Identity Assertion provider must explicitly know which property names to request via the ContextHandler.getValue(propertyName)
method. The only way to satisfy this requirement is for you, or a third party, to write a custom Authentication or Identity Assertion provider.
For example, Listing 2-1 shows how to get the HttpServletRequest property from a provider that you write.
:
Object requestValue = handler.getValue("com.bea.contextelement.alsb.transport.http.http-request
");
if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
return;
HttpServletRequest request = (HttpServletRequest) requestValue;
log.println(" " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
log.println(" " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
log.println(" " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
return;
If the security provider does not need the value of the user-defined property, then the XPath expression is not evaluated.
This release of AquaLogic Service Bus can use the WebLogic Server administrative channel.
As described in Understanding Network Channels, a WebLogic Server network channel is a configurable resource that defines the attributes of a network connection to WebLogic Server.
You can configure a particular type of network channel, called an administrative channel, to isolate “administration” and application (“business”) traffic in a WebLogic domain. The administrative channel is a secured channel that accepts only SSL connections.
In AquaLogic Service Bus, business traffic is comprised of all messages sent to and from AquaLogic Service Bus proxy services and business services. SSL business traffic must use the default WebLogic Server secure network channel.
Administration traffic is comprised of all communication with the WebLogic Server Administration Console, AquaLogic Service Bus Administration console, internal traffic within a cluster, and traffic between administration scripts and admin or managed servers.
When an administrative channel is enabled in a domain, all of the administration traffic in that domain must go through that channel. Otherwise, the administration traffic also uses the default WebLogic Server secure network channel.
The domain-wide administration port control is located on the Domain > Configuration > General page. The default administration port is 9002.
Be sure to activate the change.
The URL is https://hostname:9002/sbconsole
if you enabled the domain-wide administration port and accepted the default port number.
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:
See Improving the Performance of WebLogic and LDAP Authentication Providers for guidance on improving the performance of these authentication providers.
As described in Why Customize the Default Security Configuration, you may want to use an Authentication provider that accesses a database other than WebLogic Server's embedded LDAP server. For example, you might want to use a different authentication provider for the majority of user accounts, but continue to use the default authentication provider (embedded LDAP) for ALSB and Web Logic Server administrative user accounts.
Using the WebLogic Authentication provider for all WebLogic Server and ALSB administrative user accounts provides reliable access in the event of a network or database problem. BEA recommends that you use the default WebLogic Authentication provider for all WebLogic Server and ALSB administrative accounts for this reason.
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/folder2
proxy
is the name of the proxy service. For example, proxy=myProxy
action
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.