5.5 Configuring TAM for authorization for WebSphere Portal Server

< Day Day Up >

Before continuing with the configuration steps for this task, it is necessary to ensure that the following installation tasks have been carried out:

On the Application Node

Installation of Access Manager Java RunTime Environment as per sections 4.5.6, "Installing Tivoli Access Manager Java Runtime Environment" on page 112 through 4.5.7, "Configuring Tivoli Access Manager Java Runtime Environment" on page 113.

Before continuing with the configuration steps for this task, it is necessary to ensure that the following configuration tasks (together with all their prerequisite tasks) have been carried out:

On the Application Node

Configuration of TAM to perform authentication as per section 5.4, "Configuring TAM for authentication for WebSphere Portal Server" on page 182.
On the Security Node

Configuration of TAM to perform authentication as per section 5.4, "Configuring TAM for authentication for WebSphere Portal Server" on page 182.

5.5.1 Modifying the Portal authorization configuration

Make a back-up copy of the <wps_root>\shared\app\config\services\ ExternalAccessControlService.properties file. Edit this file.

Change the following values:

Change externalaccesscontrol.ready from false to true.
Uncomment the externalaccesscontrol.server property (it should have a default value of WebSphere_Portal).
Uncomment the externalaccesscontrol.application property (it should have a default value of WPS).
Uncomment the externalaccesscontrol.cell and change its value to <ApplicationNodeName> (m23x2896, in our environment).
Uncomment the externalaccesscontrol.pdroot and change its value to /WPS.
Uncomment the externalaccesscontrol.pduser line and leave its default value of sec_master.
Uncomment the externalaccesscontrol.pdpw line and change its value to sah309r (in our envirnoment).This is the password for sec_master.
Verify the value of the externalaccesscontrol.pdurl property and ensure that it is pointing to the correct directory and file (as set by the -cfg_file argument in the SvrSslCfg Tivoli command) as set by SvrSslCfg in "Installing Tivoli Access Manager Java Runtime Environment" on page 112.

Note
If the value of externalaccesscontrol.pdurl has spaces in it, you can put spaces in the pdurl property, but do not put quotes around the property or add%20 for spaces; it will not work.
Uncomment the externalaccesscontrol.createAcl; its default value should be true.
Uncomment the externalaccesscontrol.pdactionGroup line and the externalaccesscontrol.pdaction line.

Save the file.

Make a back-up copy of the C:/program files/portalserver/shared/app/config/services/ AccessControlConfigService.properties file, where C:/program files/portalserver is your<PortalServerRoot>. Edit the following value as shown:

    accessControlConfig.enableExternalization=true

Save the file.

Make a back-up copy of the C:/program files/portalserver/shared/app/config/services.properties file. Edit the file and modify the Access Control section by adding the following entry and commenting the previous entry for this property:

    com.ibm.wps.services.ac.ExternalAccessControlService=com.ibm.wps.ac.esm.TAM    ExternalAccessControlImpl

Save the modified file.

Make a back-up copy of the AccessControlDataManagementService.properties file in the C:\program files\websphere\portalserver\shared\app\config\services directory. Edit the file and change the value of the property accessControlDataManagement.cacheTimeout to 30. This value controls the time interval between access control cache flushes. When using an external authorization provider, this value has to be changed from its default value of 0. If it is not changed then the externalization performed on different resources will not be taken into account until the Portal server is restarted. Save the file.

The following steps add a Tivoli Access Manager-specific subclass of java.security.Principal to the WebSphere Portal JAAS Subject, which is used for the access control integration with Tivoli Access Manager.

From the WebSphere Application Server Administrative Console, select Security -> JAAS Configuration -> Application Logins -> Portal_Login. Click JAAS Login Modules in the Additional Properties section. Click New. Enter com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy in the Module Classname field. Select REQUIRED in the Authentication Strategy field. Click OK.

click to expand
Figure 5-68: Adding a Login Module

Click Application Login Configuration -> Portal_Login -> JAAS Login Modules, then click com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy. Click Custom Properties in the Additional Properties section. Click New. In the Name field, type delegate and in the Value field type com.ibm.wps.sso.WebSealLoginModule. Click OK.

