Container for Federated Identity

Introduction to Liberty
WLS 9.0 SAML Overview
SOA With Cerntralized Authentication across security domains
A Proposal for SAML communications with JAAS
Shekar Jha's Blog (Contains FIM)

Technical Articles:


Sun ONE Identity Server Configuration Cookbook

J2EE Security: Authentication and Authorization

JSR-115 (JACC) defines a container contract for authorization purposes. JSR-115 defines a SPI for authentication for containers. I think these two specs are very important for a J2EE container provider when it comes to security.

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

Hashtable and HashCode

I am a big fan of Richard Monson-Haefel's technical books (EJB, JMS and J2EE Web Services).

Here is an explanation of Hashtable and Hashcodes that few developers grasp in practice:

A Hashtable is designed to provide fast lookups by binding an object to a key. Given any object's key, looking the object up in a hash table is a very quick operation. For the lookup, the key is converted to an integer value using the key's hashCode() method.


Hash codes do not need to be unique, only well-distributed. By "well-distributed," we mean that given any two keys, the chances are very good that the hash codes for the keys will be different. A well-distributed hash code algorithm reduces, but does not eliminate, the possibility that different keys evaluate to the same hash code. When keys evaluate to the same hash code, they are stored together and uniquely identified by their equals() method. If you look up an object using a key that evaluates to a hash code that is shared by several other keys, the Hashtable locates the group of objects that have been stored with the same hash code; then it uses the key's equals() method to determine which key (and hence, which object) you want. (That's why you have to override the equals() method in primary keys, as well as the hashCode() method.) Therefore, the emphasis in designing a good hash code algorithm is on producing codes that are well-distributed rather than unique. This allows you to design an index for associating keys with objects that is easy to compute, and therefore fast.

Source: Enterprise Java Beans, Second Edition



A decent writeup on HashCode and Equals is here:
HashCode and Equals in Java