Configuring access to WebSphere Service Registry and Repository for users and groups defined in an LDAP user registry

Examples in this article show you how to configure access and manage security for WebSphere Service Registry and Repository, for users and groups defined in an external Lightweight Directory Access Protocol (LDAP) user registry. This approach lets you add or remove users from the external provider groups without any additional work within WSRR. The article also shows how WSRR J2EE roles can help you manage access control.

Share:

Introduction

JKHL Enterprises (hereafter called JKHLE) is a fictitious company that wants to configure access to IBM® WebSphere® Service Registry and Repository (hereafter called WSRR) using its external LDAP user registry. JKHLE is using the WebSphere Application Server federated repository option and with security enabled. It is also using the WSRR Governance Enablement Profile (hereafter called the GEP). The six JKHLE objectives for this project are listed here, and the solutions for them are described in sections 1-6 below:

  1. Identify and define groups in LDAP that will be granted access to WSRR.
  2. Prevent WSRR users from administering WebSphere Application Server.
  3. Enable users to access WSRR even if LDAP is not available.
  4. Limit access to the WSRR Web UI to WSRR groups.
  5. Limit access to Business Space to WSRR groups, and limit the ability to create spaces and update Business Space widgets in WSRR to users with a Business Space superuser role.
  6. JKHLE has developed a WSRR client using the EJB API, and it needs to prevent users who can run this WSRR client from logging into Business Space and the WSRR Web UI.

JKHLE runtime environment

  • WSRR V8.0 in a standalone configuration using DB2 V9.7 Enterprise Server Edition with Fix Pack 4.
  • WebSphere Application Server V8.0 with Fix Pack 3.
  • IBM Tivoli Directory Server LDAP

While JKHLE uses WSRR V8.0, steps in this article apply to both WSRR V7.5 and V8.0.

1. Identify and define groups in LDAP that will be granted access to WSRR

The best way to manage security with LDAP is by using groups. For example, a good way to grant administrative access to WSRR is to add pre-defined groups of users from your external LDAP user registry to WSRR. Then when changes are required, LDAP administrators can simply add or remove individual users from the groups that exist in their LDAP. This procedure ensures that security maintenance carried out in LDAP does not require any additional work in either WSRR or WebSphere Application Server.

Therefore the first step is to identify the LDAP groups to use with WSRR, derived from the JKHLE requirements listed above. JKHLE uses the GEP, and in WSRR, an active GEP defines six roles:

  • Business
  • Development
  • Operations
  • SOAGovernance
  • WSRRUser
  • WSRRAdmin

For more information on GEP roles in the GEP, see Roles in the GEP. in the WSRR information center.

  • WSRR Business Space defines a superuser role with administrative privileges. For more information, see Assigning the Business Space superuser role in the WSRR information center. JKHLE wants to restrict the Business Space superuser role to a few selected users, which you can do by defining an LDAP group called WSRRBusinessSpaceSuperUsers.
  • JKHLE also wants to restrict users with the ability to run the WSRR client it created using the EJB API from logging into Business Space and the WSRR Web UI. The role associated with this activity can be called WSRRBatchUser. The WSRR group corresponding to this role will be defined in LDAP.

Roles identified above translate to specific activities in WSRR. Therefore it is logical that each of these roles will have a corresponding group defined in LDAP, and these LDAP groups will be assigned to an appropriate role in WSRR, in alignment with the activities they will perform. Table 1 below shows the WSRR groups that JKHLE defines in LDAP:

Table 1. WSRR groups to be defined in LDAP
WSRR rolesWSRR groups in LDAP
BusinessSpaceSuperUserWSRRBusinessSpaceSuperUsers
BusinessWSRRBusinessUsers
DevelopmentWSRRDevelopmentUsers
OperationsWSRROperationsUsers
SOAGovernanceWSRRSOAGovernanceUsers
WSRRAdminWSRRAdminUsers
WSRRBatchUserWSRRBatchUsers
WSRRUserWSRRUsers

At the end of Section 1, JKHLE has identified and defined WSRR groups in LDAP.

