Single Sign-On for Java 3.3.2 - Administration Guide

Single Sign-on for Java authorization

Single Sign-on for Java supports similar declarative and programmatic authorization models to the standard Java EE framework. Furthermore, Single Sign-on for Java allows you to define authorization in terms of Active Directory groups and principals, allowing centralized administration of authorization using Active Directory. Single Sign-on for Java also provides access to other information related to Active Directory user accounts such as their full name, last login time, number of bad password attempts since last successful login and a list of the groups to which they belong.

Compatibility with standard Java EE deployment descriptors

Because each application server container enforces its security constraints in a different and non-standardized way, it is not possible to reuse the existing security constraint mechanism in the Java EE deployment descriptor.

Instead, Single Sign-on for Java allows you to reuse the XML fragments in the standard deployment descriptors to specify the authorization policy in a separate XML file. This provides a compromise between tight container integration, and the ability for Single Sign-on for Java to support a wide range of Java application server platforms.

For this reason, when configuring authorization for Single Sign-on for Java you need to make sure that any existing security-constraint tags that apply to resources protected by Single Sign-on for Java are removed from the deployment descriptor.

How authorization works in Single Sign-on for Java

Single Sign-on for Java maintains an XML policy file detailing the authorization rules for an application. When the Single Sign-on for Java/Filter starts, it reads this policy file and contacts Active Directory to convert the user-friendly names used in the policy file, to the unique Security IDentifiers (SIDs) used by Active Directory. A secured LDAP connection is used to ensure that the mapping between these names and the SIDs can be relied upon.

When the browser contacts the application server, the Single Sign-on for Java-protected Filter/Servlet requests authentication using Windows Integrated Authentication. The end result is that the Filter/Servlet receives a Kerberos ticket that is proof of the user's authenticity.

In addition, Active Directory includes a Privilege Attribute Certificate (PAC) in the ticket. This includes information about the user including the Active Directory groups to which they belong. The PAC is also cryptographically authenticated, ensuring that the authorization information passed with the request can be relied upon.

The SSO Filter/Servlet then consults the policy to see if the constraints specified allow the user to access the requested resource. The constraints can be determined by the user's principal name, group membership, or—if programmatic security is being used—by any other useful information in the PAC. If the authorization is successful, then the user is allowed to access the resource. Otherwise, access is denied.

In most cases, the only time that the SSO Filter/Servlet needs to access security information from Active Directory is when it starts up. This greatly increases the scalability and reliability of your SSO solution.

The container may apply multiple filters to a request. Each filter may be assigned an access policy. Single Sign-on for Java currently recognizes only one access policy per request. There is currently no provision for combining multiple access policies.

For example, consider a request that is mapped using filters A and B. If filter A allows access to resource X, and filter B denies access to resource X, then access to resource X shall depend on whether filter A or filter B is being processed.

It is recommended that only one access policy is defined, and applied to one filter only.

Declarative security using Single Sign-on for Java

Single Sign-on for Java takes almost the same approach to declarative security as Java EE. Authorization rules are specified in XML using the same syntax as the standard <security-constraint> tag described above, and are placed in a separate policy file that the SSO Filter/Servlet reads at startup. In addition to specifying security constraints for the resources you wish to protect, this XML file also allows you to specify the role mappings that define which Active Directory groups and principals are members of a given role.

The following shows how the security constraints for declarative security in the order/inventory system described previously might be implemented:

<policy>

<role name="StockManager">

<include>

<group name="StockMgrs"/>

</include>

</role>

<security-constraint>

<web-resource-collection>

<web-resource-name>InventoryReports</web-resource-name>

<description>

Security constraint for restricting access to Inventory reports.

</description>

<url-pattern>/inventory/reports/*</url-pattern>

<http-method>POST</http-method>

<http-method>GET</http-method>

</web-resource-collection>

<auth-constraint>

<description>

Access only available to StockManagers

</description>

<role-name>StockManager</role-name>

</auth-constraint>

</security-constraint>

</policy>

You will notice that the policy file reuses the same syntax for the security constraint. In fact, in most cases you can copy the XML <security-constraint> fragments from the deployment descriptor to the Single Sign-on for Java policy file with few or no changes.

The only difference between the security-constraint tag here and the one in the original example is that the <login-config> tag has been removed. This is because it is implied from the use of Single Sign-on for Java for authentication. For similar reasons the <user-data-constraint> tag is also not supported in the SSO policy file.

Another addition is the specification of the “StockManager” role (mapping directly to the “StockMgrs” Active Directory group. This replaces the role definition function that the application server was required to do, meaning that the same roles can be used for authorization when deploying to any application server. Roles can be specified in terms of Active Directory groups, users, or other roles in the policy file. The role definition supports both an <includes> and an <excludes> tag to allow fine-grained specification of roles. This allows a lot of flexibility in the specification of roles by deployers, without the necessity to create new Active Directory groups specifically for your application.

To make an application using Single Sign-on for Java enforce this policy, you configure the Filter/Servlet by adding the idm.policy parameter. For example:

<filter>

<filter-name>authFilter</filter-name>

<filter-class>com.wedgetail.idm.sso.AuthFilter</filter-class>

<!-- Specify the policy file -->

<init-param>

<param-name>idm.access.policy</param-name>

<param-value>policy.xml</param-value>

</init-param>

...

</filter>