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 within the platform. 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 only necessary for Version 4.3.0 and earlier; it 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.
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.
Kinetic Task configuration user credentials
Kinetic Request CE Space Admin user account that can be used as a Proxy User for Kinetic Task.
Configuration 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.
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.
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.
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/20KineticTask/Documentation/KineticTask4.0/UserGuide/Consoles/40Permissions
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.
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.