Skip to content
  • There are no suggestions because the search field is empty.

Role Based Security

Overview

Role based security (Access Protection) is applied based on the user login credentials to determine chart and feature access within org.manager. It is possible to have different levels of access depending on the employee record associated to users.

Access is applied in two stages. First the user is authenticated via Single Sign-On, which establishes who they are. The application then applies a set of field security rules to determine what that user is allowed to see.

Authentication

On the basis of the authentication of the user who wants to open an organisation chart in an org.manager output via the browser, it is possible to assign access authorisations at person or group level.

The authorisations are set at directory level (IIS) and/or in the organisation chart configuration (access protection module).

However the user is authenticated, org.manager maps the Unique User Identifier (Name ID) passed during Single Sign-On with an Employee Record in the HR data. 

I Windows authentication

If Windows authentication is activated in the web server (IIS), it is possible to configure on the server which persons have access to organisation charts.

The user ID via which the user logs onto the PC is relayed by the server to the applications running there. If the access protection additional module is used, it is also possible to specify which information can be viewed and which functions in the organisation chart can be used. The authorisation function can also be moved from IIS to org.manager if org.directory is used. So-called advanced authentication will then be available.

II Token authentication

As an additional method, org.manager supports authentication via JSON Web Token (JWT). In this case, the client requests a token from an authentication server. If the authentication is successful, the authentication server returns a JSON Web Token. The client then relays the token to the org.manager server component on the web server and access to the organisation chart is granted.

The advantage of this method is being able to use the company's existing authentication servers (insofar as they support JWT). The manner in which a client/user is actually authenticated vis-à-vis the authentication server is part of the corporate IT Policy and completely independent of org.manager operation.

III Anonymous authentication

If anonymous authentication is used in the web server (IIS), the user is not identified. Therefore, restrictions for persons/groups to the organisation chart are not possible (apart from the external proxy servers or firewalls). Likewise, the user cannot be allowed to enter the organisation chart at their own organisation unit.

Field Security

In org.manager, access can be configured at different levels:

  • Attributes - employee id, salary, position title

  • Perspectives - basic chart, org tree with budget analysis, dashboard

  • Features - data exports, PDF exports, search

  • Hierarchical - structural access

How it works

After the authentication process completes and the employee record linked to the user is established, the application works out what level of access to grant using the list of security rules.

Security rules are pre-configured conditional logic using the HR data imported into org.manager. The conditions can be directly related to the user's employee record, or to an object linked to it (for example position, org unit, job). Depending on which conditions are met by their employee record, users can be granted more or less access.

 

After the authentication process completes and the employee record linked to the user is established, the application then proceeds to work out what level of access they should be granted using the list of security rules.

Security rules are pre-configured conditional logic using the HR data imported into org.manager. The conditions can be directly related to the user’s employee record, or to an object linked to it (e.g. position, org unit, job, etc).

Depending on which conditions are met by their employee record, users can be granted more or less access.

Management Access

For instance, a user in a management role might be required to have access to additional perspectives besides the basic organisational chart, remuneration and budgeting attributes, a more comprehensive set of perspectives including dashboards and sunburst diagrams, and additional options to allow them to run data exports or create simulations for organisational modelling.

General users might only be granted access to a subset of data attributes (non-sensitive information), basic charts with restricted access to their teams, PDF export and search.

 
 
 
 
org.manager - Access granted to users that meet rules 2 and 3
 

External Users

As mentioned in the previous section, the access in org.manager is highly dependent on the employee record linked to each user. As such, the application requires for the users accessing it to be part of the HR data being charted.

In the event of requiring to grant access to people who are not part of the organisational hierarchy being rendered in org.manager, this can be achieved by automating the creation of artificial records for external users.

 

Recommendations

  • Keep the access protection rules as simple as possible. In most cases, it is possible to handle all the required access scenarios with just a few rules.

  • Avoid hard coding personnel IDs in the access protection rules as much as possible.

  • Custom fields included in the HR data imported into org.manager can be a viable solution when wanting to control the access directly from the HRIS.

  • Access protection is the most important feature to test before going live with your org.manager organisational charts. Make sure all the possible scenarios are thoroughly tested.