How to configure Websphere Security for Multi-instances of WPS to Enable Logins by Groups
It may happen that your customer wants to install multi-instances of WPS on the same WAS. The steps to do this are listed in the official document on how to install multiple instances of WPS on the same WAS. However, by following that document, you will find that all users can log into all the instances of WPS. The steps listed in this document show you how to configure WebSphere Security so that different groups of users are restricted to login to their instance of WPS.
Before listing the steps for configuring Websphere security, here are the installer steps for the 2nd and more instances of WPS. I have listed the steps here because they are not in the original installation document.
After installing the multiple instances of WPS, here are the extra steps to take.
It is best to have a different cookie name for each instance of WPS. To do this, at the Websphere Admin Console, for each instance of WPS installed, select
WebSphere Portal Server ->WPS Servlet Engine -> Session Manager
and change the cookie name in the properties panel on the right.
Now we come to the real meat. Before we begin, I just want to state that this is just one of many ways you can partition the users. This is the one that I have tried and works. It is also the simplest in that only one LDAP is used. Please also note that this is *NOT* a secure way of authorization control (See security note at end of article). Your customer may have different requirements so use your own discretion if necessary.
Another point to note is that in this method of partitioning users, all newly created users must be assigned to the group that is allowed to log into that instance. WPS’s “User Self Registration” feature does not do this automatically. You either have to disable the “User Self Registration” or modify it so that users by default belongs to a group when they sign up.
1. Create the user group
If necessary, create the group that you want to allow log in for the WPS instance, and assigns users to it. Use the DMT to do this. The steps to do this can be found in the WPS documentation and will not be listed here.
2. Add a new Security Method Group for controlling login access
a. In AdminConsole, select Tasks->Configure Security Method Groups
b. Select “Add a new method group”
c. Enter New Method Group eg WPS1LoginMethod. Click Finish
3. Modify the Base Distinguished Name of the User Registry that WAS Security use to authenticate users. This step is needed so that WAS can detect the user groups in the next step.
a. In AdminConsole, select Tasks->Configure Global Security.
b. Click the User Registry tab. In the Base Distinguished Name field, remove the “cn=users” from the start of the entry (eg. change from “cn=users,dc=ibm,dc=com” to “dc=ibm,dc=com”)
4. Add the user group to the Security Method Group created in step 2 for the WPS instance’s Enterprise Application
a. In AdminConsole, select Tasks->Configure Security Permissions
b. Select the WPS instance’s Enterprise Application you want to configure login access. Click Next.
c. Select the Enterprise Application’s method group that you have just created eg WPS Enterprise Application 1- WPS1LoginMethod. Click Next.
d. Select Selection. Select Group in the Search For drop down
list. Enter the name of the group you want to grant log in permission and click
on Search. When the group’s name appear in the Search Results
panel, highlight it. Click Next.
e. Check that the selected group has been added to the enterprise application method group. Click Finish.
5. Add user “wpsadmin” to Security Method Group
Repeat the above step. But this time, add the “wpsadmin” user instead. This is needed so that you log in as administrator to admin the portal.
6. Configure the login page so that only the just added user group can log in.
a. In AdminConsole, select Tasks->Configure Resource Security
b. Select the myportal resource of the instance you want to grant permission eg /wps1/myportal. Note that it is not the /wps1/myportal/* resource. Click Next.
c. For each of the method, Remove the original method group and Add the method group (eg WPS1LoginMethod) that you have created. Click Finish.
7. Prepare a error page
a. Create a HTML file to be displayed when a unauthorized user log in. Besides displaying an error message, the HTML should also contain a link to the URL that will log out the user when he clicks on it. This is because to WPS, the unauthorized user would have already log in and he needs to be logged out again. The HTML should contain something like this.
<h1>You are not authorized to access this portal</h1>
Click <a
href="http://yourhostname/wps1/myportal/action/IBMLogoutUserAuth">here</a>
to continue
b.
Place the HTML file in a place where it can be
directly accessed by the browser. One possible location is <wps_root>\app\web\html
8. Set your WPS instance to use the error page
a. In AdminConsole, select WebSphere Portal Server 1->WPS Servlet Engine->wps1.
b. Select the Advanced Tab on the right panel. Scroll down the page until you see the Error Pages table
c. Add the following entry
i. Status Code or Exception: 403
ii. Location: html/loginerror.html (or which ever location and filename of the error page you created in Step 7)
9. Restart your WPS instance.
10. Test the login.
When you try logging in as a user that is not in the group that you have granted permission, you should get the error page you created. Clicking on the link should bring you back to the portal front page.
Note: The above has been tested with Netscape and it works perfectly. However, with IE, you may get the error page again when you click on the Login link a second time(instead of the Login page). I recommend that you use Netscape to do your testing.
Note that this is not a secure method of login control. The user can easily bypass the login control by manually typing in the URL of the portal page when the error page is displayed. An alternative would be to have a redirection instruction in the error page that logs out the user automatically. However, this is not a real solution as the user can easily turn off automatic redirection in the browser. If security is a important consideration, you should use other means of access control eg installing WPS on separate WAS, or use more fine grain WAS resource security control.