2. Prevent WSRR users from administering WebSphere Application Server

This section begins by identifying the eight predefined roles in WebSphere Application Server V8 listed below that users and groups will be mapped to:

  • Monitor
  • Configurator
  • Operator
  • Administrator
  • Iscadmins
  • Deployer
  • Auditor
  • Admin Security Manager

Table 2 below describes each of these administrative roles. For more information on these roles, see Administrative roles in the WSRR information center.

Table 2. WebSphere Application Server administrative roles
Administrative roleDescription
MonitorA user or group with the monitor role can complete the following tasks:
  • View the WebSphere Application Server configuration.
  • View the current state of the application server.
ConfiguratorA user or group in this role has the monitor privilege plus the ability to configure.
OperatorA user or group in this role has the monitor privilege plus the ability to start and stop the server and monitor the server status in the administrator console.
AdministratorA user or group in this role has both the operator and the configurator privileges, plus additional privileges that are granted for administration.
IscadminsAdministrative console users who are granted this role have administrator privileges for managing groups and users in the federated repository.
DeployerUsers in this role are granted the ability to deploy an application and configure application run-time settings.
Admin Security ManagerUsers in this role can assign users and groups to the administrative user roles and administrative group roles.
AuditorA user in this role can modify the configuration settings for security auditing subsystems. This role also includes the monitor role.

In order to restrict the WSRR users from performing WebSphere Application Server administrator activities, it is important that WSRR groups these users belong to must not be granted WebSphere Application Server's Administrator role. Groups WSRRBuinessSpaceSuperUsers and WSRRAdmins will be assigned an operator role, since users in these groups may invoke the WSRR MBean's administration operations.

The MBean operations that trigger updates in WSRR require the WebSphere Application Server Operator role or higher. For more information on these operations, open the IBM Redbook WSRR Handbook and go to pages 286-289, "WSRR MBean."

All other WSRR groups from LDAP will be assigned WebSphere Application Server's Monitor role. Table 3 below shows the mapping of WSRR groups defined in LDAP to their corresponding WebSphere Application Server administrative roles. This article assumes that WebSphere Application Server is already configured to use LDAP. For instructions on assigning WebSphere Application Server administrative roles to WSRR groups from LDAP, see Assigning users and groups to roles in the WebSphere Application Server information center.

Table 3. Mapping of WSRR groups defined in LDAP to their corresponding WebSphere Application Server administrative roles
WSRR Groups from LDAPWebSphere Application Server administrative role
WSRRBusinessSpaceSuperUsersOperator
WSRRBusinessUsersMonitor
WSRRDevelopmentUsersMonitor
WSRROperationsUsersMonitor
WSRRSOAGovernanceUsersMonitor
WSRRAdminUsersOperator
WSRRBatchUsersMonitor
WSRRUsersMonitor

Figure 1 shows the mapping of WSRR groups in LDAP to their corresponding WebSphere Application Server administrative roles:

Figure 1. Assignment of WebSphere Application Server administrative roles to WSRR groups defined in LDAP
Assignment of WebSphere Application Server administrative roles to WSRR groups defined in LDAP

At the end of Section 2, JKHLE has assigned WebSphere Application Server administrative roles to its WSRR groups defined in LDAP. In doing so, it has prevented users in these WSRR groups from being able to administer WebSphere Application Server.

3. Enable users to access WSRR if LDAP is not available

The LDAP groups for use with WSRR have been identified, defined in LDAP, and assigned administrative roles in WebSphere Application Server. However, in its current configuration, access to WSRR is dependent on LDAP availability. In order to remove this dependency, JKHLE needs to define local WSRR groups in the WebSphere Application Server internal security provider (a file-based repository), as shown below in Table 4. For information on adding groups and users to a file based repository, open the IBM Redbook WebSphere Application Server V8: Administration and Configuration Guide and go to page 251, "Assigning administrative roles to users and groups."

For instructions on assigning WebSphere Application Server administrative roles to WSRR groups defined locally in WebSphere Application Server, see Assigning users and groups to roles in the WebSphere Application Server information center. You can assign a limited number of users to these groups in order to access WSRR without LDAP.

