How to Integrate Risk Tracker with Internal HR Feeds

Hi, Vineet Batta here. I’m a senior software developer on the Information Security Tools (IST) team.

In my last blog I shared details on features of the Risk Tracker application focusing on the Risk Management module. Today, I will help customers who may want to deploy this in their organizations (this tool is licensed under MS-PL). First there are prerequisite integration steps that needs to be completed so that Risk tracker can be successfully deployed in an environment.

A core functionality of Risk Tracker is the AuthZ (Authentication & Authorization) component. Risk Tracker relies on the following to allow access to the Risk Tracker application based on a user’s configuration setup in the back end system. The prerequisites include:

1. Active Directory services are available.
2. Person table is populated (exists in ISRM db).
3. Organization table is populated (exists in ISRM db).
4. Security Groups Configurations are completed.
5. Cache Manager executable has run at least once.

Person Table

This table needs to be populated with all the employee information within an organization. Only people who have records in this table based on roles defined for them will have access to Risk Tracker. I will explain more about roles later. The records in this table need to be continuously synchronized from the actual source (HR feed system).

Example:                                                                                                                                                                                                                          

Internally our team implemented SISS package that did this required synchronization of employee data which helps maintain updated employee records in the Person table. You can do this for your internal implementation to maintain the records in this table.

OrganizationHierarchy table

This table holds the organization hierarchy information for your organization. Most of the organizations also have code (column OrganizationHierarchyCode) associated with it also. This column is also referenced in the ‘Person’ table.

Example:                                                                                                                                                                                                                          

Internally our team implemented SISS package that retrieved this organizations hierarchy from an internal HR feed which now allows the organization hierarchy to be maintained here. You can do the same for your internal implementation and maintain the records in this table as well.

Security Group Configuration

Default Roles are setup as below in the ISRM db with correct Hierarchy during installation. The data is in the Role table.

Note: Parent inherits Childs permission in this system.

Define Security groups in [AuthorizationGroup] for each role. Example: ‘Risk Manager Group’. This is a required step.

For user to have access to the application based on roles (defined above) the user should belong to one or more security groups defined in AD. Then these groups should be mapped to specific role in the ISRM database. This mapping data is stored in [RoleMapping] table.

Example of data in [RoleMapping] table:

Here the GroupID is the Foreign key referenced from primary table [AuthorizationGroup].

Cache Manager

The final step is to run the Cache Manager executable {The detailed deployment steps for Cache Manager are documented in Installation help file} . This will populate the data in the ISRM database for users with the correct role mapping based on which security group they belong to. Please verify that the data is populated in the following tables:

• [AuthZUser]
• [AuthZUserRole]

Hope this helps folks who are trying to integrate Risk Tracker with their internal HR data feeds for employee data. In my next blog I will do a deep dive into the service layer and authorization implementation which we did for Risk Tracker. Stay tuned…

-Vineet