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.
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 -->
The following caveats apply when using groups as roles:
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:
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:
<!-- Refer to suppliers in the Extranet realm -->
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.
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.