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:
Why Remove the File Repository?
In general, WebSphere Portal recommends to remove the file repository in production systems:
"Note: It is not recommended to use the file-based repository in a production environment".
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
"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
"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."
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
"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."
"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
"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
"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
"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
"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