click to expand
Figure 5-69: Adding WebSEALLoginModule Custom Property to Login Module

Click Application Login Configuration -> Portal_Login -> JAAS Login Modules and then click New. Enter com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy in the Module Classname field. Select REQUIRED in the Authentication Strategy field. Click OK. You will then have two Module Classnames specified, both with the same value, as shown in Figure 5-70 on page 207.

click to expand
Figure 5-70: Login Modules created for Portal_Login Application Login

Click the com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy just created. Click Custom Properties in the Additional Properties section. Click New. In the Name field, type delegate and in the Value field type com.tivoli.mts.PDLoginModule. Click OK.

click to expand
Figure 5-71: Adding PDLoginModule Custom Porperty to Login Module

You should have only one delegate Custom Property under each Module Classname.

Select Security -> JAAS Configuration -> Application Logins -> Portal_SubjectRebuild and repeat the same procedure with exactly the same values as for the Portal_Login.

click to expand
Figure 5-72: Login Modules created for Portal_SubjectRebuild Application Login

Click Save at the top of the page, then click Save again.

Make a back-up copy of the <wp_root>/shared/app/config/services/ConfigService.properties file. Edit the file and set the execute.portal.jaas.login value to true. Save the file.

Make a back-up copy of the <wp_root>/shared/app/config/callbackheaderslist.properties file. Edit the file and uncomment the appropriate entries so that it reads as below:

    header.1=iv-user    header.2=iv-creds

Save the file.

Restart WebSphere_Portal.

5.5.2 Testing externalized authorization

When the WebSphere Portal starts, TAMExternalAccessControlServices creates the necessary topology in Tivoli Access Manager to begin externalizing roles and also creates the core WPS_Administrator-Virtual_wps-EXTERNAL ACCESS CONTROL_1 role. It also creates an ACL (Access Control List) and adds the <wpsadmin> user to the ACL. It attaches this ACL to the core role. To confirm this, execute the following commands in a pdadmin session on the Security Node:

    objectspace list    action group list    acl list    acl show WPS_Administrator-Virtual_wps-EXTERNAL_ACCESS_CONTROL_1

The output should be similar to that shown in Figure 5-73.

click to expand
Figure 5-73: TAM authorization

Open a browser and type in the URL:

    https://m23caatk.itso.ral.ibm.com/portal/wps/myportal

where m23caatk.itso.ral.ibm.com/portal/wps/myportal is the <SecurityNodeHostname>.

WebSEAL will prompt you for a user and password. Type wpsadmin and sah309r. The personalized portal page for wpsadmin will open. Notice that he should still have the Administration link available in the upper right corner of the screen. This confirms that authorization for portal administration is working properly.

Tracing externalized authorization

If the above tests are not successful, you will have to debug the modules that are involved with external authorization. To do so, you will have to edit the PDJLog.properties file that is located in C:\program files\websphere\appserver\java\jre\PolicyDirector. Change the value of baseGroup.PDJTraceLogger.isLogging from false to true. Uncomment the baseGroup.PDJauthzTraceLogger.isLogging property and set its value to true. The default location for the trace file generated by this property is C:\program files\tivoli\Policy Director\log and the file name is trace__amj.log.

Edit the <wps>/shared/app/config/log.properties file and change the traceString entry to:

    traceString=com.ibm.wps.engine.commands.*=all=enabled

The trace file generated by this setting can be found in the <wps>/log directory with the following name: wps<timestamp>.log.

In the same place where you added the delegate Custom Property, add a new custom property with the name debug and the value true.

click to expand
Figure 5-74: Adding debug to Login Modules

After making these changes, you will have to restart WebSphere_Portal.

5.5.3 Externalizing resources

Previous versions of WebSphere Portal worked with external security managers by externalizing resources and using ACLs to control permissions. WebSphere Portal now externalizes roles and uses ACLs to control role membership. From the perspective of the external security manager, these externalized roles contain only one permission: membership in the role. WebSphere Portal always determines the permissions that the portal associates with each role.

The specifics as to which resources to externalize and the access control to be applied to them is environment-specific and needs to be analyzed in detail for each one. Normally, you would externalize the pages and portlets, but the tool allows you to externalize all the portal resource types.

