Thoughts on Portal from Level 2 Support

Matching: security

WebSphere Plugin Personal Certificate and password will expire on April 26, 2012

Brett A. Gordon Tags: wsas plugin security ssl ‎ 3,741 Views

WebSphere Portal customers should be aware of the following technote: http://www.ibm.com/support/docview.wss?uid=swg21579757

From the technote:

The WebSphere Plugin comes with a plugin-key.kdb file upon installation, and contains a personal certificate that is set to expire by April 26, 2012. The keyfile itself also has a password "WebAS" that is set to expire by April 26, 2012. Action may be required to maintain encryption between the plugin and application server(s). This affects WebSphere Application Server V6.1, 7.0 and 8.0.

Refer to the Flash technotes from the WebSphere Application Server support team to determine if you are affected and what steps may be needed to correct this situation (direct links):
http://www.ibm.com/support/docview.wss?uid=swg21577327

http://www.ibm.com/support/docview.wss?uid=swg21588312

Limitations on using a File Repository

twcornwe Tags: federate file-based security fileregistry.xml repository ‎ 4,709 Views

Overview

WebSphere Portal 6.1 and later out of the box utilize a file repository in a Virtual Member Manager (VMM) federated repositories. During installation of WebSphere Portal, a prompt is given to create a new username and password. The username and password are created in the file repository and utilized by WebSphere Portal during runtime, and during installation/configuration tasks. When the system is ready to be configured to an enterprise LDAP, with a standalone LDAP configuration, the file repository no longer is available and only a single LDAP is available for use. With a federated repositories configuration, a file repository and one or more LDAP may exist simultaneously. A decision should be made as to whether to keep the file repository, or, remove it. In general, the recommendation is to remove the file repository.

Why Keep the File Repository?

The most common reason to keep the file repository is to have a location other than the LDAP to store the administrative users. In the event of an LDAP outage, the file repository would still be available and allow login to the WebSphere Application Server and/or Portal server. For these scenarios, we instead strongly recommend customers setup a database user registry with their Portals. The database user registries do not have nearly the number of limitations as do the file repositories, allow for a more flexible configuration of the system, and do not have nearly the performance penalty as do file repositories. More information on database user registries are available here:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/install/aix_add_db_ureg.html

Why Remove the File Repository?

In general, WebSphere Portal v6.1-8.0 recommends to remove the file repository in production systems:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/plan/plan_clussec.html

"Note: It is not recommended to use the file-based repository in a production environment".

WebSphere Portal v8.5 and later require its removal in production systems:
https://www.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/plan/plan_ureg_ov.html +
https://www.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/plan/plan_clussec.html

There are several limitations on the file repository which may limit functionality (and potentially performance) of the system.

　Limitation #1: Administrator groups are restricted to adding users from same repository

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.wim.doc/anentitynotfoundexceptionerroroccurs.html

"Only the database entry mapping repositories support the creation of a group with members that exist in repositories outside the database repository. If you use a Lightweight Directory Access Protocol (LDAP) registry, you can assign a member to a group within that same LDAP registry. Similarly, if you use a file repository, you can assign a member to a group within that same file repository. "

End Result: You may not have an administrative user in the file repository which belongs to an administrators group in the LDAP, and vice-versa.

　Limitation #2: Client certificate login not supported with file repository

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/twim_filebased_unconfig.html

"Client certificate login is not supported in a realm that includes a single built-in, file-based repository or a single built-in, file-based repository with other repositories."

Addendum: This is now supported with WAS 70023, WAS 8004 and WAS 8550 and later. More details available at this link:
http://www-01.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/twim_filebased_cert_login.html

　End Result: This is a rare, but valid security configuration not available with the file repository.

　Limitation #3: Cluster-only - changes to file repository must be manually replicated

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/twim_changing_repos.html

"Changes to built-in, file-based repositories are not automatically replicated to managed nodes in a federated repositories configuration. You need to use the administrative console to replicate the changes you make to a built-in, file-based repository."

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.wim.doc/file.html

"If the WebSphere Application Server is installed in a clustered environment, then these files are distributed to all the cluster members based on the standard WebSphere Application Server configuration distribution mechanism. All the write functions occur only at the Network Deployment Manager (NDM) server, but the read functions are performed using the local file repositories."

　End Result: You may not use "Edit my Profile" to modify users or their passwords in a File Repository. It must be done via the Deployment Manager console.

　Limitation #4: SPNEGO will not work with file-repository users

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rsec_SPNEGO_troubles.html

"The registry used by WebSphere is not the Active Directory domain LDAP, or Global Catalogue, but is some other virtual registry (for example, a file-based custom user registry)."

End Result: Administrative users in the file repository will not be able to use SPENGO if configured.

　Limitation #5: Tivoli Access Manager integration will not work with file repository users

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rwim_limitations.html

"You can configure only one LDAP repository under federated repositories, and that LDAP repository configuration must match the LDAP server configuration under Tivoli Access Manager."

　End Result: Administrative users in the file repository will need to access the Portal server, rather than through TAM. Note, the same is likely true for other External Security Managers (such as Siteminder), as those ESMs typically do not have access to the users in the file repository.

　Limitation #6: Application groups are not supported with file repository users

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/security/app_group.html

"Note: Application groups only apply to WebSphere Portal; it does not apply to external security managers. Also, application groups is not supported when using the default federated repository with a built-in file repository."

End Result: If an administrative user exists in the file repository, it is not supported to make that user a member of one or more application groups. This is a WebSphere Portal specific limitation.

