+

Search Tips   |   Advanced Search

JACC support in WAS

WebSphere Application Server supports the Java Authorization Contract for Containers (JACC) specification, which enables third-party security providers to handle the Java EE authorization.

The J2EE Web and EJB containers:

The security provider:


JACC access decisions

The web or EJB container uses the security runtime to call an external provider which makes the authorization decision.

  1. A permission object is created
  2. Policy context handlers are registered
  3. A policy context identifier (contextID) is set
  4. A call is made to the external provider java.security.Policy object to make the access decision


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 using the following process:

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

    1. The WebResourcePermission object is constructed with the urlPattern and the HTTP method accessed.

    2. A ProtectionDomain object with a null principal name is created.

    3. 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.

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

    1. 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.

    2. A ProtectionDomain object with a null principal name is created.

    3. 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.

  3. 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.

  4. After the user credentials are validated, a final authorization check is performed to see if the user is granted access privileges to the URI.

    1. 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.

    2. 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.

For more information on these access permissions, see JSR-000115 Java Authorization Contract for Containers .



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:

  1. Creates the EJBMethodPermission object using the bean name, method name, interface name, and the method signature.

  2. Creates the context ID and sets it on the thread using the PolicyContext.setContextID(contextID) method.

  3. Registers the required policy context handlers, including the Subject policy context handler.

  4. Creates the ProtectionDomain object with principal in the Subject. If no principal exists, null is passed for the principal name.

  5. 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.

  6. The isCallerInRole access check also follows the same process, except an EJBRoleRefPermission object is created instead of an EJBMethodPermission object.


Use information from the Subject for access decision

If the security 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 security provider adds the required information to the Subject, WAS can use the information to make the access decision. The provider might add the information 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 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 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 Java EE resources using ISAM for more information). This option can be enabled or disabled using the administrative 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 containing 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 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 interface:

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 is used only if the provider requires initialization during server startup.


Mixed node environment and JACC

Authorization using JACC was a new feature in WAS v6 and it is enhanced to the latest JACC specification version 1.5 in WAS v9.

The JACC configuration is set up at the cell level and is applicable for all the nodes and servers in that cell.

If we are planning to use the JACC-based authorization version 1.5 functions, the cell must contain v9 and later nodes only. This restriction implies that a mixed node environment containing the v8.5.x or earlier nodes in a v9 or later cell is supported for the JACC-based authorization based on the lowest supported version in the cell. In this case it is the JACC-based authorization version 1.4.


Related:

  • Authorization providers
  • ISAM integration as the JACC provider
  • JACC providers
  • Enable an external JACC provider
  • Authorizing access to Java EE resources using ISAM
  • Propagating security policy of installed applications to a JACC provider
  • 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
  • JSR-000115 Java Authorization Contract for Containers