Skip to ContentSun and Oracle Channel Sun How to Buy Log In

Sun Java System Access Manager 7.1 Administration Guide

Exibir este livro em:

Contidos dentro

Sun Java System Access Manager 7.1

Localizar Mais Documentação

Destaques de Recursos de Suporte

Fazer download desta apostila em PDF (1232 KB)

Anterior: Access Control

Part II Directory Management and Default Services

This is part two of the Sun Java System Access Manager 7.1 Administration Guide. The Directory Management chapter describes how to manage Directory objects when Access Manager is deployed in Legacy Mode. The other chapters describe how to configure and use some of Access Manager's default services. This part contains the following chapters:

Chapter 7 Directory Management

The Directory Management tab is only displayed when you install Access Manager in Legacy mode. This directory management feature provides an identity management solution for Sun Java System Directory Server-enabled Access Manager deployments.

For more information on the Legacy Mode installation option, see the Sun Java Enterprise System 5 Installation Guide for UNIX

Managing Directory Objects

The Directory Management tab contains all the components needed to view and manage the Directory Server objects. This section explains the object types and details how to configure them. User, role, group, organization, sub organization and container objects can be defined, modified or deleted using either the Access Manager console or the command line interface. The console has default administrators with varying degrees of privileges used to create and manage the directory objects. (Additional administrators can be created based on roles.) The administrators are defined within the Directory Server when installed with Access Manager. The Directory Server objects you can manage are:

Organizations

An Organization represents the top-level of a hierarchical structure used by an enterprise to manage its departments and resources. Upon installation, Access Manager dynamically creates a top-level organization (defined during installation) to manage the Access Manager enterprise configurations. Additional organizations can be created after installation to manage separate enterprises. All created organizations fall beneath the top-level organization.

To Create an Organization

Click the Directory Management tab.

In the Organizations list, click New.

Enter the values for the fields. Only Name is required. The fields are:

Name

Enter a value for the name of the Organization.

Domain Name

Enter the full Domain Name System (DNS) name for the organization, if it has one.

Organization Status

Choose a status of active or inactive . The default is active. This can be changed at any time during the life of the organization by selecting the Properties icon. Choosing inactive disables user access when logging in to the organization.

Organization Aliases

This field defines alias names for the organization, allowing you to use the aliases for authentication with a URL login. For example, if you have an organization named exampleorg, and define 123 and abc as aliases, you can log into the organization using any of the following URLs:

http://machine.example.com/amserver/UI/Login?org=exampleorg

http://machine.example.com/amserver/UI/Login?org=abc

http://machine.example.com/amserver/UI/Login?org=123

Organization alias names must be unique throughout the organization. You can use the Unique Attribute List to enforce uniqueness.

DNS Alias Names

Allows you to add alias names for the DNS name for the organization. This attribute only accepts “real” domain aliases (random strings are not allowed). For example, if you have a DNS named example.com, and define example1.com and example2.com as aliases for an organization named exampleorg, you can log into the organization using any of the following URLs:

http://machine.example.com/amserver/UI/

Login?org=exampleorg

http://machine.example1.com/amserver/

UI/Login?org=exampleorg

http://machine.example2.com/amserver/

UI/Login?org=exampleorg

Unique Attribute List

Allows you to add a list of unique attribute names for users in the organization. For example, if you add a unique attribute name specifying an email address, you would not be able to create two users with the same email address. This field also accepts a comma-separated list. Any one of the attribute names in the list defines uniqueness. For example, if the field contains the following list of attribute names:

PreferredDomain, AssociatedDomain

and PreferredDomain is defined as http://www.example.com for a particular user, then the entire comma-separated list is defined as unique for that URL. Adding the naming attribute 'ou' to the Unique Attribute List will not enforce uniqueness for the default groups, people containers. (ou=Groups,ou=People).

Uniqueness is enforced for all sub organizations.

Note –
Unique attributes can not be set in Realm mode. They also cannot be set in the 7.0 or 7.1–based consoles for Legacy mode. In order to create the unique attribute list, you must login into the 6.3–based console. See Legacy Mode 6.3 Console for more information.

Click OK.

The new organization displays in the Organization list. To edit any of the properties that you defined during creation of the organization, click the name of the organization you wish to edit, change the properties and click Save.

To Delete an Organization

Select the checkbox next to the name of the organization to be deleted.

Click Delete.

Note –
There is no warning message when performing a delete. All entries within the organization will be deleted and you can not perform an undo.

To Add an Organization to a Policy

Access Manager objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject. Once the subject is defined, the policy will be applied to the object. For more information, see Managing Policies.

Containers

The container entry is used when, due to object class and attribute differences, it is not possible to use an organization entry. It is important to remember that the Access Manager container entry and the Access Manager organization entry are not necessarily equivalent to the LDAP object classes organizationalUnit and organization. They are abstract identity entries. Ideally, the organization entry will be used instead of the container entry.

Note –

The display of containers is optional. To view containers you must select Show Containers in the Administration service under Configuration>Console Properties.

To Create a Container

Select the location link of the organization or container where the new container will be created.

Click the Containers tab.

Click New in the Containers list.

Enter the name of the container to be created.

Click OK.

To Delete a Container

Click the Containers tab.

Select the checkbox next to the name of the container to be deleted.

Click Delete.

Note –
Deleting a container will delete all objects that exist in that Container. This includes all objects and sub containers.

Group Containers

A group container is used to manage groups. It can contain only groups and other group containers. The group container Groups is dynamically assigned as the parent entry for all managed groups. Additional group containers can be added, if desired.

Note –

The display of group containers is optional. To view group containers you must select Enable Group Containers in the Administration service under Configuration>Console Properties.

To Create a Group Container

Select the location link of the organization or the group container which will contain the new group container.

Select the Group Containers tab.

Click New in the Group Containers list.

Enter a value in the Name field and click OK. The new group container displays in the Group Containers list.

To Delete a Group Container

Navigate to the organization which contains the group container to be deleted.

Choose the Group Containers tab.

Select the checkbox next to the group container to be deleted.

Click Delete.

Groups

A group represents a collection of users with a common function, feature or interest. Typically, this grouping has no privileges associated with it. Groups can exist at two levels; within an organization and within other managed groups. Groups that exist within other groups are called sub-groups. Sub groups are child nodes that “physically” exist within a parent group.

Access Manager also supports nested groups, which are “representations” of existing groups contained in a single group. As opposed to sub groups, nested groups can exist anywhere in the DIT. They allow you to quickly set up access permissions for a large number of users.

There are two types of groups you can create; static groups and dynamic groups. Users can only be manually added to static groups, while dynamic groups control the addition of users through a filter. Nested or sub groups can be added to both types.

Static Group

A static group is created based on the Managed Group Type you specify. Group members are added to a group entry using the groupOfNames or groupOfUniqueNames object class.

Note –

By default, the managed group type is dynamic. You can change this default in the Administration service configuration.

Dynamic Group

A dynamic group is created through the use of an LDAP filter. All entries are funneled through the filter and dynamically assigned to the group. The filter would look for any attribute in an entry and return those that contain the attribute. For example, if you were to create a group based on a building number, you can use the filter to return a list all users containing the building number attribute.