Table 4. Mapping of WSRR groups defined locally in WebSphere Application Server to their corresponding WebSphere Application Server administrative roles
WSRR groups local to WebSphere Application ServerCorresponding WebSphere Application Server administrative role
lWSRRBusinessSpaceSuperUsersOperator
lWSRRBusinessUsersMonitor
lWSRRDevelopmentUsersMonitor
lWSRROperationsUsersMonitor
lWSRRSOAGovernanceUsersMonitor
lWSRRAdminUsersOperator
lWSRRBatchUsersMonitor
lWSRRUsersMonitor

Figure 2 below shows the mapping of WSRR groups defined locally in WebSphere Application Server to their corresponding WebSphere Application Server administrative roles.

Figure 2. Assignment of WebSphere Application Server administrative roles to WSRR groups defined in LDAP and WSRR groups defined locally in WebSphere Application Server.
Assignment of WebSphere Application Server administrative roles to WSRR groups defined in LDAP and WSRR groups defined locally in WebSphere Application Server.

At the end of Section 3, JKHLE has the ability to use WSRR even when LDAP is not available.

4. Limit access to the WSRR Web UI to WSRR groups

Access to the WSRR Web UI is controlled by mapping users and groups to the ServiceRegistry enterprise application J2EE roles. The ServiceRegistry enterprise application defines two J2EE roles that must be users or group principals:

Administrator
Only users in this role can invoke administrative MBean operations. For more information on these operations, open the IBM Redbook WSRR Handbook and go to pages 286-289, "WSRR MBean." The MBean operations that trigger updates in WSRR require the WebSphere Application Server Operator or higher role, as discussed in Section 2 above.
User
Users in this role perform non-administration operations in WSRR. All non-administrative users that require access to WSRR must be mapped to this role. Users in this role can perform necessary actions (in WSRR) in WebSphere Application Server Administrator, Operator, Configurator or Monitor roles.

For more information on these J2EE roles, see J2EE role mappings in the WSRR information center.

Begin by mapping the WSRR groups defined in LDAP (in Section 1) and WSRR groups defined in WebSphere Application Server's internal security provider (in Section 3) to the two J2EE security roles discussed above. Table 5 below shows the mapping of these WSRR groups to ServiceRegistry applications J2EE roles. For more information on accomplishing the security role to group mapping, see Security role to user or group mapping in the WebSphere Application Server information center.

Table 5. Mapping of WSRR groups to ServiceRegistry applications J2EE roles
WSRR Groups ServiceRegistry applications J2EE roles
WSRRBusinessSpaceSuperUsersAdministrator
WSRRBusinessUsersUser
WSRRDevelopmentUsersUser
WSRROperationsUsersUser
WSRRSOAGovernanceUsersUser
WSRRAdminUsersAdministrator
WSRRBatchUsersUser
WSRRUsersUser
lWSRRBusinessSpaceSuperUsersAdministrator
lWSRRBusinessUsersUser
lWSRRDevelopmentUsersUser
lWSRROperationsUsersUser
lWSRRSOAGovernanceUsersUser
lWSRRAdminUsersAdministrator
lWSRRBatchUsersUser
lWSRRUsersUser

By completing the mapping of WSRR groups to the ServiceRegistry application's J2EE roles, JKHLE achieves two objectives:

  • Users belonging to WSRR groups that have been assigned the J2EE Administrator role can log in to the WSRR Web UI and use the Configuration perspective to set up fine-grained access control. For more information on access control in WSRR, open the IBM Redbook Service Lifecycle Governance with IBM WebSphere Service Registry and Repository and go to section 7.3.3, "Fine-grained access control."
  • Users belonging to other (non-administrative) WSRR groups that have been assigned a J2EE user role are now visible in the WSRR Web UI Configuration perspective for assignment to GEP roles. Table 6 below shows the mapping of WSRR groups to GEP roles. For instructions on assigning groups to access control roles, see Add or remove principals for a role in the WSRR information center.