We have currently set the property createAcl to true (5.5.1, "Modifying the Portal authorization configuration" on page 202). This implies that for each resource role type that is externalized for a particular resource, there is a dedicated TAM Access Control List created that is attached to the resource role type. That is, if you externalize the Welcome page resource, and this resource has an explicit role type defined for a priviliged user, and administrator in the TAM object space there will be created two objects, one for each role type, and also two ACLs, one for each role type. This can mean that your TAM ACL list will have many entries that might not necessary be for your environment. If this is your case, then you have the possibility of setting the createAcl property to false. The consequences of this are that the ACLs will not be created for the resources you externalize and that you will have to create and attach them manually.

To assign users or groups to Role Types for a Resource, you have to use the Resource Permission portlet which can be accessed by clicking Administration -> Access -> Resource Permission.

click to expand
Figure 5-75: Resource Permissions portlet

Tip

We recommend that you perform system backups before externalizing your resources.

Externalizing the first resource

As an example, we will externalize the YourCo Financial pages. Click Pages under Resource Type column. Click Content Root in the Page Title column. Click My Portal.

click to expand
Figure 5-76: My Portal Resource Permission

Important:

When you externalize the roles for a resource, any access control inheritance from internally controlled parent resources is severed (that is, the external resource no longer inherits role assignments from the internalized parent resource). Since, for most resources, the Administrator Role Type is inherited, it would be lost when a resource is externalized. To prevent problems when this inheritance is severed, you must explicitly assign at least one user (the actual user carrying out the Externalize task) or group (a group to which that user belongs) to the Administrator role before externalizing any resource.

We are going to verify the access granted to the YourCo Financial page (and pages under it by inheritance). Click the key icon in the Assign Access column next to YourCo Financial.

click to expand
Figure 5-77: YourCo Financial Resource Permissions

This shows all the possible roles that can be defined for this resource. To determine which users or groups belong to a role, you will have to click the pencil icon in the Edit Role column for the particular role.

If you examine the User role (click its Edit Role button), you will be able to see that there are no explicit users or groups assigned to it.

click to expand
Figure 5-78: YourCo Financial User Role Members

If we examine the Privileged User role, we see that the special group All authenticated portal users is inherited (it has a check mark in the Inherited column) from a parent resource.

If you examine the Administrator role, you will be able to verify that the wpsadmin user and wpsadmins group have membership to this role and that it is inherited.

click to expand
Figure 5-79: YourCo Financial Administrator Role Members

As noted above, since we are going to externalize this resource, we must add the wpsadmins group explicitly to the Administrator role. Click the Add button and a list of current LDAP groups will appear. Select the checkbox beside the wpsadmins group and click OK.

click to expand
Figure 5-80: Assigning explicit members to a role

You should now see a window similar to the one shown in Figure 5-81 on page 219.

click to expand
Figure 5-81: YourCo Financial Administrator Role with explicit members

There are a few things to notice in this window:

There is a message stating that the member has been successfully added to the role.
The line below this message shows you the role type and the resource which is being modified.
In the Delete member from Role column, a trashcan icon has appeared. This allows you to remove this explicit user/group from the role. It also is an indicator that the user/group has been explicitly assigned to the role (even though, confusingly, the Inherited column is still checked). Keep in mind that the trashcan icon is an indicator of an explicitly assigned user/group to a role.
Groups can be graphically differentiated from users because they have an icon of a group of three figures beside them. Users have no icon next to them.

Click Done and then OK. Click YourCo Financial and then click the Assign Access button next to the Home page. Edit the role for the User. Note that a special group All authenticated portal users and the special user Anonymous portal user are explicitly assigned to this role and that there is no inheritance.

click to expand
Figure 5-82: YourCo Financial - Home page User Role members

In the same way, you can verify the roles for the Company Info, Sales, Customer Support and My Account pages. If you check the User role for the My Account page, you will find that there are no users or groups explicitly or implicitly assigned to it. However, there is still an explicit entry for the special group Anonymous portal user to the role Priviliged User. That is, all authenticated portal users should be able to view all the pages under YourCo Financial but an anonymous portal user will be able to view the other pages but not the My Accounts page. When we externalize the YourCo Financial page in the steps that follow, all these subsidiary pages (and their permissions assigned through roles) will also be externalized.