Note –

Access Manager should be configured with Directory Server to use the referential integrity plug-in. When the referential integrity plug-in is enabled, it performs integrity updates on specified attributes immediately after a delete or rename operation. This ensures that relationships between related entries are maintained throughout the database. Database indexes enhance the search performance in Directory Server. For more information on enabling the plug-in, see the Sun Java Access Manager 6 Migration Guide.

To Create a Static Group

Navigate to the organization, group, or group container where the new group will be created.

From the Groups list, click New Static.

Enter a name for the group in the Name field. Click Next.

Select the Users Can Subscribe to this Group attribute to allow users to subscribe to the group themselves.

Click OK.

Once the group is created, you can edit the Users Can Subscribe to this Group attribute by selecting the name of the group and clicking the General tab.

To Add or Remove Members to a Static Group

From the Groups list, select the group to which you will add members.

Choose an action to perform in the Select Action menu. The actions you can perform are as follows:

New User

This action creates a new user and adds the user to the group when the user information is saved.

Add User

This action adds an existing user to the group. When you select this action, you create a search criteria which will specify users you wish to add. The fields used to construct the criteria use either an ANY or ALL operator. ALL returns users for all specified fields. ANY returns users for any one of the specified fields. If a field is left blank, it will match all possible entries for that particular attribute.

Once you have constructed the search criteria, click Next. From the returned list of users, select the users you wish to add and click Finish.

Add Group

This action adds a nested group to the current group. When you select this action, you create a search criteria, including search scope, the name of the group (the “*” wildcard is accepted), and you can specify whether users can subscribe to the group themselves. Once you have entered the information, click Next. From the returned list of groups, select the group you wish to add and click Finish.

Remove Members

This action will remove members (which includes users and groups) from the group, but will not delete them. Select the member(s) you wish to remove and choose Remove Members from the Select Actions menu.

Delete Members

This action will permanently delete the member you select. Select the member(s) you wish to delete and choose Delete Members.

To Create a Dynamic Group

Navigate to the organization or group where the new group will be created.

Click the Groups tab.

Click New Dynamic.

Enter a name for the group in the Name field.

Construct the LDAP search filter.

By default, Access Manager displays the Basic search filter interface. The Basic fields used to construct the filter use either an ANY or ALL operator. ALL returns users for all specified fields. ANY returns users for any one of the specified fields. If a field is left blank it will match all possible entries for that particular attribute.

When you click OK all users matching the search criteria are automatically added to the group.

To Add or Remove Members to a Dynamic Group

Form the Groups list, click the name of the group to which you will add members.

Choose an action to perform in the Select Action menu. The actions you can perform are as follows:

Add Group

This action adds a nested group to the current group. When you select this action, you create a search criteria, including search scope, the name of the group (the “*” wildcard is accepted), and you can specify whether users can subscribe to the group themselves. Once you have entered the information, click Next. From the returned list of groups, select the group you wish to add and click Finish.

Remove Members

This action will remove members (which includes groups) from the group, but will not delete them. Select the member(s) you wish to remove and choose Remove Members

Delete Members

This action will permanently delete the member you select. Select the member(s) you wish to delete and choose Delete Members.

To Add a Group to a Policy

Access Manager objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Managing Policies.

People Containers

A people container is the default LDAP organizational unit to which all users are assigned when they are created within an organization. People containers can be found at the organization level and at the people container level as a sub People Container. They can contain only other people containers and users. Additional people containers can be added into the organization, if desired.

Note –

The display of people containers is optional. To view People Containers you must select Enable People Containers in the Administration Service.

Create a People Container

Navigate to the organization or people container where the new people container will be created.

Click New from the People Container list.

Enter the name of the people container to be created.

Click OK.

To Delete a People Container

Navigate to the organization or people container which contains the people container to be deleted.

Select the checkbox next to the name of the people container to be deleted.

Click Delete.

Note –
Deleting a people container will delete all objects that exist in that people container. This includes all users and sub people containers.

Users

A user represents an individual’s identity. Through the Access Manager Identity Management module, users can be created and deleted in organizations, containers and groups and can be added or removed from roles and/or groups. You can also assign services to the user.

Note –

If a user in a sub organization is created with the same user ID as amadmin, the login will fail for amadmin. If this problem occurs, the administrator should change the user’s ID through the Directory Server console. This enables the administrator to login to the default organization. Additionally, the DN to Start User Search in the authentication service can be set to the people container DN to ensure that a unique match is returned during the login process.

To Create a User

Navigate to the organization, container or people container where the user is to be created.

Click the user tab.

Click New from the user list.

Enter data for the following values:

User ID

This field takes the name of the user with which he or she will log into Access Manager. This property may be a non-DN value.

First Name

This field takes the first name of the user. The First Name value and the Last Name value identify the user in the Currently Logged In field. This is not a required value.

Last Name

This field takes the last name of the user. The First Name value and the Last Name value identify the user.

Full Name

This field takes the full name of the user.

Password

This field takes the password for the name specified in the User Id field.

Password (Confirm)

Confirm the password.

User Status

This option indicates whether the user is allowed to authenticate through Access manager. Only active users can authenticate. The default value is Active.

Click OK.

To Edit the User Profile

When a user who has not been assigned an administrative role authenticates to the Access Manager, the default view is their own User Profile. Additionally, administrators with the proper privileges can edit user profiles. In this view the user can modify the values of the attributes particular to their personal profile. The attributes displayed in the User Profile view can be extended. For more information on adding customized attributes for objects and identities, see the Access Manager Developer's Guide.

Select the user who's profile is to be edited. By default, the General view is displayed.

Edit the following fields:
First Name

This field takes the first name of the user.

Last Name

This field takes the last name of the user.

Full Name

This field takes the full name of the user.

Password

Click the Edit link to add and confirm the user password.

Email Address

This field takes the email address of the user.

Employee Number

This field takes the employee number of the user.

Telephone Number

This field takes the telephone number of the user.

Home Address

This field can take the home address of the user.

User Status
This option indicates whether the user is allowed to authenticate through Access Manager. Only active users can authenticate through Access Manager. The default value is Active. Either of the following can be selected from the pull-down menu: .
- Active — The user can authenticate through Access Manager.
- Inactive — The user cannot authenticate through Access Manager, but the user profile remains stored in the directory.
  
  Note –
  Changing the user status to Inactive only affects authentication through Access Manager. The Directory Server uses the nsAccountLock attribute to determine user account status. User accounts inactivated for Access Manager authentication can still perform tasks that do not require Access Manager. To inactivate a user account in the directory, and not just for Access Manager authentication, set the value of nsAccountLock to false. If delegated administrators at your site will be inactivating users on a regular basis, consider adding the nsAccountLock attribute to the Access Manager User Profile page. See the Sun Java System Access Manager 7.1 Developer’s Guide for details.
Account Expiration Date

If this attribute is present, the authentication service will disallow login if the current date and time has passed the specified Account Expiration Date. The format for this attribute is mm/dd/yyyy hh:mm.

User Authentication Configuration

This attribute sets the authentication chain for the user.

User Alias List