Table 6. Mapping of WSRR groups to WSRR GEP roles
WSRR Groups WSRR GEP Roles
WSRRBusinessSpaceSuperUsersWSRRAdmin
WSRRBusinessUsersBusiness
WSRRDevelopersDevelopment
WSRROperationsOperations
WSRRSOAGovernanceUsersSOAGovernance
WSRRAdminUsersAdministrator
WSRRBatchUsersDiscussed in Section 6 below.
WSRRUsersWSRRUser
lWSRRBusinessSpaceSuperUsersWSRRAdmin
lWSRRBusinessUsersBusiness
lWSRRDevelopersDevelopment
lWSRROperationsOperations
lWSRRSOAGovernanceUsersSOAGovernance
lWSRRAdminUsersWSRRAdmin
lWSRRBatchUsersDiscussed in Section 6 below.
lWSRRUsersWSRRUser

Mapping the WSRR groups to the ServiceRegistry application's J2EE roles and assigning them GEP access control roles ensures that users of these groups can log in to the WSRR Web UI and carry out activities relevant to their GEP roles. However, in its current configuration, all users in the WebSphere Application Server federated repository who have been authenticated can access resources that are protected by these roles in WSRR, including the user's ability to log in to the WSRR Web UI. This is because the ServiceRegistry application's two J2EE roles identified above, are by default mapped to the special subject All authenticated in application's realm. JKHLE needs to restrict Web UI access to members of the WSRR groups defined in Sections 1 and 3 above. In order to restrict WSRR Web UI access to WSRR groups, you need to change the special subjects mapping of the ServiceRegistry application's J2EE roles. Here are the steps to update the user/group mapping for the ServiceRegistry enterprise application:

  1. Select Applications => Application Types => WebSphere enterprise applications and then select the ServiceRegistry application.
  2. In the right panel under Detail Properties, select Security role to user/group mapping.
  3. Remap the All authenticated in the application's realm role from the ServiceRegistry application by first removing the special subject.
  4. Select the roles User and Administrator.
  5. Click Map special subjects and select None.
  6. Restart the server.

Figure 3 below shows the mapping of WSRR groups to the two J2EE roles associated with the ServiceRegistry application. It also shows the configuration of special subjects to None. In the figure, the Mapped user lWSRRAdminUser represents a user with the RunAs role. For more information, open the IBM Redbook Service Lifecycle Governance with WSRR and go to "WSRR Administrative RunAs role" on pages 268-269. Section 5 below discusses the assignment of J2EE administrator role to groups' lWSRRBusinessSpaceSuperUsers and WSRRBusinessSpaceSuperUsers.

Figure 3. Mapping of WSRR groups to J2EE roles associated with ServiceRegistry application.
Mapping of WSRR groups to J2EE roles associated with ServiceRegistry application.

At the end of Section 4, JKHLE has restricted WSRR Web UI access to WSRR related groups defined in LDAP and WSRR groups defined in WebSphere Application Server's internal security provider.

5. Limit access to Business Space to WSRR groups, and limit ability to create spaces and update Business Space widgets in WSRR to superusers

Access to Business Space in WSRR is controlled by mapping users and groups to the J2EE role mm.was_node_server (mm.was_cluster in a Network Deployment environment) in the ServiceRegistry enterprise application. mm.was_node_server defines two J2EE roles that must be users or group principals:

Admin
Only users in this role can view, edit, and delete all spaces and pages, manage and create templates, and change ownership of a space by changing the owner ID. Such users are called Business Space Superusers or Business Space Administrators.
Allauthenticated
Only users in this role can log in to Business Space.

Begin by preventing users from creating a business space. For instructions, see Preventing users from creating business spaces in the WSRR information center. Completing this step ensures that the ability to create a business space is limited to users with the Superuser role. Next, map the WSRR groups defined in LDAP (in Section 1) and WSRR groups defined in the WebSphere Application Server internal security provider (in Section 3) to mm.was_node_server , the ServiceRegistry application's two J2EE security roles described above. Table 7 below shows the mapping of these WSRR groups to the mm.was_node_server application's J2EE roles. For more information on mapping security roles to groups, see Security role to user or group mapping in the WebSphere Application Server information center.

