Configure the UDDI registry to use WAS security
You can configure the UDDI registry to determine whether users are allowed access to services, and to determine security of data at the transport level. Before you start this task, complete the following two steps:
- Enable WAS security (see Enabling security for all appservers). This allows the UDDI registry to exploit the WAS security features.
- Ensure that WAS is configured to use HTTPS (SSL). This allows the use of secure access with the UDDI registry. By default, WAS is configured to accept SSL requests on port 9443. To make additional SSL configuration changes, see SSL configurations for selected scopes.
Overview
The UDDI registry exploits two aspects of WebSphere Application Server security:When WAS security is enabled, the default settings in the UDDI V3 Application and Web deployment descriptors produce the following results:
- Authorization
- Authorization determines whether users are allowed access to services. WAS determines authorization by mapping users, or groups of users, to roles. UDDI makes use of two WAS special subjects: Everyone (all users are allowed access) and AllAuthenticatedUsers (only valid WAS registered users are allowed access).
- Data confidentiality
- Data confidentiality determines security at the transport level. Data confidentiality for WAS services can be either 'none' (HTTP is used as the transport protocol) or 'confidential' (requiring the use of SSL; HTTPS is used as the transport protocol).
- Publish, Custody Transfer and Security services are mapped to the AllAuthenticatedUsers special subject, and data confidentiality is enforced (HTTPS is used). Authentication uses the standard WAS security facilities and there is no separate registration function for the UDDI registry. To use publish functions, users must supply their WAS user name and password (unless you have modified the supplied publish role), and must also be registered UDDI Publishers. By registering users as UDDI Publishers, you control which users in the AllAuthenticatedUsers subject can update the UDDI registry.
- Inquiry services are mapped to the Everyone special subject, and data confidentiality is not enforced (HTTP is used). To use inquiry services, users do not need to supply a user name or password, and do not need to be registered UDDI publishers.
We recommend that you use the default settings, as described previously. However, you can change the defaults by mapping roles to different users or user groups. If you do this, turn on the Automatically register UDDI publishers property (see UDDI node settings) so that you do not need to use two mechanisms to give access to a subset of users. You can also have a role that is not mapped to any users or user groups, in which case all access to that role is disabled.
For more information about UDDI role mappings, and a list of UDDI registry services and roles, see Access control for UDDI registry interfaces.
To change the default settings, use the following steps:
Procedure
- To change the role mappings using the administrative console...
- In the navigation pane, click Applications > Enterprise Applications.
- In the content pane, click the UDDI registry application.
- Under Detail Properties click Security role to user/group mapping.
- Make any changes you require and click OK.
- To change the role mappings using the wsadmin command...
- Use the MapRolesToUsers option of the edit command of the AdminApp object to map the roles defined in the UDDI registry application to special subjects (Everyone or AllAuthenticatedUsers), to users, or to user groups. For example, the following Java command language (JACL) statement maps the V3 GUI Publish role to Everyone, and the V3 SOAP Publish role to user 'user1' and group 'group1':
$AdminApp edit $AppName {-MapRolesToUsers { {"GUI_Publish_User" Yes No "" ""} {"V3SOAP_Publish_ User_Role" No No "user1" "group1"} }}where $AppName is a variable representing the name of the UDDI registry application.For more information about using the MapRolesToUsers option, see Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands.
- To change the data confidentiality settings, refer to Configure SOAP API and GUI services for the UDDI registry.
Next topic: UDDI registry security additional considerations
Related concepts
Access control for UDDI registry interfaces
Related tasks
Configure the UDDI registry to use UDDI security
Configure SOAP API and GUI services for the UDDI registry
Configure UDDI registry security
Related Reference
Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands