Authentication and Authorization

The Service Provider Authentication/Authorization servlet filter serves as the default authentication system for the sample user pages. This filter ensures that protected pages can only be accessed after successful authentication. If a client attempts to access to a protected page without proper authentication, the filter would redirect the client to the login page.

Authentication is executed when the user clicks the login button on the login page. The filter attempts to authenticate the user by authenticating the user against the Service Provider directory with the provided credentials. During this process, the system verifies credentials and also determines whether the user’s profile has been locked due to multiple login attempt failures. If the profile is locked, then access is denied to the self-service pages and the appropriate error message is displayed.

Pages that require authentication can be accessed using a different path than pages that can be accessed anonymously. This protected path is a configuration option of the filter.

Because pages that require authentication are accessible using a different path than anonymous pages, protecting these pages are easy to configure in any access management system. The sample user pages do not depend on a particular type of authentication nor do they require the password anywhere but in the filter. The sample pages only require the user name for auditing purposes.

When authentication successfully completes, the filter puts the Constants.VAR_SUBJECT variable into the session with the user name as the value. To access pages that require authentication, the subject must be present in the session. When the user logs out of the self-service pages, the session is invalidated. The session timeout configured for the application defines how long the user can be inactive without being “logged out”.

Configuring the Filter

The $WSHOME/WEB-INF/web.xml file contains the definition the Service Provider Authentication/Authorization filter. This filter handles authentication and ensures that protected pages can only be accessed after successful authentication. If a client attempts to access to a protected page without proper authentication, the filter would redirect the client to the login page.

The Service Provider Authentication/Authorization filter defines the following parameters. Note that the parameters that specify a directory or page must include the path to the web application.

See Account and Password Policies for information about implementing lockout policies in Service Provider.

Specifying Protected and Public Pages

The protected-pages-path parameter in the web.xml file specifies the directory in which pages that need authentication must reside. Public pages must reside in a different location.

The following pages are provided in the $WSHOME/spe/user/protected directory by default.

• Form.jsp— Displays Identity Manager form output.

• Home.jsp— The content that appears on the page that is displayed after the user is successfully authenticated.

• OperationResult.jsp— Displays a successful operation message in an authenticated context, such as a successful password change.

Other customized files may be added to this directory.

See Specifying an Action Path for more information about implementing authentication with the default authentication filter.

Integrating with Access Manager

The AuthFilter can also be configured to work in an environment with an access management solution, such as the Sun Java System Access Manager. In these environments, Service Provider is not responsible for logging in the user because the access management solution is used to protect the end user pages.

The normal login process places the user name into the HTTP session. But when the normal process is not used, Service Provider requires the access management solution to put the username in a configured HTTP header before forwarding the HTTP request.

Two configuration attributes in the SPEUserPages configuration object control how the Service Provider end user pages work in this environment.

• sso-assume-authenticated— If set to true, the AuthFilter will not redirect to a login page. However, for auditing purposes, the filter requires a user name to associate with each request. Normally, this username is stored on the HTTP session by the login pages. However, since the login pages are not used in an SSO environment, the username is pulled from an HTTP header attribute.

• sso-user-name-http-header-attr— Specifies the name of the HTTP header attribute to use.

See SPEUserPages Configuration Object for more information.

For Sun Java System Access Manager, to ensure that the header is set, edit the AMAgent.properties file to include entries similar to the following:

com.sun.identity.agents.config.profile.attribute.fetch.mode = HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid] = HEADER_speuid

Assuming users login with the uid attribute, the Access Manager Policy Agent will store the uid value in the HEADER_idmuid HTTP header before forwarding requests to the Service Provider User Interface pages.

Integrating with Other Access Management Systems

You can use a third-party access management access system to perform the authentication/authorization instead of the provided filter and still leverage the self-service features of the sample pages. The integration is the easiest if the access management system can provide the name of the authenticated user in the HTTP request header. In this case, steps similar to the Integration with Access Manager can be followed.

If providing the name of the authenticated user in the HTTP request header is not possible, then the following guidelines should be followed to enhance or replace the provided filter:

• All self-service pages that require authentication are under the /spe/user/protected folder, all other pages are in the /spe/user folder.

• On successful authentication, the Constants.VAR_SUBJECT session attribute must be set to the corresponding user name in Service Provider.