　Limitation #7: Multiple Wildcards not supported with file repository users

http://www-01.ibm.com/support/docview.wss?uid=swg21470705

"The VMM file-based repository does not support search queries with multiple wildcards"

　End Result: If searching for users in the Portal with multiple wildcard, e.g. searching for John Doe via Jo* Do*, such searches will fail. Both the file repository and LDAP will be searched with this query, and the query will fail on the file repository, causing the entire search operation to fail and have no results return to the end user.

　Limitation #8: File repositories do not contain password enforcement policy enforcement such as:

- Account lock out when you have too many failed login attempts
- Passwords the expire
- Enforcement of strong passwords
- Password reset/recovery that known only to the user and not to the administrator

Modified on by twcornwe

Things to consider when creating new virtual portals in Websphere Portal v7

twcornwe Tags: security initialization script portal initialize virtual vp permision xml ‎ 6,307 Views

*** Location of Virtual Portal Scripts

When you create the virtual portal by using the Virtual Portal Manager portlet, the virtual portal is pre-filled with default content. This default content is determined by the default XML script file for initializing virtual portals.

In previous versions of Portal, the Virtual Portal (VP) initialization xml scripts are stored on the file system in the directory ...//wp_profile/installedApps/<node_name>/wps.ear/wps.war/virtualportal. In Portal 7, the VP initialization scripts are located in a WebSphere Application Server (WAS) asset named VirtualPortal.zip. To get to this file, access a WebSphere Application Server administrative console, select Applications -> Application Types -> Assets, and locate the file in the list.

This VirtualPortal.zip file is physically located in:<wp_profile>/config/cells/<cellname>/assets/VirtualPortal.zip/aver/BASE/bin (in a stand-alone Portal environment)

<DMGR_profile>config/calls/<DMGR_Cell_name>/assets/VirtualPortal.zip/aver/BASE/bin (in a clustered environment)

In a migrated Portal v7 environment, as part of the migration process the virtual portal scripts are removed from the .../wps.ear/wps.war/virtualportal directory and moved to a WAS asset zip file named MigratedVirtualPortal.zip and is located in the .../VirtualPortal.zip/aver/BASE/bin directory as mentioned above.

*** WebSphere security role required

As the VP initialization scripts are now located in a WAS asset, WAS security comes into consideration when Portal class is accessing WAS services. As a result, if the user who attempts to create or initialize the VP has no proper privileges on the WAS, the task cannot access the XML file used to initialize the virtual portal and it will fail with the exception "EJPAH2012E: Can not find xmlaccess script".

This issue was reported under APAR PM39581, and a fix was released as part of Cumulative Fix CF006 for Portal 7.0.0.1, but unfortunately the WAR is not redeployed in CF06, CF07, or CF08. The WAR is properly redeployed in CF09.

Therefore, in CF06, CF07, or CF08 to take advantage of this fix, customers should manually redeploy the WAR by copying PortalServer/ap/wp.ap.virtualportal/installableApps/ManageVirtualPortals.war to PortalServer/installableApps/ManageVirtualPortals.war and then running the ConfigEngine.sh/bat deploy-portlet-upgrade-wp.ap.virtualportal

If you can not upgrade Portal to the later CF that includes this fix, you can workaround this issue by logging in to the IBM® WebSphere® Integrated Solutions Console (ISC) admin console as the WAS administrative user and giving the user who is trying to create or initialize the virtual portal the "Monitor" role, which is the minimum requirement.

* Steps to add "Monitor" role for a user:

- Go to: Users and Groups >> Administrative user roles >> Add

- Highlight the "Monitor" role in the Role(s) box

- Search for the user and select the user from the search results

- Click the "Add" button

- Click "OK". Then save to the master configuration.

- Restart Portal

After these steps, user should be able to create virtual portals using the Virtual Portal Manager portlet and to initialize the virtual portal created previously that failed to initialize.

This situation is described in more details in IBM Technote # 1469910

*** Migrated VP scripts vs. Fresh Install VP scripts

Another issue that may occur in Portal v7 environment migrated from Portal v6.1 is caused by a missing Portal resource in Portal v7. The migrated VP initialization script may contain references to the "Manage Seed List" portlet, which has become obsolete in Portal v7 and will cause the script to fail with exception such as:

"EJPXA0025E: The resource was not found in the portal, either because it does not exist or because you have not specified an identifying attribute in the XML input. [portlet <portlet_objectID> name=Manage Seed List]"

The reason that these scripts are not updated during migration is that they are considered customer scripts. The scripts that ship with Portal just have the sample content and pages in them. So there is an assumption that the customer may have updated the scripts with their own pages and content; therefore, the migration process just moves these scripts untouched into the WAS asset VirtualPortal.zip in the target Portal v7 environment.

To avoid this issue,

* BEFORE MIGRATION: Remove those references to "Manage Seed List" in your VP xml scripts. For example, remove these lines:

And this:

<portletinstance action="update" domain="rel" objectid="portletinstance_objectID" portletref="<Manage_Seed_List_objectID>" shareref="5_CGAH47L008DE402BK8543I18D4"></portletinstance>

(The object ids, portletrefs, sharerefs, etc ... may vary in your installation.)

* AFTER MIGRATION: If you have already migrated, use the WAS admin console to export the VirtualPortal.zip asset, update the VP initialization script as above, then re-import the asset. Refer to the section "Asset Collection" of the Websphere Application Server v7 Information Center for details on how to update the asset.

Feed for Blog Entries

Blogs