Single Sign-On for Java 3.3.2 - Administration Guide

Programmatic security

Using programmatic security with Single Sign-on for Java is identical to using programmatic security in normal Java EE applications. This means that you can use applications that support the standard Java EE isUserInRole mechanism with Single Sign-on for Java without recompiling the code.

In addition, Single Sign-on for Java gives access to much more information about the user, allowing you to, for example, enumerate all the groups to which a user belongs. For more information see the API documentation for the AuthUser interface.

Active Directory groups as roles

Single Sign-on for Java supports a configuration parameter that allows you to specify an Active Directory group name wherever a role is specified (either in a security constraint or programmatically in isUserInRole). With this parameter turned on, there is no need to specify extra role definitions.

To enable support for Active Directory groups as roles, add the following to your SSO Filter/Servlet configuration:

<!-- Indicate AD groups should be equivalent to roles -->

<init-param>

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

<param-value>true</param-value>

</init-param>

The following caveats apply when using groups as roles:

• If a role with the same name as an Active Directory group is specified in the policy file, the role name is used rather than the group.
• If you enable roles as groups, then you may get name clashes with roles defined programmatically. To counter this you can map the clashing role to a different Active Directory group.

  For example, suppose you have code which calls isUserInRole("Managers") that is meant to refer to Inventory managers, and an Active Directory group called Managers that refers to all Managers within the current domain, then you should create a role-mapping to override the group as follows:

  <role name="Manager">

  <group name="InventoryManagers"/>

  </role>

• When using programmatic security, the mapping between Active Directory names and SIDs may not be known until the actual call to isUserInRole. This may incur a delay for the first user that trips over this code, while Active Directory is contacted to perform the mapping. In all other cases this mapping can be done at load time.

Active Directory principals or groups in other realms or domains

Single Sign-on for Java supports cross-realm authentication and authorization so that the policy can refer to principals and groups in other domains. This is done by using the fully-qualified name of the principal/group, for example:

<role name="Suppliers">

<!-- Refer to suppliers in the Extranet realm -->

<include>

<group name="Suppliers@EXTERNAL.EXAMPLE.COM"/>

</include>

</role>

Names that are not qualified are automatically assumed to be in the default domain specified by the idm.realm configuration parameter. This fact needs to be taken into account when changing the default domain.

Recommendations for Managing Authorization

The best way to manage authorization for Single Sign-on for Java is to define the security constraints for the resources that you wish to protect, and then define one or more “Domain Local” Active Directory groups to manage access to these resources. This allows centralized management of authorization without requiring redeployment of the application.

This is recommended, as the groups which are allowed access to an application are likely to be stable, whereas the membership of these groups is not. The Domain Local group must be in the server's domain, but may include groups and users from any other domain. See Active Directory groups for more details.

An alternative is to define the roles fully in the policy XML file and redeploy each time the role membership changes. Despite the obvious disadvantages, this does have the benefit of not requiring any support from the IT staff who manage Active Directory to manage the application authorization. It is only recommended in cases where this advantage is significant or the authorization rules are likely to be very static.