Once you are done reviewing the permissions, navigate up the page tree to Root -> Content Root -> MyPortal. Click the right-facing arrow in the Externalize/Internalize column.

Important:

You will not be prompted to confirm your selection and the process to externalize or internalize will begin.

When it has completed the message APRV4012I: Resource successfully externalized will appear.

click to expand
Figure 5-83: Successful externalization

The arrow in the Externalize/Internalize column is not updated until you click Done and reopen this resource.

click to expand
Figure 5-84: Externalized versus internalized resource

On the Access Manager server, open the Tivoli Administration command prompt. We can review in the TAM protected object space. To do so, execute the commands as shown in Example 5-11.

Example 5-11: Reviewing externalized Resource Roles

 pdadmin> login Enter User ID: sec_master Enter Password: pdadmin> objectspace list /Management /WebSEAL /WPS pdadmin> object show /WPS     Name : /WPS         Description : Portal Server 5         Type :  (Unknown)  : 0         Is Policy Attachable : yes pdadmin> object list /WPS     /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69     /WPS/Administrator@VIRTUAL_wps.EXTERNAL_ACCESS_CONTROL_1     /WPS/Privileged User@CONTENT_NODE_yourCo.AccountsPage_6_0_6F     /WPS/Privileged User@CONTENT_NODE_yourCo.CompanyInfoPage_6_0_6C     /WPS/Privileged User@CONTENT_NODE_yourCo.ContactUsPage_6_0_6I     /WPS/Privileged User@CONTENT_NODE_yourCo.CustomerSupportPage_6_0_6E     /WPS/Privileged User@CONTENT_NODE_yourCo.HomePage_6_0_6A     /WPS/Privileged User@CONTENT_NODE_yourCo.MyAccountsPage_6_0_6B     /WPS/Privileged User@CONTENT_NODE_yourCo.PaymentsPage_6_0_6G     /WPS/Privileged User@CONTENT_NODE_yourCo.ProfilePage_6_0_6H     /WPS/Privileged User@CONTENT_NODE_yourCo.SalesPage_6_0_6D     /WPS/Security Administrator@CONTENT_NODE_yourCo.Financial_6_0_69     /WPS/User@CONTENT_NODE_yourCo.CompanyInfoPage_6_0_6C     /WPS/User@CONTENT_NODE_yourCo.CustomerSupportPage_6_0_6E     /WPS/User@CONTENT_NODE_yourCo.HomePage_6_0_6A     /WPS/User@CONTENT_NODE_yourCo.SalesPage_6_0_6D pdadmin> object show /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69     Name : /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69         Description :         Type :  (Unknown)  : 0         Is Policy Attachable : yes pdadmin> object list /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69     /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS pdadmin> object list /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS/WebSphere_Portal pdadmin> object list /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS/WebSphere_Portal /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS/WebSphere_Portal/m2 3x2672 pdadmin> object list /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS/WebSphere_Portal/m2 3x2672 pdadmin> object show /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS/WebSphere_Portal/m2 3x2672     Name : /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69/WPS/WebSphere_Portal/m2 3x2672         Description : WP role: Administrator@CONTENT_NODE/yourCo.Financial/6_0_69         Type :  (Unknown)  : 0         Is Policy Attachable : yes         ACL : WPS_Administrator-CONTENT_NODE_yourCo-Financial_6_0_69

The object list /WPS command shows all the TAM objects that have been created in the protected object space (the name of the top-level object /WPS is taken from the pdroot property set in the ExternalAccessControlService.properties file in 5.5.1, "Modifying the Portal authorization configuration" on page 202) to correspond with all the role types defined for the resources externalized (and all their children resources). The object show /WPS command demonstrates that no TAM ACLs have been attached to this object. The remaing commands show additional detail about a particular role type (that is, the adminstrator role for the YourCo Financial page). The following object list commands show the tree structure (that is, the /WPS/WebSphere_Portal/m23x2672 structure) that has been created for each role type object. The names for each level in this tree correspond to the server, application and cell properties set in the ExternalAccessControlService.properties file in 5.5.1, "Modifying the Portal authorization configuration" on page 202. The last object show command demonstrates that an ACL has been attached to the cell-level object of the tree structure. To review the permissions that this ACL grants, enter the commands as given in Example 5-12.