The field defines a list of aliases that may be applied to the user. In order to use any aliases configured in this attribute, the LDAP service has to be modified by adding the iplanet-am-user-alias-list attribute to the User Entry Search Attributes field in the LDAP service.

Preferred Locale

This field specifies the locale for the user.

Success URL

This attribute specifies the URL that the user will be redirected to upon successful authentication.

Failure URL.

This attribute specifies the URL that the user will be redirected to upon unsuccessful authentication.

Password Reset Options

This is used to select the questions on the forgotten password page, which is used to recover a forgotten password.

User Discovery Resource Offering

Sets the User Discovery service's resource offering for the user.

MSIDSN Number

Defines the user's MSISDN number if using MSISDN authentication.

To Add a User to Roles and Groups

Click the Users tab.

Click the name of the user you wish to modify.

Select either the Roles or Groups tab.

Select the role or group to which you wish to add the user and click Add.

Click Save.

Note –
To remove a user from Roles or groups, Select roles or groups and click Remove and then Save.

To Add a User to a Policy

Access Manager objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Managing Policies.

Roles

Roles are a Directory Server entry mechanism similar to the concept of a group. A group has members; a role has members. A role’s members are LDAP entries that possess the role. The criteria of the role itself is defined as an LDAP entry with attributes, identified by the Distinguished Name (DN) attribute of the entry. Directory Server has a number of different types of roles but Access Manager can manage only one of them: the managed role.

Note –

The other Directory Server role types can still be used in a directory deployment; they just can not be managed by the Access Manager console. Other Directory Server types can be used in a policy’s subject definition. For more information on policy subjects, see Creating Policies.

Users can possess one or more roles. For example, a contractor role which has attributes from the Session Service and the Password Reset Service might be created. When new contractor employees join the company, the administrator can assign them this role rather than setting separate attributes in the contractor entry. If the contractor is working in the Engineering department and requires services and access rights applicable to an engineering employee, the administrator could assign the contractor to the engineering role as well as the contractor role.

Access Manager uses roles to apply access control instructions. When first installed, Access Manager configures access control instructions (ACIs) that define administrator permissions. These ACIs are then designated in roles (such as Organization Admin Role and Organization Help Desk Admin Role) which, when assigned to a user, define the user’s access permissions.

Users can view their assigned roles only if the Show Roles on User Profile Page attribute is enabled in the Administration Service.

Note –

There are two types of roles:

Static — Static roles are created without adding users at the point of the role’s creation. Once the role is created, you can then add specific users to it. This gives you more control when adding users to a given role.
Dynamic – Dynamic roles are created through the use of an LDAP filter. All users are funneled through the filter and assigned to the role at the time of the role’s creation. The filter looks for any attribute value pair (for example, ca=user*) in an entry and automatically assign the users that contain the attribute to the role.

To Create a Static Role

Go to the organization where the Role will be created.

Click the Roles tab.

A set of default roles are created when an organization is configured, and are displayed in the Roles list. The default roles are:

Container Help Desk Admin. The Container Help Desk Admin role has read access to all entries in an organizational unit and write access to the userPassword attribute in user entries only in this container unit.

Organization Help Desk Admin. The Organization Help Desk Administrator has read access to all entries in an organization and write access to the userPassword attribute.

Note –
When a sub organization is created, remember that the administration roles are created in the sub organization, not in the parent organization.

Container Admin. The Container Admin role has read and write access to all entries in an LDAP organizational unit. In Access Manager, the LDAP organizational unit is often referred to as a container.

Organization Policy Admin. The Organization Policy Administrator has read and write access to all policies, and can create, assign, modify, and delete all policies within that organization.

People Admin. By default, any user entry in an newly created organization is a member of that organization. The People Administrator has read and write access to all user entries in the organization. Keep in mind that this role DOES NOT have read and write access to the attributes that contain role and group DNs therefore, they cannot modify the attributes of, or remove a user from, a role or a group.

Note –
Other containers can be configured with Access Manager to hold user entries, group entries or even other containers. To apply an Administrator role to a container created after the organization has already been configured, the Container Admin Role or Container Help Desk Admin defaults would be used.

Group Admin. The Group Administrator created when a group is created has read and write access to all members of a specific group, and can create new users, assign users to the groups they manage, and delete the users the that they have created.

When a group is created, the Group Administrator role is automatically generated with the necessary privileges to manage the group. The role is not automatically assigned to a group member. It must be assigned by the group’s creator, or anyone that has access to the Group Administrator Role.

Top-level Admin. The Top-level Administrator has read and write access to all entries in the top-level organization. In other words, this Top-level Admin role has privileges for every configuration principal within the Access Manager application.

Organization Admin. The Organization Administrator has read and write access to all entries in an organization. When an organization is created, the Organization Admin role is automatically generated with the necessary privileges to manage the organization.

Click the New Static button.

Enter a name for the role.

Enter a description of the role.

Choose the role type from the Type menu.

The role can be either an Administrative role or a Service role. The role type is used by the console to determine and here to start the user in the Access Manager console. An administrative role notifies the console that the possessor of the role has administrative privileges; the service role notifies the console that the possessor is an end user.

Choose a default set of permissions to apply to the role from the Access Permission menu. The permissions provide access to entries within the organization. The default permissions shown are in no particular order. The permissions are:

No permissions

No permissions are to be set on the role.

Organization Admin

The Organization Administrator has read and write access to all entries in the configured organization.

Organization Help Desk Admin

The Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute.

Organization Policy Admin

The Organization Policy Administrator has read and write access to all policies in the organization. The Organization Policy Administrator can not create a referral policy to a peer organization.

Generally, the No Permissions ACI is assigned to Service roles, while Administrative roles are assigned any of the default ACIs.

To Add Users to a Static Role

Click the name of the role to which you wish to add users.

In the Members list, select Add User from the Select Action menu.

Enter the information for the search criteria. You can choose to search for users based on one or more the displayed fields The fields are:

Match

Allows you to select the fields you wish to include for the filter. ALL returns users for all specified fields. ANY returns users for any one of the specified fields.

First Name

Search for users by their first name.

User ID

Search for a user by User ID.

Last Name

Search for users by their last name.

Full Name

Search for users by their full name.

User Status

Search for users by their status (active or inactive)

Click Next to begin the search. The results of the search are displayed.

Choose the users from the names returned by selecting the checkbox next to the user name.

Click Finish.

The Users are now assigned to the role.

To Create a Dynamic Role

Go to the organization where the Role will be created.

Click the Roles tab.

A set of default roles are created when an organization is configured, and are displayed in the Roles list. The default roles are:

Container Help Desk Admin. The Container Help Desk Admin role has read access to all entries in an organizational unit and write access to the userPassword attribute in user entries only in this container unit.

Organization Help Desk Admin. The Organization Help Desk Administrator has read access to all entries in an organization and write access to the userPassword attribute.

Note –
When a sub organization is created, remember that the administration roles are created in the sub organization, not in the parent organization.

Container Admin. The Container Admin role has read and write access to all entries in an LDAP organizational unit. In Access Manager, the LDAP organizational unit is often referred to as a container.

Organization Policy Admin. The Organization Policy Administrator has read and write access to all policies, and can create, assign, modify, and delete all policies within that organization.