Table 7. Mapping of WSRR groups to mm.was_node_server application's J2EE roles
WSRR Groups mm.was_node_server application's J2EE roles
WSRRBusinessSpaceSuperUsersAdmin and Allauthenticated
WSRRBusinessUsersAllauthenticated
WSRRDevelopersAllauthenticated
WSRROperationsAllauthenticated
WSRRSOAGovernanceUsersAllauthenticated
WSRRUsersAllauthenticated
lWSRRBusinessSpaceSuperUsersAdmin and Allauthenticated
lWSRRBusinessUsersAllauthenticated
lWSRRDevelopersAllauthenticated
lWSRROperationsAllauthenticated
lWSRRSOAGovernanceUsersAllauthenticated
lWSRRUsersAllauthenticated

Completing the mapping of WSRR groups to the mm.was_node_server application's J2EE roles achieves two objectives:

  • Users belonging to groups that have been assigned the J2EE Admin and Allauthenticated roles can log in to Business Space as a Superuser. With Superuser access, these users can create new spaces in Business Space.
  • Users belonging to other (non-administrative) WSRR groups that have been assigned the J2EE Allauthenticated role can log in to Business Space.

Note that WSRRAdminUsers and lWSRRAdminUsers groups have not been mapped to the mm.was_node_server application's J2EE roles. Thus JKHLE may be able to achieve isolation between Business Space administrators and Web UI administrators by assigning a separate set of users to these groups. The next step is to map the WSRR groups to the following J2EE roles, in order to ensure that these WSRR groups can carry out activities relevant to their GEP roles in Business Space:

  • BSpaceEAR_node_server (BSpaceEAR_cluster in a Network Deployment environment) enterprise application's J2EE role businessspaceusers.
  • BSpaceForms_node_server (BSpaceForms_cluster in a Network Deployment environment) enterprise application's J2EE role WebFormUsers.

Mapping the WSRR groups to the mm.was_node_server application's J2EE roles and assigning them GEP access control roles (in Section 4) ensures that users in these groups can log in to Business Space and carry out activities relevant to their GEP roles in Business Space. However, in its current configuration, all users in the WebSphere Application Server federated repository who have been authenticated can access resources that are protected by these roles in WSRR, including the user's ability to log in to Business Space and carry out activities associated with Superuser role in Business Space. This is because the mm.was_node_server application's two J2EE roles identified above, are by default mapped to special subject All authenticated in application's realm. JKHLE needs to restrict Business Space access to members of the WSRR groups defined in Sections 1 and 2, and therefore it is important to change the special subjects mapping of the mm.was_node_server application's J2EE roles. Here are the steps to update the user/group mapping for the mm.was_node_server enterprise application:

  1. Select Applications => Application Types => WebSphere enterprise applications and select the mm.was_node_server application.
  2. In the right panel under Detail Properties, select Security role to user/group mapping.
  3. Remap the All authenticated in the application's realm role from the mm.was_node_server application by first removing the special subject.
  4. Select the roles Allauthenticated and Administrator.
  5. Click Map Special Subjects and select None.
  6. Restart the server.

Repeat Steps 1-6 for both the BSpaceEAR_node_server and BSpaceForms_node_server enterprise applications. By setting the special subjects to None, JKHLE has restricted Business Space access to WSRR related groups defined in LDAP and WSRR groups defined in the WebSphere Application Server internal security provider. JKHLE has also ensured that the Superuser role is now restricted to users in the lWSRRBusinessSpaceSuperUsers and WSRRBusinessSpaceSuperUsers groups.

Figure 4 below shows the mapping of WSRR groups to the two J2EE roles associated with the mm.was_node_server application. It also shows the configuration of special subjects to None:

Figure 4. Mapping of WSRR groups to J2EE roles associated with the mm.was_node_server application.
Mapping of WSRR groups to J2EE roles associated with the mm.was_node_server application.

Figure 5 below shows the mapping of WSRR groups to the J2EE role associated with the BSpaceEAR_node_serverapplication. It also shows the configuration of special subjects to None:

