Providing security

Virtual member manager provides role based security for both changing the configuration and using the runtime APIs.

Configuration security

The virtual member manager configuration can be changed from the WebSphere Administrative Console, the wsadmin commands, and scripting. Only a user assigned the WebSphere Application Server Administrator role can change the configuration from the console or by using the commands. The wsadmin commands can also be used in local mode during WebSphere Application Server installation.

Runtime security

During runtime operations, by default, virtual member manager supports only two roles:

WebSphere Application Server Administrator

A user who authenticates as the WebSphere Application Server Administrator, may perform any virtual member manager function against any virtual member manager object.

Account Owner role

The Account Owner role is virtual member manager specific and not a J2EE role. If the authenticated user is the owner of the registry object, the user is programmatically assigned the Account Owner role. The authenticated user can change its own password and search on itself only. The user is not authorized to make any other modifications, nor can the user search, view, create, or delete any objects in the repositories.

Account-Owner-Role
	SEARCH Entity/RolePlayer/Party/LoginAccount/*
	UPDATE Entity/RolePlayer/Party/LoginAccount/*
	WRITE Entity/RolePlayer/Party/LoginAccount/* sensitive
	READ Entity/RolePlayer/Party/LoginAccount/* unchecked
	WRITE Entity/RolePlayer/Party/LoginAccount/* unchecked

All Authenticated Users
	Account-Owner-Role {Condition: OWNERSHIP == true}

The virtual member manager runtime API that WebSphere Application Server needs for authentication, does not have any access control applied. The effect is twofold:

Prevents circular dependencies between WebSphere Application Server security and virtual member manager during authentication to WebSphere Application Server
Provides quick authentications

Mapping users and groups to roles for assigning federated repository management rights

If you want to enable users who are not assigned the WebSphere Application Server Administrator role to access virtual member manager methods, you can assign the user or group one of the following predefined virtual member manager roles.

The predefined virtual member manager roles and their corresponding permissions are listed in the following table:

Table 1. Predefined virtual member manager roles and permissions
Role name	Method permission
IdMgrAdmin (same authority as WAS Administrator)	create update delete search get createSchema getSchema
IdMgrWriter	create update delete search get
IdMgrReader	search get

You can map a user or a group to only one role. You can also map all logged-in users to a specific role, using a special subject with the value ALLAUTHENTICATED instead of the group ID. In case multiple roles are granted to a user through group membership, there is no specific order of precedence in which the roles are applied. However, as each role is a subset or superset of the other, there are no conflicting roles. For example, IdMgrWriter has IdMgrReader and IdMgrWriter permissions, and IdMgrAdmin has IdMgrReader, IdMgrWriter, and IdMgrAdmin permissions.

The following limitations apply:

The permissions assigned to each role are hardcoded; you cannot modify or customize them.
The group level access check of an attribute is not enforced.
According to the role assigned to them, users are granted all the relevant permissions on all attributes and attribute groups.

For information on how to assign users or groups to the predefined virtual member manager roles, read about the mapIdMgrUserToRole, mapIdMgrGroupToRole, removeIdMgrUsersFromRole, removeIdMgrGroupsFromRole, listIdMgrUsersForRoles, and listIdMgrGroupsForRoles commands in the topic, IdMgrConfig command group for the AdminTask object in the WebSphere Application Server documentation.

Note:

If you are adding permissions for an LDAP user where the LDAP type is defined as Custom and the external ID is not customized (the external ID used for Custom LDAP types is the Distinguished Name), either use the short user name when adding the roles to the user (janeDoe versus cn=JaneDoe,o=ibm) or enable the custom property, returnUniqueNameInNormalCaseIfExtIdMapToDN, using the wsadmin command, setIdMgrCustomProperty. Or set the external ID to a UUID appropriate for your LDAP server. For example, AdminTask.addIdMgrLDAPExternalIdAttr ('[-id myLDAP-name ibm-entryUUID]').