Before you begin
Before you perform this task,When a user ID and password is assigned to a RunAs role, validation occurs using the current active user registry that is configured. By default, the local OS user registry is set as the active user registry. Therefore, when an application is installed and security is disabled on the server, the local OS user registry is used to validate the user ID and password that is assigned to the RunAs Role. If the intended user registry for the application is not local OS, the validation fails. Therefore, map RunAs roles to users when the security is enabled on the server. However, if the active user registry and the intended user registry after enabling security are the same, you can assign the user to a RunAs role when security is disabled.
If the special subjects "Everyone" or "All Authenticated" are assigned to a role, then validation does not take place for that role.
The validation is done every time Apply in this panel is clicked or when OK is clicked in the Map security roles to users and groups panel. The check verifies that all the users in all the RunAs roles do exist directly or indirectly (through a group) in those roles in the Map security roles to users and groups panel. If a role is assigned both a user and a group to which that user belongs, then either the user or the group (not both) can be deleted from Map security roles to users and groups panel.
If
the RunAs role user belongs to a group and if that group is assigned to that
role, make sure that the assignment of this group to the role is done through
administrative console and not through the Application Assembly Tool (AAT)
or any other method. When using the administrative console, the full name
of the group is used (for example, hostname\groupName in windows
systems, and distinguished names (DN) in Lightweight Directory Access Protocol
(LDAP)). During the check, all the groups to which the RunAs role user belongs
are obtained from the registry. Since the list of groups obtained from the
registry are the full names of the groups, the check works correctly. If the
short name of a group is entered using the AAT (for example, group1 instead
of CN=group1, o=myCompany.com) then this check fails.
If
the RunAs role user belongs to a group and if that group is assigned to that
role, make sure that the assignment of this group to the role is done through
administrative console and not through the Assembly Toolkit or any other method.
When using the administrative console, the full name of the group is used
(for example, hostname\groupName in windows systems, and distinguished
names (DN) in Lightweight Directory Access Protocol (LDAP)). During the check,
all the groups to which the RunAs role user belongs are obtained from the
registry. Since the list of groups obtained from the registry are the full
names of the groups, the check works correctly. If the short name of a group
is entered using the Assembly Toolkit (for example, group1 instead
of CN=group1, o=myCompany.com) then this check fails.
Why and when to perform this task
These steps are common to both installing an application and modifying an existing application. If the application contains RunAs roles, you see the Map RunAs roles to users link during application installation and also during managing applications as a link in the Additional Properties section at the bottom.
Steps for this task
Results
The RunAs role user is added to the binding file in the application. This file is used for delegation purposes when accessing J2EE resources.Example
What to do next
If you are installing the application, complete installation. Once the application is installed and running you can access your resources according to the RunAS role mapping. Save the configuration.If you are managing applications and have modified the RunAs roles to users mapping, make sure you save, stop and restart the application so that the changes become effective. Try accessing your J2EE resources to verify that the new changes are in effect.