People Admin. By default, any user entry in an newly created organization is a member of that organization. The People Administrator has read and write access to all user entries in the organization. Keep in mind that this role DOES NOT have read and write access to the attributes that contain role and group DNs therefore, they cannot modify the attributes of, or remove a user from, a role or a group.

Note –
Other containers can be configured with Access Manager to hold user entries, group entries or even other containers. To apply an Administrator role to a container created after the organization has already been configured, the Container Admin Role or Container Help Desk Admin defaults would be used.

Group Admin. The Group Administrator created when a group is created has read and write access to all members of a specific group, and can create new users, assign users to the groups they manage, and delete the users the that they have created.

When a group is created, the Group Administrator role is automatically generated with the necessary privileges to manage the group. The role is not automatically assigned to a group member. It must be assigned by the group’s creator, or anyone that has access to the Group Administrator Role.

Top-level Admin. The Top-level Administrator has read and write access to all entries in the top-level organization. In other words, this Top-level Admin role has privileges for every configuration principal within the Access Manager application.

Organization Admin. The Organization Administrator has read and write access to all entries in an organization. When an organization is created, the Organization Admin role is automatically generated with the necessary privileges to manage the organization.

Click the New Dynamic button.

Enter a name for the role.

Enter a description for the role.

Choose the role type from the Type menu.

The role can be either an Administrative role or a Service role. The role type is used by the console to determine and where to start the user in the Access Manager console. An administrative role notifies the console that the possessor of the role has administrative privileges; the service role notifies the console that the possessor is an end user.

Choose a default set of permissions to apply to the role from the Access Permission menu. The permissions provide access to entries within the organization. The default permissions shown are in no particular order. The permissions are:

No permissions

No permissions are to be set on the role.

Organization Admin

The Organization Administrator has read and write access to all entries in the configured organization.

Organization Help Desk Admin

The Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute.

Organization Policy Admin

The Organization Policy Administrator has read and write access to all policies in the organization. The Organization Policy Administrator can not create a referral policy to a peer organization.

Generally, the No Permissions ACI is assigned to Service roles, while Administrative roles are assigned any of the default ACIs.

Enter the information for the search criteria. The fields are:

Match

Allows you to include an operator for any the fields you wish to include for the filter. ALL returns users for all specified fields. ANY returns users for any one of the specified fields.

First Name

Search for users by their first name.

User ID

Search for a user by User ID.

Last Name

Search for users by their last name.

Full Name

Search for users by their full name.

User Status

Search for users by their status (active or inactive)

Click OK to initiate the search based on the filter criteria. The users defined by the filter criteria are automatically assigned to the role.

To Remove Users from a Role

Navigate to the Organization that contains the role to modify.

Choose Organizations from the View menu in the Identity Management module and select the Roles tab.

Select the role to modify.

Choose Users from the View menu.

Select the checkbox next to each user to be removed.

Click Remove user from the Select Action menu.

The users are now removed from the role.

To Add a Role to a Policy

Access Manager objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Managing Policies.

Chapter 8 Current Sessions

This chapter describes the session management features of Access Manager. The Session Management module provides a solution for viewing user session information and managing user sessions. It keeps track of various session times as well as allowing the administrator to terminate a session. System administrators should ignore the Load Balancer servers listed in the Platform Server list.

The Current Sessions Interface

The Current Sessions module interface allows an administrator, with the appropriate permissions, to view the session information for any user who is currently logged in to Access Manager.

Session Management

The Session Management frame displays the name of the Access Manager that is currently being managed.

Session Information

The Session Information window displays all of the users who are currently logged into Access Manager, and displays the session time for each user. The display fields are:

User ID. Displays the user ID of the user who is currently logged in.

Time Left. Displays the amount of time (in minutes) remaining that the user has for that session before having to re-authenticate.

Max Session Time. Displays the maximum time (in minutes) that the user can be logged in before the session expires and must re-authenticate to regain access.

Idle Time. Displays the time (in minutes) that the user has been idle.

Max Idle Time. Displays the maximum time (in minutes) that a user can remain idle before having to re-authenticate.

The time limits are defined by the administrator in the Session Management Service.

You can display a specific user session, or a specific range of user sessions, by entering a string in the User ID field and clicking Filter. Wildcards are permitted.

Clicking the Refresh button will update the user session display.

Terminating a Session

Administrators with appropriate permissions can terminate a user session at any time.

To Terminate a Session

Select the user session that you wish to terminate.

Click Terminate.

Chapter 9 Password Reset Service

Access Manager provides a Password Reset service to allow users to reset their password for access to a given service or application protected by Access Manager. The Password Reset service attributes, defined by the top-level administrator, control user validation credentials (in the form of secret questions), control the mechanism for new or existing password notification, and sets possible lockout intervals for incorrect user validation.

This chapter contains the following sections:

Registering the Password Reset Service

The Password Reset service does not need to be registered for the realm in which the user resides. If the Password Reset service does not exist in the organization in which the user resides, it will inherit the values defined for the service in Service Configuration.

To Register Password Reset for Users in a Different Realm

Navigate to the realm to which you will register the password for the user.

Click the realm name and click the Services tab.

If it has not been added to the realm, click the Add button.

Select the r Password Reset and click Next

The Password Reset service attributes will be displayed. For attribute definitions, see the online help.

Click Finish.

Configuring the Password Reset Service

Once the Password Reset service has been registered, the service must be configured by a user with administrator privileges.

To Configure the Service

Select the realm for which the Password Reset service is registered.

Click the Services tab.

Click Password Reset from the services list.

The Password Reset attributes appear, allowing you to define requirements for the Password Reset service. Make sure that the Password Reset service is enabled (it is by default). At a minimum, the following attributes must be defined:
- User Validation
  - Secret Question
  - Bind DN
  - Bind Password
    
    The Bind DN attribute must contain a user with privileges for resetting the password (for example, Help Desk Administrator). Due a limitation in Directory Server, Password Reset does not work when the bind DN is cn=Directory Manager.
    
    The remaining attributes are optional. See the online help for a description of the service attributes.
  Note –
  Access Manager automatically installs the Password Reset web application for random password generation. However, you can write your own plug-in classes for password generation and password notification. See the following Readme.html files in the following locations for samples for these plug-in classes.
  
  PasswordGenerator:
  AccessManager-base/SUNWam/samples/console/PasswordGenerator
  NotifyPassword:
  AccessManager-base/SUNWam/samples/console/NotifyPassword

Select the Personal Question Enabled attribute if the user is to define his/her unique personal questions. Once the attributes are defined, click Save.

To Localize the Secret Question

If you are running a localized version of the Access Manager, and wish to display the secret question in a character set specific to you locale, perform the following:

Add the secret question key to the Current Values list under the Secret Question attribute in the Password Reset service. For example, favorite-color.

Add the key to the amPasswordReset.properties file with the question that you want to displays the value of this key. For example:

favorite-color=What is your favorite color?

Add the same key with the localized question to AMPasswordReset_locale.properties located in /opt/SUNWam/locale. When the user attempts to changes his or her password, the localized question is displayed.

Password Reset Lockout

