Single Sign-On for Java 3.3.2 - Administration Guide

Writing access policy files

This section describes in detail how to write access policy files for Single Sign-on for Java. You should be familiar with the Single Sign-on for Java approach to authorization as described in Single Sign-on for Java authorization.

• Overview of policy files
• Preconditions for writing an XML policy file
• Creating the policy XML file

Overview of policy files

Single Sign-on for Java uses a standard text file, formatted in XML for the authorization policy. This policy file consists of two main components:

• Role definitions: List of roles and their members
• Security constraints: List of constraints to apply to resources being protected

This file is included in the Web Application aRchive (WAR) file, and referred to from the Web application deployment descriptor using the idm.access.policy parameter of the SSO Servlet/Filter configuration.

You can define a policy file for each Filter/Servlet, or define a global one for your application by setting the parameter inside the <servlet-context> tag of the deployment descriptor.

Preconditions for writing an XML policy file

1. Identify the resources that are to be protected.
2. Identify the roles that are to access these resources.
3. Disable any security constraints in your existing deployment descriptor.
4. The following sections discuss each of these steps in more detail.

Identify the resources to be protected

The first step to undertake in defining an access policy is to determine which resources require protection. Single Sign-on for Java allows you define one or more resource collections which are sets of URLs that match Servlets/JSPs in your application.

Depending on the complexity of your application you may decide to have one access policy that covers the entire application, or you may wish to define finer-grained access to each resource.

It helps if you can arrange the namespace of your application so that resources belonging to different groups have different URL prefixes. For example, if you have an application that has administrative and user components, you may choose to organize resources with the prefixes /admin and /user.