JACC support in WAS

JACC support in WAS

WAS supports the Java Authorization Contract for Containers (JACC) specification, which enables third-party security providers to handle the Java EE authorization.
The JACC spec requires that both the containers in the application server and the provider satisfy some requirements. Specifically, the containers are required to propagate the security policy information to the provider during the application deployment and to call the provider for all authorization decisions. The providers are required to store the policy information in their repository during application deployment. The providers then use this information to make authorization decisions when called by the container.

JACC access decisions

When security is enabled and an enterprise bean or Web resource is accessed, the EJB container or Web container calls the security runtime to make an authorization decision on whether to permit access. When using an external provider, the access decision is delegated to that provider.
According to the Java Authorization Contract for Containers (JACC) specification, the appropriate permission object is created, the appropriate policy context handlers are registered, and the appropriate policy context identifier (contextID) is set. A call is made to the java.security.Policy object method that is implemented by the provider to make the access decision.
The following sections describe how the provider is called for both the enterprise bean and the Web resources.
Access decisions for enterprise beans When security is enabled, and an EJB method is accessed, the EJB container delegates the authorization check to the security runtime. If JACC is enabled, the security runtime uses the following process to perform the authorization check:

Creates the EJBMethodPermission object using the bean name, method name, interface name, and the method signature.
Creates the context ID and sets it on the thread by using the PolicyContext.setContextID(contextID) method.
Registers the required policy context handlers, including the Subject policy context handler.
Creates the ProtectionDomain object with principal in the Subject. If no principal exists, null is passed for the principal name.
The access decision is delegated to the JACC provider by calling the implies method of the Policy object, which is implemented by the provider. The EJBMethodPermission and the ProtectionDomain objects are passed to this method.
The isCallerInRole access check also follows the same process, except that an EJBRoleRefPermission object is created instead of an EJBMethodPermission object.

Access decisions for Web resources When security is enabled and configured to use a JACC provider, and when a Web resource such as a servlet or a JSP file is accessed, the security runtime delegates the authorization decision to the JACC provider by using the following process:

A WebResourcePermission object is created to see if the URI is cleared. If the provider honors the Everyone subject it is also selected here.

The WebResourcePermission object is constructed with the urlPattern and the HTTP method accessed.
A ProtectionDomain object with a null principal name is created.
The JACC provider Policy.implies method is called with the permission and the protection domain. If the URI access is cleared or given access to the Everyone subject, the provider permits access (return true) in the implies method. Access is then granted without further checks.

If access is not granted in the previous step, a WebUserDataPermission object is created and used to see if the URI is precluded, excluded or must be redirected using the HTTPS protocol.

The WebUserDataPermission object is constructed with the urlPattern accessed, the HTTP method invoked, and the transport type of the request. If the request is over HTTPS, the transport type is set to CONFIDENTIAL; otherwise, null is passed.
A ProtectionDomain object with a null principal name is created.
The JACC provider Policy.implies method is called with the permission and the protection domain. If the request is using the HTTPS protocol and the implies method returns false, the HTTP 403 error is returned to imply excluded and precluded permission. In this case no further checks are performed. If the request is not using the HTTPS protocol, and the implies returns false, the request is redirected over HTTPS.

The security runtime attempts to authenticate the user. If the authentication information already exists (for example, LTPA token), it is used. Otherwise, the user's credentials must be entered.
After the user credentials are validated, a final authorization check is performed to see if the user is granted access privileges to the URI.

As in Step 1, the WebResourcePermission object is created. The ProtectionDomain object now contains the Principal that is attempting to access the URI. The Subject policy context handler also contains the user’s information, which can be used for the access check.
The provider implies method is called using the Permission object and the ProtectionDomain object created previously. If the user is granted permission to access the resource, the implies method returns true. If the user is not granted access, the implies method returns false.

Even if the order listed previously is changed later (for example, to improve performance) the end result is the same. For example, if the resource is precluded or excluded, the end result is that the resource cannot be accessed.
Use information from the Subject for access decision
If the provider relies on the WAS generated Subject for access decision, the provider can query the public credentials in the Subject to obtain the WSCredential credential. The WSCredential API is used to obtain information about the user, including the name and the groups that the user belongs to. This information is used to make the access decision.
If the provider adds the required information to the Subject, WAS can use the information to make the access decision. The provider might add the information by using the Trust Association Interface feature or by plugging login modules into the appserver.
The security attribute propagation section contains additional documentation on how to add the WAS required information to the Subject.

Dynamic module updates in JACC

WAS supports dynamic updates to Web modules under certain conditions. If a Web module is updated, deleted or added to an application, only that module is stopped and started as appropriate. The other existing modules in the application are not impacted, and the application itself is not stopped and then restarted.
When using the default authorization engine, any security policies are modified in the Web modules and the application is stopped and then restarted. When using the Java Authorization Contract for Containers (JACC) based authorization, the behavior depends on the functionality that a provider supports. If a provider can handle dynamic changes to the Web modules, then only the Web modules are impacted. Otherwise, the entire application is stopped and restarted for the new changes in the Web modules to take effect.
A provider can indicate if it supports the dynamic updates by configuring the Supports dynamic module updates option in the JACC configuration model (see Authorizing access to J2EE resources using TAM for more information). This option can be enabled or disabled using the admin console or by scripting. It is expected that most providers store the policy information in their external repository, which makes it possible for them to support these dynamic updates. This option should be enabled by default for most providers.
When the Supports dynamic module updates option is enabled, if a Web module that contains security roles is dynamically added, modified, or deleted, only the specific Web modules are impacted and restarted. If the option is disabled, the entire application is restarted. When dynamic updates are performed, the security policy information of the modules impacted are propagated to the provider.

Initialization of the JACC provider

If a Java Authorization Contract for Containers (JACC) provider requires initialization during server startup, for example, to enable the client code to communicate to the server code, the provider can implement the com.ibm.wsspi.security.authorization.InitializeJACCProvider interface. See Interfaces that support JACC for more information.
When this interface is implemented, it is called during server startup. Any custom properties in the JACC configuration model are propagated to the initialize method of this implementation. The custom properties can be entered using either the admin console or by scripting.
During server shutdown, the cleanup method is called for any clean-up work that a provider requires. Implementation of this interface is strictly optional, and is used only if the provider requires initialization during server startup.

Mixed node environment and JACC

Authorization using Java Authorization Contract for Containers (JACC) is a new feature in WAS V 6.0.x. Also, the JACC configuration is set up at the cell level and is applicable for all the nodes and servers in that cell.
If planning to use the JACC-based authorization, the cell must contain V 6.0.x and later nodes only. This restriction implies that a mixed node environment containing a set of V5.x nodes in a V6.0.x or later cell is not supported.

Related concepts

Authorization providers
TAM integration as the JACC provider
JACC providers
Authorization providers

Related tasks

Enable an external JACC provider
Authorizing access to J2EE resources using TAM
Propagating security policy of installed applications to a JACC provider using wsadmin scripting

Related

Interfaces that support JACC
Security authorization provider troubleshooting tips
JACC policy context handlers
JACC policy context identifiers (ContextID) format
JACC policy propagation
JACC registration of the provider implementation classes