The Password Reset service contains a lockout feature that will restrict users to a certain number of attempts to correctly answer their secret questions. The lockout feature is configured through the Password Reset service attributes. See the online help for a description of the service attributes. Password Reset supports two types of lockout, memory lockout and physical lockout.

Memory Lockout

This is a temporary lockout and is in effect only when the value in the Password Reset Failure Lockout Duration attribute is greater than zero and the Enable Password Reset Failure Lockout attribute is enabled. This lockout will prevent users from resetting their password through the Password Reset web application. The lockout lasts for the duration specified in Password Reset Failure Lockout Duration, or until the server is restarted. See the online help for a description of the service attributes.

Physical Lockout

This is a more permanent lockout. If the value set in the Password Reset Failure Lockout Count attribute is set to 0 and the Enable Password Reset Failure Lockout attribute is enabled, the users’ account status is changed to inactive when he or she incorrectly answers the secret questions. See the online help for a description of the service attributes.

Password Reset for End Users

The following sections describe the user experience for the Password Reset service.

Customizing Password Reset

Once the Password Reset service has been enabled and the attributes defined by the administrator, users are able to log into the Access Manager console in order to customize their secret questions.

To Customize Password Reset

The user logs into the Access Manager console, providing Username and Password and is successfully authenticated.

In the User Profile page, the user selects Password Reset Options. This displays the Available Questions Answer Screen.

The user is presented with the available questions that the administrator defined for the service, such as:
- What is your pet’s name?
  - What is your favorite TV show?
  - What is your mother’s maiden name?
  - What is your favorite restaurant?

The user selects the secret questions, up to the maximum number of questions that the administrator defined for the realm (the maximum amount is defined the Password Reset Service). The user then provides answers to the selected questions. These questions and answers will be the basis for resetting the user’s password (see the following section). If the administrator has selected the Personal Question Enabled attribute, text fields are provided, allowing the user to enter a unique secret question and provide an answer.

The user clicks Save.

Resetting Forgotten Passwords

In the case where users forget their password, Access Manager uses the Password Reset web application to randomly generate new passwords and notify the user of the new password. A typical forgotten password scenario follows:

To Reset Forgotten Passwords

The user logs into the Password Reset web application from a URL given to them by the administrator. For example:

http://hostname:port /ampassword (for the default realm

or

http://hostname: port/deploy_uri /UI/PWResetUserValidation?realm=realmname, where realmname is the name of the realm.

Note –
If the Password Reset service is not enabled for a parent realm but is enabled for a sub-realm, users must use the following syntax to access the service:
http://hostname: port/deploy_uri/UI/PWResetUserValidation?realm=realmname

The user enters the user id.

The user is presented with the personal questions that were defined in the Password Reset service and select by the user during customization. If the user has not previously logged into the User Profile page and customized the personal questions, the password will not be generated.

Once the user answers the questions correctly, the new password is generated and emailed to the user. Attempt notification is sent to the user whether the questions are answered correctly or not. Users must have their email address entered in the User Profile page in order for the new password and attempt notification to be received.

Password Policies

A password policy is a set of rules to govern how passwords are used in a given directory. Password policies are defined in the Directory Server, typically through the Directory Server console. A secure password policy minimizes the risks associated with easily-guessed passwords by enforcing the following:

Users must change their passwords according to a schedule.
Users must provide non-trivial passwords.
Accounts may be locked after a number of binds with the wrong password.

Directory Server provides several ways to set password policy at any node in a tree and there are several ways to set the policy. For details refer to

Directory Server Password Policy in the Directory Server Enterprise Edition 6.0 Administration Guide.

Note –

In Directory Server, the password policy contains an attribute, passwordExp, that defines whether user passwords will expire after a given number of seconds. If the administrator sets the passwordExp attribute to on, this sets the expiration for the end-user's password as well as the Access Manager's administration accounts, such as amldap, dsame, and puser. When the Access Manager administrator's account password expires, and an end-user is logged in, the user will receive the password change screen. However, Access Manager does not specify the user to which the password change screen pertains. In this case, the screen is intended for the administrator and the end-user will be unable to change the password.

To resolve this, the administrator must log in to the Directory Server and change the amldap, dsame, and puser passwords, or change the passwordExpirationTime attribute for some time in the future.

Chapter 10 Logging Service

Sun Java™ System Access Manager provides a Logging Service to record information such as user activity, traffic patterns, and authorization violations. In addition, the debug files allow administrators to troubleshoot their installation.

Log Files

The log files record a number of events for each of the services it monitors. These files should be checked by the administrator on a regular basis. The default directory for the log files is /var/opt/SUNWam/logs for SPARC systems, /var/opt/sun/identity for Linux systems, /var/opt/sun/identity for HP-UX, and jes-install-dir\identity for Windows. The log file directory can be configured in the Logging Service by using the Access Manager console.

See Logging Overview in Sun Java System Access Manager 7.1 Technical Overview in the Sun Java System Access Manager Technical Overview for a detailed list of the default log file types, the information that is recorded, and log file formats.

For attribute definitions for the Logging Service, see the online help by clicking the Help button in the Access Manager Console.

Access Manager Service Logs

There are two different types of service log files: access and error. Access log files may contain records of action attempts and successful results. Error log files record errors that occur within the Access Manager services. Flat log files are appended with the .error or .access extension. Database column names end with _ERROR or _ACCESS for Oracle databases, or _error or _access for MySQL databases. For example, a flat file logging console events is named amConsole.access, while a database column logging the same events is named AMCONSOLE_ACCESS. The following sections describe the log files recorded by the Logging Service.

Session Logs

The Logging Service records the following events for the Session Service:

Login
Logout
Session Idle TimeOut
Session Max TimeOut
Failed To Login
Session Reactivation
Session Destroy

The session logs are prefixed with amSSO.

Console Logs

The Access Manager console logs record the creation, deletion and modification of identity-related objects, policies and services including, among others, organizations, organizational units, users, roles, policies and groups. It also records modifications of user attributes including passwords and the addition or removal of users to or from roles and groups. Additionally, the console logs write delegation and data store activities. The console logs are prefixed with amConsole.

Authentication Logs

Authentication component logs user logins and logouts. The authentication logs are prefixed with amAuthentication.

Federation Logs

The Federation component logs federation-related events including, but not limited to, the creation of an Authentication Domain and the creation of a Hosted Provider. The federation logs are prefixed with amFederation.

Policy Logs

The Policy component records policy-related events including, but not limited to, policy administration (policy creation, deletion and modification) and policy evaluation. The policy logs are prefixed with amPolicy.

Agent Logs

The policy agent logs are responsible for logging exceptions regarding log resources that were either allowed or denied to a user. The agent logs are prefixed with amAgent. amAgent logs reside on the agent server only. Agent events are logged on the Access Manager server in the Authentication Logs. For more information on this function, see the documentation for the policy agent in question.

SAML Logs

The SAML component records SAML-related events including, but not limited to, assertion and artifact creation or removal, response and request details, and SOAP errors. The session logs are prefixed with amSAML.

amadmin Logs

The command line logs record event errors that occur during operations using the command line tools. These include, but are not limited to, loading a service schema, creating policy and deleting users. The command line logs are prefixed with amAdmin. the amadmin.access and amadmin.error log files reside in a subdirectory of the main logging directory. By default, the amadmin command line tool log files reside in /var/opt/SUNWam/logs.

