Applicable Product: OrgPublisher

Applicable Release: V21.x and later

Summary:

Security within the Chart:
There are different types/levels of security available and they will define what you can or cannot do with the scenarios you may face. Field and Style level security can be used in V21 HTML5 charts, but in order to set it up the chart(s) must have Chart Level security applied. 
 
1. Field level security - this allows you to control who can see a field. First, you define groups and then use those groups to define who can see the field. Additionally, you can also set it so that a manager can only see those fields in the boxes below her/him only, or also see her/his own as well.
 
You can also set it so that the field will only display in boxes of people only if they belong to a certain group. In other words, if you want to have people who belong to the MgrGrp only see the field in people who belong to the Reviewers’ boxes, you use the setting above.

A note on securing data fields – while it is possible to secure fields by groups, if a data field has a very high level of sensitivity, you may want to consider only including it in the data feed for a ‘high security’ data feed that is used to publish charts to a location that is secured by NTFS. This means using Windows’ NTFS permissions to lock down a folder so that only people belonging to certain AD groups are allowed into that folder to even view the chart. (See below under Chart Level Security for more details)
 
2. Style level security – this allows you to control who can view certain styles. If you use this, it is recommended that you have at least one style that is unsecured.

3. Starting level security – this controls where you enter the chart. After someone is authenticated, you can set it so that they enter at:

• Top of the chart
• User’s Box
• Supervisor’s Box
• Box ID in this field

4. ACL (Access Control List) - At a particular BoxID,  you would need to have a column in your data that has the value of the BoxID at which that person is to enter ACL (Access Control List).  This is a list you create (and maintain) that defines who can see what. The implementation of an ACL chart is done via our Professional Services Group. It is more labor intensive in the sense that you will have to have a process that adds people to the list and make sure that the boxes they’re allowed to see are entered correctly. Similarly, if someone leaves, you should also make sure their record is removed from the ACL.
 
NOTE: Sometimes, it is prudent or necessary, to create separate charts so that each will have one or two types of security to prevent a convoluted security scheme. As groups are used in the security definition, it is very important that your group definitions are ‘tight’ so that someone does not accidentally ‘fall’ into a group. An example of a ‘loose’ definition would be a group called “HR Group” whose definition is: “job title contains HR”. If an intern’s job title is “Assistant to HR Director”, he/she would fall into that group and be able to see information they may not be allowed to see. A better definition may be “job code equals xyz” where xyz is a job code only HR executives would have. Another crucial thing about groups used is that they should be defined to be mutually exclusive, i.e. people who belong to one group does not belong to another. When you have someone who belongs to more than one group, the application will not know which membership has priority over the other. 
 
Chart Level Security:
We do have a number of options you can choose from for Chart Security:
1. Standard - Add a field (or use existing fields such as email address and perhaps their employee id or some piece of information only the person would know) for username and password (which is not always very secure)   
 
2. Reverse Proxy - Using a Header Value (required) it contains the name of the HTTP header item that will contain the User ID expected by the OrgPublisher Charting Web app.  Store as a cookie allows for the header value to be stored as a cookie in the user's browser. Reverse Proxy will allow OrgPublisher to retrieve the user ID from the HTTP header variable and use it for authentication.
 
3. Windows Authentication - If you chose to use AD Authentication you must include the Active Directory ID in your input data and create a custom field e.g. UserID - this is for OrgPublisher to read and compare to the Windows token.
 
 
To use Active Directory authentication you’ll need to add a Custom Field in OrgPublisher that contains the user’s Active Directory username. Then, set the ‘Security Options’ page to ‘Active Directory Authentication’ and change the ‘User ID field’ (currently End Date) to the same custom field that contains the Active Directory username. By doing this the user’s username from Active Directory will match their record in the chart. When they access the chart through a web browser they’d automatically be logged in, they wouldn’t have to enter a username and password. If for any reason a user is not in the chart’s Active Directory username custom field they would not be able to access the chart – the Active Directory username must be in the chart.
 
You may also want to change the ‘Starting box in chart’ section. This is the section that controls where in the chart the user starts and what boxes that user can view. You can set the ‘Starting box in chart’ to ‘User’s box’, then uncheck the ‘Allow users to drill up from starting box’. The user would start at their box and only be able to move downward.
 
NOTE: OrgPublisher charts can be secured so that only authenticated users can access the chart - this is done via Windows' NTFS permissions and turning on IIS' "Windows Authentication". What this will do is that only authenticated users on your network will be able to access the folder in which the published OrgPublisher charts reside. Additionally, you can add another layer of access control by using OrgPublisher's chart level security. This is done by having a custom field in your data feed that contains each person's ADID. When someone tries to view the chart, the chart will request their ADID from their workstation and then do a lookup in the published data set. If it finds a matching ADID, then the person is allowed into the chart.
 
 
4. SSO - All versions of OrgPublisher support the SSO scenarios as described above with AD authentication and Reverse Proxy.  If you use AD ID for your authentication, all you need is to add that field to each person's record in the data extract. If you use something like a portal authentication, then you have to make sure that the HTTP header contains the user ID and that it is identified by some sort of variable name (your portal team can tell you what that variable name is). Then you will have to use the "Reverse Proxy" authentication method when you publish your chart.
 
5. The only way to limit access to the HTML5 chart without using OrgPublisher's "chart security" (such as Standard, Reverse Proxy or  AD authentication) that requires the person's ID be in the data set, is to use IIS' Authorization Rules feature. It works pretty much like NTFS permissions that you would use to secure folders on your file share.
For Authorization Rules to show up in IIS, you will have to add the "URL Authorization" role via Server Manager (see screenshots Role.jpg and Feature.jpg below).
After the "URL Authorization" role is added, you would do the following:
a. Publish your chart as Unsecured
b. Set the instance's/web app's (in the HTML5 Configuration tool) security to "Unsecured" and have the "Use Windows Authentication for site access" box checked (see Win auth.jpg) - if possible, do an iisreset or recycle the app pool for that web app
c. In IIS, select the web app and then double-click the "Authorization Rules" feature
d. Remove the "Allow all users" rule
e. Add and "Allow Rule"
f. You can then add specific AD groups or AD accounts to provide access, then click OK
NOTE: Keep in mind that when you use this method, you cannot secure fields or styles to certain groups because it is published as an unsecured chart.

Created : Melanie Culp
Reviewed: Alvin Ee 14 Dec. 2021