Authorization providers
WebSphere Application Server supports authorization based on the Java Authorization Contract for Containers (JACC) specification in addition to the default authorization.
JACC is a specification introduced in Java EE1.4. It enables third-party security providers to manage authorization in the application server.
In WebSphere Application Server version 7.0, Java Authorization Contract for Containers (JACC) specification 1.4 was applied. In JACC specification 1.4, we support Java EE5 that includes Servlet 2.5 and EJB 3. The biggest functional change with the introduction of JACC specification 1.4 is the inclusion of annotations for propagating security policy information.
(zos) Note: For WebSphere Application Server for z/OS , if SAF- based authorization is implemented, the implementation at this point does not use or implement the JACC Policy provider interface.
When security is enabled in WebSphere Application Server, the default authorization is used unless a JACC provider is specified. The default authorization does not require special setup, and the default authorization engine makes all of the authorization decisions. However, if a JACC provider is configured and set up for WebSphere Application Server to use, all of the enterprise beans and web authorization decisions are delegated to the JACC provider.
WebSphere Application Server supports security for Java EE applications and also for its administrative components. Java EE applications, such as Web and EJB components are protected and authorized per the Java EE specification. The administrative components are internal to WebSphere Application Server and are protected by the role-based authorizer. The administrative components include the console, MBeans, and other components such as naming and security. For more information on administrative security, see Role-based authorization.
When a JACC provider is used for authorization in WebSphere Application Server, all of the Java EE application-based authorization decisions are delegated to the provider per the JACC specification. However, all administrative security authorization decisions are made by the WAS default authorization engine. The JACC provider is not called to make the authorization decisions for administrative security.
When a protected Java EE resource is accessed, the authorization decision to give access to the principal is the same whether using the default authorization engine or a JACC provider. Both of the authorization models satisfy the J2EE specification, and function the same. Choose a JACC provider only when to work with an external security provider such as Tivoli Access Manager. In this instance, the security provider must support the JACC specification and be set up to work with WebSphere Application Server. Setting up and configuring a JACC provider requires additional configuration steps, depending on the provider. Unless we have an external security provider that we can use with WebSphere Application Server, use the default authorization.
Subtopics
- JACC support in WebSphere Application Server
WebSphere Application Server supports the Java Authorization Contract for Containers (JACC) specification, which enables third-party security providers to handle the Java EE authorization.
- JACC providers
The Java Authorization Contract for Containers (JACC) is a specification that was first introduced in Java EE Version 1.4 through the Java Specifications Request (JSR) 115 process. JACC specification 1.4 is included for WebSphere Application Server version 7.0 for Java EE 5 support.. This specification defines a contract between Java EE 5 containers and authorization providers.
- JACC policy context handlers
WebSphere Application Server supports all of the policy context handlers required by the Java Authorization Contract for Containers (JACC) specification. However, due to performance impacts, the EJB arguments policy context handler is not activated unless it is specifically required by the provider. Performance impacts result if objects must be created for each argument of each EJB method.
- JACC policy context identifiers (ContextID) format
A policy context identifier is defined as a unique string that represents a policy context. A policy context contains all of the security policy statements as defined by the Java Contract for Containers (JACC) specification that affect access to the resources in a web or EJB module.
- JACC policy propagation
When an application is installed or deployed in WebSphere Application Server, the security policy information in the application is propagated to the provider when the configuration is saved. The context ID for the application is saved in its application.xml file, used for propagating the policy to the Java Authorization Contract for Containers (JACC) provider, and also for access decisions for Java EE resources.
- JACC registration of the provider implementation classes
The JACC specification states that providers can plug in their provider using the javax.security.jacc.policy.provider and the javax.security.jacc.PolicyConfigurationFactory.provider system properties.
- Role-based security with embedded Tivoli Access Manager
The Java EE role-based authorization model uses the concepts of roles and resources. An example is provided here.
- Tivoli Access Manager integration as the JACC provider
Tivoli Access Manager uses the Java Authorization Contract for Container (JACC) model in WebSphere Application Server to perform access checks.
- Tivoli Access Manager security for WebSphere Application Server
WebSphere Application Server provides embedded IBM Tivoli Access Manager client technology to secure the WAS-managed resources.
- Security annotations
Annotations are a powerful programming mechanism resulting from the JSR-175 recommendation. An annotation is a standard way to include supported security behaviors while allowing, the source code and configuration files to be generated automatically.
- Java Servlet 3.0 support for security
This release of WAS supports all security updates as defined in the Java Servlet 3.0 specification.
- Servlet security dynamic annotations
When you use the programmatic APIs to add or to create a servlet, the security annotations, RunAs, declareRoles and ServletSecurity, can be dynamically updated through the setRunAsRole(), declareRoles() and setServletSecurity() methods respectively.
Related concepts
Authorization technology
Related tasks
Enable an external JACC provider Authorizing access to Java EE resources using Tivoli Access Manager Propagating security policy of installed applications to a JACC provider
Interfaces that support JACC Security authorization provider troubleshooting tips