Logging Features

The Logging Service has a number of special features which can be enabled for additional functionality. They include To Enable Secure Logging, Command Line Logging and Remote Logging.

Secure Logging

This optional feature adds additional security to the logging function. Secure Logging enables detection of unauthorized changes to, or tampering of, the security logs. No special coding is required to leverage this feature. Secure Logging is accomplished by using a pre-registered certificate configured by the system administrator. This Manifest Analysis and Certification (MAC) is generated and stored for every log record. A special "signature" log record is periodically inserted that represents the signature for the contents of the log written to that point. The combination of the two records ensures that the logs have not been tampered with. There are to methods to enable secure logging; through a Java Security Server (JSS) provider and through a Java Cryptography Extension (JCE) provider.

To Enable Secure Logging through a JSS Provider

Create a certificate with the name Logger and install it in the deployment container running Access Manager.

For instructions for Application Server, see Working with Certificates and SSL in Sun Java System Application Server Enterprise Edition 8.2 Administration Guide in the Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

For instructions for Web Server, see Managing Certificates in Sun Java System Web Server 7.0 Administrator’s Guide in the Sun Java System Web Server 7.0 Administration Guide.

Turn on Secure Logging in the Logging Service configuration using the Access Manager console and save the change. The administrator can also modify the default values for the other attributes in the Logging Service.

If the logging directory is changed from the default (/var/opt/SUNWam/logs), make sure that the permissions are set to 0700. The logging service will create the directory, if it does not exist, but it will create the directory with permissions set to 0755.

Additionally, if you specify a different directory from the default, you must change the following parameter to the new directory in the web container's server.policy file:

permission java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”

Create a file in the AccessManager-base/SUNWam/config directory that contains the certificate database password and name it .wtpass.

Note –
The file name and the path to it is configurable in the AMConfig.properties file. For more information see the "Certificate Database" in AMConfig.properties file reference chapter in the Access Manager Administration Reference.

Ensure that the deployment container user is the only administrator with read permissions to this file for security reasons.

Restart the server.

The secure log directory should be cleared, as some misleading verification errors may be written to the /var/opt/SUNWam/debug/amLog file when the secure logging was started.

To detect unauthorized changes or tampering of the security logs, look for error messages that are written by the verification process to /var/opt/SUNWam/debug/amLog. To manually check for tampering, run the VerifyArchive utility. See The VerifyArchive command line chapter in the Access Manager Administration Reference for more information.

To Enable Secure Logging Through a JCE Provider

Create a certificate named Logger with Java keytool command and install it in JKS keystore. For example:

JAVA-HOME/jre/lib/security/Logger.jks

For instructions for Application Server, see Working with Certificates and SSL in Sun Java System Application Server Enterprise Edition 8.2 Administration Guide in the Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

For instructions for Web Server, see Managing Certificates in Sun Java System Web Server 7.0 Administrator’s Guide in the Sun Java System Web Server 7.0 Administration Guide.

Turn on Secure Logging in the Logging Service configuration using the Access Manager console and save the change. The administrator can also modify the default values for the other attributes in the Logging Service.

If the logging directory is changed from the default (/var/opt/SUNWam/logs), make sure that the permissions are set to 0700. The logging service will create the directory, if it does not exist, but it will create the directory with permissions set to 0755.

Additionally, if you specify a different directory from the default, you must change the following parameter to the new directory in the web container's server.policy file:

permission java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”

Create a file in the AccessManager-base/SUNWam/config directory that contains the JKS keystore password and name it .wtpass.

Note –
The file name and the path to it is configurable in the AMConfig.properties file. For more information see the "Certificate Database" in the AMConfig.properties file reference chapter in the Access Manager Administration Reference.

Ensure that the deployment container user is the only administrator with read permissions to this file for security reasons.

Edit the following entries in the amLogging.xml, located in the AccessManager-base/config/xml directory:

sun-am-logging-secure-log-helper

                <AttributeSchema name="iplanet-am-logging-secure-log-helper"
                    type="single"
                    syntax="string"
                    i18nKey="">
                    <DefaultValues>
                        <Value>com.sun.identity.log.secure.impl.SecureLogHelperJCEImpl</Value>
                    </DefaultValues>
                </AttributeSchema>

 sun-am-logging-secure-certificate-store

                <AttributeSchema name="iplanet-am-logging-secure-certificate-store"
                    type="single"
                    syntax="string"
                    i18nKey="">
                    <DefaultValues>
                        <Value>/dir-to-signing-cert-store/Logger.jks</Value>
                    </DefaultValues>
                </AttributeSchema>

Delete the existing service schema, iPlanetAMLoggingService. For example:

./amadmin -u amadmin -w netscape -r iPlanetAMLoggingService

Load the edited amLoging.xml to Access Manager using the amadmin command line tool. For example:

./amadmin -u amadmin -w netscape -s /etc/opt/SUNWam/config/xml/amLogging.xml

Restart the server.

To detect unauthorized changes or tampering of the security logs, look for error messages that are written by the verification process to /var/opt/SUNWam/debug/amLog. To manually check for tampering, run the VerifyArchive utility. See The VerifyArchive command line chapter in the Access Manager Administration Reference for more information.

Command Line Logging

The amadmin command line tool has the ability to create, modify and delete identity objects (organizations, users, and roles, for example) in Directory Server. This tool can also load, create, and register service templates. The Logging Service can record these actions by invoking the -t option. If the com.iplanet.am.logstatus property in AMConfig.properties is enabled (ACTIVE) then a log record will be created. (This property is enabled by default.) The command line logs are prefixed with amAdmin. See “The amadmin Command Line Tool” in the Access Manager Administration Reference for more information.

Logging Properties

There are properties in the AMConfig.properties file that affect logging output:

com.iplanet.am.logstatus=ACTIVE: This property will enable or disable logging. The default is ACTIVE.
iplanet-am-logging.service.level= level: service is the service's normal log file name. For example, to specify a logging level for amSAML.access, use the property iplanet-am-logging.amSAML.access.level.level is one of the java.util.logging.Level values and denotes the level of detail recorded in the log file. The levels are OFF, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, and ALL. Most services do not record log levels with higher detail than INFO.

Remote Logging

Access Manager supports remote logging. This allows a client application using a host where the Access Manager server is installed to create log records on an instance of Access Manager deployed on a remote machine. Remote logging can be initiated in any of the following scenarios:

When the logging URL in the Naming Service of one Access Manager instance points to a remote instance and there is a trust relationship configured between the two, logs will be written to the remote Access Manager instance.
When the Access Manager SDK is installed against a remote Access Manager instance and a client (or a simple Java class) running on the SDK server uses the logging APIs, the logs will be written to the remote Access Manager machine.
When logging APIs are used by Access Manager agents.

To Enable Remote Logging with Web Containers

Log into the either the Application Server or Web Server's administration console and add the following JVM options:
- java.util.logging.manager=com.sun.identity.log.LogManager
- java.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties
  
  For more information on the Application Server administration console, see Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.
  
  For more information on the Web Server administration console, see Sun Java System Web Server 7.0 Administrator’s Guide.
