Configuring the Liberty user registry
Through the support in Liberty, i2 Analyze can use LDAP user registries such as Microsoft Active Directory to authenticate users. Especially in example or demonstration deployments, however, you can use Liberty's basic user registry to authenticate users and assign the system group memberships that they need.
Note: For instructions on configuring Liberty to use an LDAP registry, see Configuring LDAP user registries in Liberty.
Before you begin
If you are configuring the basic user registry to provide users in the early stages of the production deployment process, you must adjust it when you modify the groups in the security schema in the schema development or configuration development environments.
About this task
i2 Analyze users can have separate identifiers, user (principal) names, and display names. When you use the basic registry, the same value is used for all three purposes. You can use provisioning to modify users' display names in an example deployment, but in production you should favour one of the other approaches to authentication.
Procedure
Create the users and groups in Liberty for each of the group permissions elements in the security schema:
In an XML editor, open the user.registry.xml file. You can find this file in the C:\i2\i2analyze\deploy\wlp\usr\shared\config directory of your Liberty installation.
Use the following template to add your users and groups to the user.registry.xml file as the first child of the <server> element:
<basicRegistry id="basic" realm="WebRealm"> <user name="" password="" /> <group name=""> <member name="" /> </group> </basicRegistry>
Use the following information to populate the template:
There is a <user> element for each user of the system. The <user> element's name and password attributes must be populated for that user.
There is a <group> element with a name attribute that matches the name of each user group mentioned in the security schema. You can also add groups that are not mentioned in the security schema.
The <group> elements are populated by <member> elements. For a user to be a member of a group, a <member> element's name attribute must match that user's name attribute.
If you are using the example deployment, the user Jenny is a member of each group.
In the following example user.registry.xml, the users Analyst1, and Clerk1 have been added into a subset of the groups. If you use the following example, log in as these users to see the different permission levels of each group:
<basicRegistry id="basic" realm="WebRealm"> <user name="Jenny" password="{xor}FToxMSY="/> <user name="Analyst1" password="{xor}HjE+MyYsK24=" /> <user name="Clerk1" password="{xor}HDM6LTRu" /> <group name="Analyst"> <member name="Jenny"/> <member name="Analyst1"/> </group> <group name="Clerk"> <member name="Jenny"/> <member name="Clerk1"/> </group> <group name="Controlled"> <member name="Jenny"/> <member name="Analyst1"/> </group> <group name="Unclassified"> <member name="Jenny"/> <member name="Clerk1"/> </group> <group name="Administrator"> <member name="Jenny"/> </group> </basicRegistry>
Use the Liberty securityUtility command to encode the password for each user:
Navigate to the bin directory of your Open Liberty deployment that is configured by the deployment toolkit. By default Liberty is deployed in the C:\i2\i2analyze\deploy\wlp directory.
In a command prompt, run the following command:
securityUtility encode password
The encoded password is displayed in the command line. Record the encoded password, including the {xor} prefix, and use the encoded password as the password in the user.registry.xml file.
For more information about using the security utility, see securityUtility command.
Save and close the file.
What to do next
To test that your changes have worked, log in to i2 Analyze as one of the users that you added to the user registry.
After you test your changes to the user registry, you can configure user access to features. For example, to upload records to the Information Store, a user must be a member of a group that has the i2:RecordsUpload permission under command access control. For more information, see Configuring command access control.