JACC support in WAS
WebSphere Application Server (WAS) supports the Java Authorization Contract for Containers (JACC) specification, which enables third-party security providers to handle the J2EE authorization.
The specification 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 run time 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 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 implemented by the provider to make the access decision.
The following sections describe how the provider is called for both the EJB 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:
- It creates the EJBMethodPermission object using the bean name, method name, interface name and the method signature.
- It creates the contextID and sets it on the thread by using the PolicyContext.setContextID(contextID) method.
- It registers the required policy context handlers, including the Subject policy context handler.
- It creates the ProtectionDomain object with principal in the Subject. If there is no principal, 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.
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 JavaServer pages (JSP) is accessed, the security runtime delegates the authorization decision to the JACC provider by using the following process:
- A WebResourcePermission is created to see if the URI is unchecked. If the provider honors the Everyone subject it should also be checked here.
- The WebResourcePermission is constructed with urlPattern and the HTTP method accessed.
- A ProtectionDomain with a null principal name is created.
- The JACC provider’s Policy.implies( ) method is called with the permission and the protection domain. If the URI access is unchecked (or given access to Everyone subject), the provider should permit access (return true) in the implies() method. Access is then granted without further checks.
- If the access was not granted in Step 1, a WebUserDataPermission is created and used to see if the URI is precluded or excluded or must be redirected using HTTPS protocol.
- The WebUserDataPermission is constructed with the urlPattern accessed, along with 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.
- ProtectionDomain with a null principal name is created.
- The JACC provider's Policy.implies( ) method is called with the permission and the protection domain. If the request is using the HTTPS protocol and the implies returns false, the HTTP 403 error is returned to imply excluded/precluded permission and 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, LTPAToken), 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 has been granted access privileges to the URI.
- As in Step 1, the WebResourcePermission is created. The ProtectionDomain 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’s implies() method is called using the Permission object and the ProtectionDomain created above. If the user is granted permission to access the resource, the implies( ) method should return true. If the user is not granted access, the implies() method should return false.
Note: Even if the order listed above is changed later (for example, to improve performance) the end result should be the same. For example, if the resource is precluded or excluded the end result is that the resource cannot be accessed.
Using 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 credential of type WSCredential . 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 then used to make the access decision.
If the provider adds 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 Application Server.
The security attribute propagation section contains additional documentation on how to add 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/or 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 they will support the dynamic updates by configuring the supports dynamic module updates option in the JACC configuration model This option can be enabled or disabled using the administrative console or by scripting. It is expected that most providers will 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), they can implement the interface...com.ibm.wsspi.security.authorization.InitializeJACCProvider
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 administrative 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 should be 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 v6.x. Previous versions of the WAS do not support this feature. Also, the JACC configuration is set up at the cell level and is applicable for all the nodes and servers in that cell..
If you are planning to use the JACC-based authorization, the cell must contain 6.0.x nodes only. This implies that a mixed node environment containing a set of 5.x nodes in a 6.0 cell is not supported.
See alsoJACC policy context handlers
JACC policy context identifiers (ContextID) format
JACC policy propagation
JACC registration of the provider implementation classes
Authorization in WAS
Tivoli Access Manager integration as the JACC provider
Enable an external JACC provider
Configure a JACC provider
Propagate security policy of installed applications to a JACC provider using wsadmin scripting
Interfaces used to support JACC
Troubleshoot authorization providers
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.