- If the Java™ 2 Platform, Standard Edition being used is 1.4 or later, this is accomplished by invoking the following at the command line:
  
  java -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/AccessManager-base /SUNWam/lib/xercesImpl.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/jaas.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/servlet.jar:/AccessManager-base /SUNWam/locale:/AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.
  
  -Djava.util.logging.manager=com.sun.identity.log.LogManager
  
  -Djava.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties
- If the Java 2 Platform, Standard Edition being used is earlier than 1.4, this is accomplished by invoking the following at the command line:
  
  java -Xbootclasspath/a:/AccessManager-base /SUNWam/lib/jdk_logging.jar -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/AccessManager-base /SUNWam/lib/xercesImpl.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/jaas.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/servlet.jar:/AccessManager-base /SUNWam/locale:/AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.
  
  -Djava.util.logging.manager=com.sun.identity.log.LogManager
  
  -Djava.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties

Ensure that the following parameters are configured in LogConfig.properties located in AccessManager-base/SUNWam/lib :
- iplanet-am-logging-remote-handler=com.sun.identity.
  
  log.handlers.RemoteHandler
- iplanet-am-logging-remote-formatter=com.sun.
  
  identity.log.handlers.RemoteFormatter
- iplanet-am-logging-remote-buffer-size=1
  
  Remote logging supports buffering on the basis of the number of log records. This value defines the log buffer size by the number of records. Once the buffer is full, all buffered records will be flushed to the server.
- iplanet-am-logging-buffer-time-in-seconds=3600
  
  This value defines the time-out period in which to invoke the log buffer-cleaner thread.
- iplanet-am-logging-time-buffering-status=OFF
  
  This value defines whether log buffering (and the buffer-cleaner thread) is enabled. By default this feature is turned off.
  
  If timer-based buffering is enabled (iplanet-am-logging-time-buffering-status=ON), then the buffer of log records is flushed (to the AM server providing the logging service) when the number of log records reaches the value specified in iplanet-am-logging-remote-buffer-size, or when the timer expires (timeout specified in iplanet-am-logging-buffer-time-in-seconds). If the timer expires before the buffer size is reached, then the records contained in the buffer are sent. If timer-base buffering of remote logging is disabled, then the buffer size determines when the buffer gets flushed. For example, if the buffer size is 10, and the application only sends 7 records, the buffer will not get flushed, nor the log records written. If the application terminates, then the records in the buffer will get flushed.
Note –
Whenever a log file is empty, secure logging may show "verification failure." This is because when the number of created files is equal to the archive size, secure logging will archive from this set and start again. It most instances, you can ignore this error. Once the number of records is equal to the archive size, the error will not be displayed.

If using a program with the Client SDK, the following properties in the AMConfig.properties file need to be set accordingly:
- com.iplanet.am.naming.url
- com.sun.identityagents.app.username
- com.iplanet.am.service.password
- com.iplanet.am.server.protocol
- com.iplanet.am.server.host
- com.iplanet.am.server.port
Refer to the Client SDK samples README.clientsdk in the /opt/SUNWam/war directory. It details how the AMConfig.properties and the make files are generated for the /opt/SUNWam/war/clientsdk-samples directory. In turn, those files are used by the samples' makefiles' compile and run entries.

Error and Access Logs

Two types of Access Manager log files exist: access log files and error log files.

Access log files record general auditing information concerning the Access Manager deployment. A log may contain a single record for an event such as a successful authentication. A log may contain multiple records for the same event. For example, when an administrator uses the console to change an attribute value, the Logging Service logs the attempt to change in one record. Logging Service also logs the results of the execution of the change in a second record.

Error log files record errors that occur within the application. While an operation error is recorded in the error log, the operation attempt is recorded in the access log file.

Flat log files are appended with the .error or .access extension. Database table names end with _ERROR or _ACCESS. For example, a flat file logging console events is named amConsole.access while a database table logging the same events is named AMCONSOLE_ACCESS or amConsole_access.

The following table provides a brief description of the log file produced by each Access Manager component.

Table 10–1 Access Manager Component Logs


Component	Log Filename Prefix	Information Logged
Session	`amSSO`	Session management attributes values such as login time, logout time, timeout limits.
Administration Console	`amConsole`	User actions performed through the administration console such as creation, deletion and modification of identity-related objects, realms, and policies.
Authentication	`amAuthentication`	User logins and logouts.
Identity Federation	`amFederation`	Federation-related events such as the creation of an Authentication Domain and the creation of a Hosted Provider. The federation logs are prefixed with `amFederation`.
Authorization (Policy)	`amPolicy`	Policy-related events such as policy creation, deletion, or modification, and policy evaluation.
Policy Agent	`amAgent`	Exceptions regarding resources that were either accessed by a user or denied access to a user. `amAgent` logs reside on the server where the policy agent is installed. Agent events are logged on the Access Manager machine in the Authentication logs.
SAML	`amSAML`	SAML-related events such as assertion and artifact creation or removal, response and request details, and SOAP errors.
Command-line	`amAdmin`	Event errors that occur during operations using the amadmin command line tool. When flat file logging is specified, the amAdmin log files are placed in the `amadmincli` subdirectory under the main logging directory (default `/var/opt/SUNWam/logs`). Examples are: loading a service schema, creating policy, and deleting users.

See Access Manager Log File Reference in the Access Manager Administration Referencefor list and description of the Access Manager log files.

Debug Files

The debug files are not a feature of the Logging Service. They are written using different APIs which are independent of the logging APIs. Debug files are stored in /var/opt/SUNWam/debug. This location, along with the level of the debug information, is configurable in the AMConfig.properties file, located in the AccessManager-base/SUNWam/lib/ directory. For more information on the debug properties, see the AMConfig.properties file reference chapter in the Access Manager Administration Reference..

Debug Levels

There are several levels of information that can be recorded to the debug files. The debug level is set using the com.iplanet.services.debug.level property in AMConfig.properties.

Off—No debug information is recorded.
Error—This level is used for production. During production, there should be no errors in the debug files.
Warning—Currently, using this level is not recommended.
Message—This level alerts to possible issues using code tracing. Most Access Manager modules use this level to send debug messages.

Note –
Warning and Message levels should not be used in production. They cause severe performance degradation and an abundance of debug messages.

Debug Output Files

A debug file does not get created until a module writes to it. Therefore, in the default error mode no debug files may be generated. The debug files that get created on a basic login with the debug level set to message include:

amAuth
amAuthConfig
amAuthContextLocal
amAuthLDAP
amCallback
amClientDetection
amConsole
amFileLookup
amJSS
amLog
amLoginModule
amLoginViewBean
amNaming
amProfile
amSDK
amSSOProvider
amSessionEncodeURL
amThreadManager

The most often used files are the amSDK, amProfile and all files pertaining to authentication. The information captured includes the date, time and message type (Error, Warning, Message).

Using Debug Files

The debug level, by default, is set to error. The debug files might be useful to an administrator when they are:

Writing a custom authentication module.
Writing a custom application using the Access manager SDKs. The amProfile and amSDK debug files capture this information.
Troubleshooting access permissions while using the console or SDK. The amProfile and amSDK debug files also capture this information.
Troubleshooting SSL.
Troubleshooting the LDAP authentication module. The amAuthLDAP debug file captures this information.