Figure 5. Mapping of WSRR groups to J2EE roles associated with the BSpaceEAR_node_server application.
Mapping of WSRR groups to J2EE roles associated with the BSpaceEAR_node_server application.

Figure 6 below shows the mapping of WSRR groups to the J2EE role associated with the BSpaceForms_node_server application. It also shows the configuration of special subjects to None.

Figure 6. Mapping of WSRR groups to J2EE roles associated with the BSpaceForms_node_server application.
Mapping of WSRR groups to J2EE roles associated with the BSpaceForms_node_server application.

In Section 4, Business Space superuser groups, namely WSRRBusinessSpaceSuperUsers and lWSRRBusinessSpaceSuperUsers, have been assigned the ServiceRegistry application's J2EE Administrator role. Granting this J2EE role ensures that users in these groups can retrieve Business Space configuration settings (which are required to edit a newly created space) and can update Business Space widgets. For more information on Business Space configuration settings, open the IBM Redpaper Customization and Deployment of WebSphere Service Registry and Repository Business Space Widgets and go to "WSRR Business Space Configuration Settings" on pages 15-16.

At the end of Section 5, JKHLE has limited Business Space access to WSRR groups and ensured that the ability to create new spaces and update Business Space widgets is restricted to the Business Space Superuser role.

6. Prevent users who can run the WSRR client from logging into Business Space and the WSRR Web UI

Begin by creating the new role WSRRBatchUser in WSRR using the Web UI. For more information on creating a new role, see Role details in the WSRR information center. Add appropriate permissions to this role by following the instructions in Adding permissions to roles. The permissions granted to this role must align with the intended use of the WSRR client.

In Section 4, the WSRR groups WSRRBatchUsers and lWSRRBatchUsers have been assigned the ServiceRegistry application's J2EE User role, to ensure that both WSRRBatchUsers and lWSRRBatchUsers are available in the Web UI for fine-grained access control. Next, associate both of these groups with the WSRRBatchUser role in the Web UI. For more information on adding groups to roles, see Add and remove principals for a role. JKHLE can now configure its WSRR client for use with members of these groups.

However, any attempts by these users to log into the WSRR Web UI will be met with the message There are no perspectives defined for the specified user. Please contact your system administrator.. This message indicates that the newly created role WSRRBatchUser is not permitted to view any of the perspectives defined in the WSRR Web UI, thereby preventing the users of this role from successfully logging in to the WSRR Web UI. For more information, see Role elements are optional in UI perspective definitions in the WSRR information center.

In Section 5, the groups WSRRBatchUsers and lWSRRBatchUsers were not assigned the mm.was_node_server enterprise application's Allauthenticated role, which prevents users in these groups from logging into Business Space.

At the end of Section 6, users with the ability to run the WSRR client (using the EJB API) were blocked from logging into both Business Space and the WSRR Web UI.

Conclusion

The introduction listed six objectives that JKHLE wanted to achieve by configuring access to WSRR using its external user registry LDAP. This article took an incremental approach by describing the solution to one requirement at a time, and thus helped JKHLE understand:

  • How to identify WSRR groups to be defined in LDAP based on user requirements.
  • How to assign WebSphere Application Server administrative roles to WSRR groups, and the role JKHLE plays in preventing users of these groups from administering WebSphere Application Server.
  • How to use the WebSphere Application Server internal security provider (a file-based repository) to ensure access to WSRR even when LDAP is not available.
  • The contribution of WSRR J2EE roles in establishing access control for both Business Space and the Web UI.
  • How to use WSRR roles and permissions (fine-grained access control) to prevent users of the WSRR EJB client from logging in to Business Space and the Web UI.

Acknowledgements

The author would like to thank David Seager for his thorough review of this article. David is a Software Developer on the WebSphere Service Registry and Repository Development team at the IBM Hursley Development Lab in the U.K. He has 15 years of experience in middleware development at IBM and is also an IBM developerWorks contributing author.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=863668
ArticleTitle=Configuring access to WebSphere Service Registry and Repository for users and groups defined in an LDAP user registry
publish-date=04032013