Kinetic Task can be configured to share the same users as a given Kinetic Request CE space to allow for easier management and authorization of users. The article below outlines the steps needed to configure Kinetic Core as the identity store for Kinetic Task.
Additionally, you can configure Kinetic Request CE as an OAuth provider and use it for Single Sign On with Kinetic Task. Instructions on how to do that can be found here.
The Kinetic Core Identity Store is contained in a Jar file that can be added to Kinetic Task v4. Installation is very simple and can be accomplished with only a few steps.
Note: The following steps must be performed for each Kinetic Task web application instance in your environment.
- Stop the web server service (Tomcat, Websphere, etc…).
- Copy the Kinetic Core Identity Store jar file into the deployed Kinetic Task web application. The jar file needs to be copied into the /kinetic-task/WEB-INF/lib/ directory. (This file is included out of the box in Task Version 4.3.1 and later)
- Start the web server service.
- Repeat steps 1-3 for each Kinetic Task web application instance in your environment.
The Kinetic Core Identity Store must be configured to connect to your Kinetic Request CE server, so it knows how to find the User information within a space inside your organization’s Kinetic Request CE installation.
Requirements before starting
- Kinetic Task configuration user credentials
- By default, these values are admin/admin
- May have been changed in your environment
- Kinetic Request CE Space Admin user account that can be used as a Proxy User for Kinetic Task.
- Kinetic Task will connect to the Kinetic Request CE server using a proxy account in order to search the users based on your configuration.
- It is necessary to update the credentials in Kinetic Task whenever the password changes.
The default values used in the example configuration below work with a standard Active Directory implementation of LDAP. If you are using a different LDAP application, the configuration values may be slightly different.
The first step is to login to the Kinetic Task administration console using the built-in configuration user. By default these user credentials are admin/admin, but they were probably changed during the installation. Use the values for your environment. The administration console is located at the following URL - http://your-web-server/kinetic-task/
Once logged in to the administration console, click the ‘Admin’ tab, then the ‘Setup’ tab, then the ‘Authentication’ tab.
Change the Identity Store selection to Kinetic Core Identity Store. The identity store is basically terminology that defines where the User and Group information is stored. By default the application looks to its own internal Users and Groups tables. By changing the value to Kinetic Core Identity Store, the system will look to an external Kinetic Request CE installation.
After the changing the Identity Store selection to Kinetic Core Identity Store, the configurable properties for the identity store become active. This is where you will need to enter the information specific to your location.
Kinetic Core Space Url - The location of the Kinetic Core Space to authenticate against (default: http://localhost:8080/kinetic/space)
Group Attribute Name: The name of the User Attribute that determines what Groups the User is included in (default: Group)
Proxy Username (Space Admin): The username for a proxy account (Space Admin required) used to search for the user details for the login user.
Proxy Password (Space Admin): The password for a proxy account (Space Admin required) used to search for the user details for the login user.
- Repeat steps 1-4 for each Kinetic Task web application instance in your environment.
Now that the system is configured to use Kinetic Core instead of the local identity store, any user matching your configuration can authenticate to Kinetic Task. The instructions below illustrate how to setup the system to restrict access to the different areas of the application.
The first step is to change the system default policy rule to Deny All users. This instructs Kinetic Task to deny access to any area of the application unless a policy rule has been applied to that area. If a policy rule does exist, it will be evaluated and access will either be granted or denied based on the rule. This is in contrast to the default system policy of Allow All users, which would grant access to all authenticated users if a policy rule was not applied to the area.
From within the administration console, click the ‘Permissions’ tab, then the ‘Policy Rules’ tab, then the ‘System Default’ tab.
Change the System Default Rule selection to Deny All, and save the system default rule.
You will now need to create policy rules to define which users have access to the various parts of the application, which you can find in the documentation on Kinetic Community: http://community.kineticdata.com/20_Kinetic_Task/Documentation/Kinetic_Task_4.0/User_Guide/Consoles/40_Permissions
Policy rules can be defined just like they were with the Local Identity Store, except the groups will now be bound to a Kinetic Request CE User Attribute.
As an example, say you want to create a console policy rule that allows access to any user that has the "Kinetic Task Administrator" value for the newly created "Group" User Attribute.
In your configured Kinetic Core Space, create a User Attribute named "Group".
For the Users in that Space that should be Administrators, add the "Kinetic Task Administrator" value to the "Group" User Attribute.
In the Kinetic Task administrator console, click the ‘Permissions’ tab, then the ‘Policy Rules’ tab, then the ‘Console’ tab.
Add a new rule with details as depicted in the image below.
Create as many rules as you need to correspond with your Kinetic Core User Attribute values.
Assign the rules on the Console Access page to define which users have access to each area of the application, click the ‘Permissions’ tab, then the ‘Console Access’ tab. Alternatively, you can select each rule to multiple consoles by clicking on the policy rule.
Repeat for each console, or each policy rule that you created.
Download the installation file.