The debug files should go hand in hand with any troubleshooting guide we might have in the future. For example when SSL fails, someone might turn on debug to message and look in the amJSS debug file for any specific certificate errors.

Chapter 11 Notification Service

Sun Java System Access Manager 7.1 Notification Service allows for session notifications to be sent to remote web containers. It is necessary to enable this service for use by SDK applications running remotely from the Access Manager server itself. This chapter explains how to enable a remote web container to receive the notifications. It contains the following sections:

Overview

The Notification Service allows for session notifications to be sent to web containers that are running the Access Manager SDK remotely. The notifications apply to the Session, Policy and Naming Services only. In addition, the remote application must be running in a web container. The purpose of the notifications would be:

To sync up the client side cache of the respective services.
To enable more real time updates on the clients. (Polling is used in absence of notifications.)
No client application changes are required to support notifications.

Note that the notifications can be received only if the remote SDK is installed on a web container.

Enabling The Notification Service

Following are the steps to configure the remote SSO SDK to receive session notifications.

To Receive Session Notifications

Install Access Manager on Machine 1.

Install Sun Java System Web Server on Machine 2.

Install the SUNWamsdk on the same machine as the Web Server.

For instructions on installing the Access Manager SDK remotely, see the Sun Java Enterprise System 5 Installation Guide.

Ensure that the following are true concerning the machine where the SDK is installed.

Ensure that the right access permissions are set for the / remote_SDK_server/ SUNWam/lib and / remote_SDK_server / SUNWam/locale directories on the server where the SDK is installed.

These directories contains the files and jars on the remote server.

Ensure that the following permissions are set in the Grant section of the server.policy file of the Web Server.

server.policy is in the config directory of the Web Server installation. These permissions can be copied and pasted, if necessary:

permission java.security.SecurityPermission "putProviderProperty.Mozilla-JSS"

permission java.security.SecurityPermission "insertProvider.Mozilla-JSS";

Ensure that the correct classpath is set in server.xml.

server.xml is also in the config directory of the Web Server installation. A typical classpath would be:

<JAVA javahome="/export/home/ws61/bin/https/jdk" 
serverclasspath="/export/home/ws61/bin/https/jar/webserv-rt.jar:
${java.home}/lib/tools.jar:/export/home/ws61/bin/https/jar/webserv-ext.jar:
/export/home/ws61/bin/https/jar/webserv-jstl.jar:/export/home/ws61/
	bin/https/jar/nova.jar"
classpathsuffix="::/IS_CLASSPATH_BEGIN_DELIM:
				//usr/share/lib/xalan.jar:
				//export/SUNWam/lib/xmlsec.jar:
				//usr/share/lib/xercesImpl.jar:
				//usr/share/lib/sax.jar:
				//usr/share/lib/dom.jar:
				//export/SUNWam/lib/dom4j.jar:
				//export/SUNWam/lib/jakarta-log4j-1.2.6.jar:
				//usr/share/lib/jaxm-api.jar:
				//usr/share/lib/saaj-api.jar:
				//usr/share/lib/jaxrpc-api.jar:
				//usr/share/lib/jaxrpc-impl.jar:
				//export/SUNWam/lib/jaxm-runtime.jar:
				//usr/share/lib/saaj-impl.jar:/export/SUNWam
				//lib:/export/SUNWam/locale:
				//usr/share/lib/mps/jss3.jar:
				//export/SUNWam/lib/	am_sdk.jar:
				//export/SUNWam/lib/am_services.jar:
				//export/SUNWam/lib/am_sso_provider.jar:
				//export/SUNWam/lib/swec.jar:
				//export/SUNWam/lib/acmecrypt.jar:
				//export/SUNWam/lib/iaik_ssl.jar:
				//usr/share/lib/jaxp-api.jar:
				//usr/share/lib/mail.jar:
				//usr/share/lib/activation.jar:
				//export/SUNWam/lib/servlet.jar:
				//export/SUNWam/lib/am_logging.jar:
				//usr/share/lib/commons-logging.jar:
				//IS_CLASSPATH_END_DELIM:" 
envclasspathignored="true" debug="false"
debugoptions="-Xdebug -Xrunjdwp:
transport=dt_socket,
server=y,suspend=n" 
javacoptions="-g" 
dynamicreloadinterval="2">

Use the SSO samples installed on the remote SDK server for configuration purposes.
1. Change to the / remote_SDK_server /SUNWam/samples/sso directory.
2. Run gmake.
3. Copy the generated class files from / remote_SDK_server /SUNWam/samples/sso to / remote_SDK_server /SUNWam/lib/.

Copy the encryption value of am.encryption.pwd from the AMConfig.properties file installed with Access Manager to the AMConfig.properties file on the remote server to which the SDK was installed.

The value of am.encryption.pwd is used for encrypting and decrypting passwords.

Execute the servlet by entering http:// remote_SDK_host:58080/servlet/SSOTokenSampleServlet into the browser location field and validating the SSOToken.

SSOTokenSampleServlet is used for validating a session token and adding a listener. Executing the servlet will print out the following message:

SSOToken host name: 192.18.149.33 SSOToken Principal name: uid=amAdmin,ou=People,dc=red,dc=iplanet,dc=com Authentication type used: LDAP IPAddress of the host: 192.18.149.33 The token id is AQIC5wM2LY4SfcyURnObg7vEgdkb+32T43+RZN30Req/BGE= Property: Company is - Sun Microsystems Property: Country is - USA SSO Token Validation test Succeeded

Set the property com.iplanet.am.notification.url= in AMConfig.properties of the machine where the Client SDK is installed:

com.iplanet.am.notification.url=http://clientSDK_host.domain:port
/servlet
    com.iplanet.services.comm.client.PLLNotificationServlet

Restart the Web Server.

Execute the servlet by entering http:// remote_SDK_host:58080/servlet/SSOTokenSampleServlet into the browser location field and validating the SSOToken again.

When the machine on which the remote SDK is running receives the notification, it will call the respective listener when the session state is changed. Note that the notifications can be received only if the remote SDK is installed on a web container.

To Enable the Notification Service with a Portal-only Installation

This section describes the steps to enable notification with WebLogic 8.1 in a Portal-only installation, which by default runs in polling mode. For Portal instances that also contain the amserver component, these procedures are not needed. amserver components are automatically configured to perform notification.

Register the PLLNotificationServlet in WebLogic.

WebLogic 8.1 requires that a web application be deployed. Also, the servlet URL must be valid so that when accessed from a browser, the following message is returned:
Webtop 2.5 Platform Low Level notification servlet

Enter the registered URL into AMConfig.properties as follows:

com.iplanet.am.notifaction.url=http://weblogic_instance-host.domain:port/notification/PLLNotificationServlet

Disable polling in AMConfig.properties. This automatically enables notification:

com.iplanet.am.session.client.polling.enable=false

Restart WebLogic and test the configuration.

If you have set the debug mode to message, you should see session notification arriving at the portal when triggered. For example, a action such as the termination of a user from the Access Manager console will cause a notification event.

Anterior: Access Control