Now, JACC can be used for externalizing authorization decisions.
(Reference: IBM Material)
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 run time. If JACC is enabled, the security run time 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 by 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 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 JavaServer Pages (JSP) file is accessed, the security run time delegates the authorization decision to the JACC provider by 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.
A. The WebResourcePermission object is constructed with the urlPattern and the HTTP method accessed.
B. A ProtectionDomain object with a null principal name is created.
C. 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.
A. 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 .
B. A ProtectionDomain object with a null principal name is created.
C. 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 run time 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.
A. 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.
B. 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.
Related Articles/Resources
JAAS Authorization
Java Access Control Mechanism [Good PDF on XACML Site]
Java Authorization Internals (Great Article)
Simplify enterprise Java authentication with single sign-on
Authorization Resources
XACML -- A No-Nonsense Developer's Guide
No comments:
Post a Comment