Example 5-12: Reviewing externalized Resource ACLs

 pdadmin> acl list WPS_Privileged-User-CONTENT_NODE_yourCo-CustomerSupportPage_6_0_6E default-webseal default-root WPS_Administrator-VIRTUAL_wps-EXTERNAL_ACCESS_CONTROL_1 WPS_Privileged-User-CONTENT_NODE_yourCo-PaymentsPage_6_0_6G WPS_Privileged-User-CONTENT_NODE_yourCo-ProfilePage_6_0_6H default-gso WPS_Privileged-User-CONTENT_NODE_yourCo-SalesPage_6_0_6D WPS_User-CONTENT_NODE_yourCo-CustomerSupportPage_6_0_6E WPS_Privileged-User-CONTENT_NODE_yourCo-ContactUsPage_6_0_6I default-policy WPS_User-CONTENT_NODE_yourCo-SalesPage_6_0_6D WPS_Privileged-User-CONTENT_NODE_yourCo-CompanyInfoPage_6_0_6C WPS_Privileged-User-CONTENT_NODE_yourCo-AccountsPage_6_0_6F default-config WPS_Privileged-User-CONTENT_NODE_yourCo-MyAccountsPage_6_0_6B WPS_Privileged-User-CONTENT_NODE_yourCo-HomePage_6_0_6A WPS_Administrator-CONTENT_NODE_yourCo-Financial_6_0_69 WPS_User-CONTENT_NODE_yourCo-CompanyInfoPage_6_0_6C default-management WPS_Security-Administrator-CONTENT_NODE_yourCo-Financial_6_0_69 default-replica WPS_User-CONTENT_NODE_yourCo-HomePage_6_0_6A pdadmin> acl show WPS_Administrator-CONTENT_NODE_yourCo-Financial_6_0_69     ACL Name: WPS_Administrator-CONTENT_NODE_yourCo-Financial_6_0_69     Description: ACL for WP roleAdministrator@CONTENT_NODE/yourCo.Financial/6_0_69     Entries:         User sec_master TcmdbsvaBl         Group wpsadmins [WPS]m

Note that the server, application, cell tree structure has been created to form a so-called unified object. This means that an ACL can only be attached to the lowest, cell-level object of the tree structure. That is, you cannot attach an ACL to the intermediate levels. If you attempt to do so, you will receive an error message, as shown in Example 5-13.

Example 5-13: Error in attaching ACLs to externalized resource objects

 pdadmin> acl attach /WPS/Administrator@CONTENT_NODE_yourCo.Financial_6_0_69 WPS_Administrator-CONTENT_NODE_yourCo-Financial_6_0_69 Could not perform the administration request. Error: Protected Object not found in Authorization database (status 0x1005b1ca)

Externalizing virtual resources

If you go to the Resource Permissions portlet and select the resource type Portlets, a list of all the deployed portlets will appear; you can then externalize each portlet individually. However, this can become cumbersome. If later on, you deploy a new portlet, you will have to manually externalize it. There is a much simpler way of doing this and that is to use the Virtual Resource resource type under Resource Types. If you externalize the virtual resource Portlet Applications (which is the parent resource for all portlets and portlet applications), after having added an explicit member to the Administrative role, all the portlets will also be externalized. Each new portlet or portlet application added thereafter will be automatically externalized.

click to expand
Figure 5-85: Externalizing virtual resource

If you select Portlets as the resource type to work with, you will discover that all the current instances of portlets have been externalized.

click to expand
Figure 5-86: Portlets externalized

The same occurs if you select the Portlet Applications resource type.

click to expand
Figure 5-87: Externalized portlet applications

If, by chance, you did not perform a system backup before externalizing resources and did not see the important note stating that you need to create a user before externalizing a resource, you can also do the following if you are familiar with the XMLACCESS tool.

Use XMLACCESS to run a full export of your Portal environment
Edit the resulting .xml file
Find the resource(s) you externalized
Edit the attribute access-control so that externalized=" false"
Use XMLACCESS to import the .xml file (you may want to edit it to only make changes to these particular resources)

< Day Day Up >