Skip to Content

This is my first “how to” blog on STVN and unfortunately it’s taken me a while to find the time to get it finished and published before 3.0 is released and its relevance diminishes significantly. That said, the principles will remain the same as will a majority of the techniques and methods of coding.

Security is by far and away the most complex area of OrgChart, particularly for the Staged architecture. I will mostly cover Staged but I will also highlight the configuration for the Live architecture. Despite SAP’s recommendation to use Live I find that most organisations have at least one complex requirement that cannot be met by the Live architecture. This generally concerns excluding objects or transforming data in a way that cannot be done through XSL templates and where the client does not want to customise standard SAP BAPIs.

For those wanting to do advanced security configuration I recommend obtaining the TestAllowList.aspx script from Nakisa to use for testing. This will make your life so much easier when trying to work out which part of your security is failing.

Luckily in STVN2.1 OrgChart a large chunk of security is already pre-configured. The authentication is pre-configured, as are the security roles. However, if customisation takes place and new, secure data is added then this needs to be restricted to one of these roles – or added to an entirely new role. In this blog I will concentrate on customising the security roles. This requires an intermediate knowledge of XML configuration in OrgChart, including a sound knowledge of the configuration structure and naming conventions.

Concepts in OrgChart Security

I thought I’d start quickly by going through some of the basic concepts involved in OrgChart security. These concepts are based around the two common security concepts of authentication and authorisation:

  • Authentication is the process of seeing if the user has access to the system
  • Authorisation is the process of seeing what the user has access to in the system

Before we touch on the concepts of security I think it is important to discuss the authentication sources to add context to this discussion.

Authentication Sources

OrgChart can authenticate against 3 sources:

    1. SAP (using forms login)
    2. Enterprise Portal (using single sign-on or forms login)
    3. LDAP (for Windows Integrated authentication)

  Each source offers different benefits and caveats during implementation. For clients without the Portal who do not provide SAP access to many potential users of OrgChart then Windows Integrated authentication can be a good method of authenticating the user. However, this does not come pre-enabled and requires customisation to enable in ManagerResources.xml (the one in Admin_config folder, not your build folder). As a hint it can be found in the LoginConfigurations
item.
 

Portal integration allows single sign-on using the Portal SSO ticket so once users are logged into the Portal they do not need to log in for a second time into OrgChart. OrgChart reads the SSO ticket, extracts the user’s SAP username and password from the ticket and then uses that with SAP. It uses the SAP MYSAPSSO2 module to do this plus some other DLLs if you are using STVN2.1 or above. This will be covered later.

SAP forms login is the good old fashioned login method – enter your SAP username and password as if you were logging into the SAP gui.

Authentication

Authentication is fairly straightforward… or so you think! In OrgChart it is more than just entering the SAP system details. The authentication concept has sub-concepts of its own:

    1. User authentication object
    2. User Object
    3. Role mapping to the role object

  These objects are populated with data throughout the authentication process in order to enable authorisation. The authentication process works like this: 

The user authentication object populates with data from the authentication source. The User Object is populated with the user’s employee record from SAP using data from the authentication source. Data from the User Object is then used to map them to an application role. In the Live version where structural authorizations are used instead of application roles, the role mapping data will be populated but no role object mapped to the user. Most often when security isn’t working it is because one or more of the above objects or processes have failed.

Authorisation

Authorisation in OrgChart is very similar to SAP and is based around the use of roles. This is not really relevant with Live when structural authorizations are in place because the system uses the authorization checks when accessing data to determine if that data can be shown in the application. The only caveat here is adding a custom starting location for your chart, depending on the logged in user.

A role within OrgChart gives users particular access to items, data or parts of the structure that have been restricted. Commonly this is used to give Manager and HR users access to sensitive data for the whole organisation (for HR users) or for a specific area (for a Manager or Business Partner). When talking about this role based security configuration it is important to recognise two areas within OrgChart security: static security and dynamic security (see below). We also refer to the data that is only to be shown to a particular role as “restricted” data.

Role-based Security

Static security and dynamic security allow access to restricted data but through different scopes. Usually a HR role would have static security while a Manager role would have dynamic security. Static security allows access to the restricted data for all objects in the structure. Dynamic security allows access to restricted data for all objects in the part of the structure from a particular root (ie the Manager’s position) downwards.

In STVN2.1 OrgChart there are 5 roles pre-configured out of the box. This is great news for those of you that aren’t technically savvy in STVN but want to have security roles for your clients. The roles are:

    1. Everyone
    2. Assistant
    3. HR
    4. Manager
    5. Executive

Each role has a different scope of access and different configurations. While you feel it isn’t necessary to learn how to do this type of configuration I am going to run through some of it in order to help you create new roles or change the ones that come pre-configured with OrgChart.

How do I do that?

So, now you’ve done the reading it’s time to look at the doing. There are 3 files that may require changes. These changes cannot be done in the Administrator Console, generally because only some of the basic configuration can be performed in the Administrator Console. These 3 files are:

  • ..\Admin_config\<build>\AppResources.xml
  • ..\Admin_config\<build>\Security\RoleMapping.xml
  • ..\Admin_config\<build>\Security\Roles.xml

Note: Static Security

Static Security is an “all or nothing” approach – it allows the user to see the restricted data for every object if they have this type role otherwise they will not see the restricted data for any object. In order to restrict data to a role of this type it is simply marked as secure=”true” in AppResources.xml and then the section referenced in the role in Roles.xml. However, the exception to his is when the restricted data is also to be seen by a dynamic security role. In that case the data is given the dynamic security keyword (see dynamic security). No mention of this section needs to be made within Roles.xml, but the security keyword for the dynamic security needs to be declared in the static security role.

A typical static security role in Roles.xml may look something like this scaled-down version of ROLE_HR (which I’ve done to add some clarity to the configuration features):

<role name=”ROLE_HR “>

<allowed>

<element>

<type>OrgChartView</type>

<objectname>SAPOrgUnitOrgChart</objectname>

<name>SAPOrgUnitFTEView</name>

</element>

<element>

<type>OrgChartView</type>

<objectname>SAPPositionReportingChart</objectname>

<name>SAPPositionFTEView</name>

</element>

<element>

<type>DetailsSection</type>

<objectname>SAPOrgUnitDetailsConfiguration</objectname>

<name>DemographicsTab</name>

</element>

<element>

<type>DetailsSection</type>

<objectname>SAPOrgUnitDetailsConfiguration</objectname>

<name>StaffingTab</name>

</element>

<element>

<type>DetailsSection</type>

<objectname>SAPPositionDetailsConfiguration</objectname>

<name>EmployeeDetailInfo</name>

</element>

</allowed>

<keywords>

<keyword name=”PositionSecurity” scope=”PositionSecurity” />

<keyword name=”OrgUnitSecurity” scope=”OrgUnitSecurity” />

<keyword name=”EmployeePositionSecurity” scope=”EmployeePositionSecurity” />

</keywords>

<scopes>

<scope name=”PositionSecurity”>

<matchtofield source=”static”>1</matchtofield>

<matchoperator>equals</matchoperator>

<matchagainst source=”static”>1</matchagainst>

</scope>

<scope name=”EmployeePositionSecurity”>

<matchtofield source=”static”>1</matchtofield>

<matchoperator>equals</matchoperator>

<matchagainst source=”static”>1</matchagainst>

</scope>

<scope name=”OrgUnitSecurity”>

<matchtofield source=”static”>1</matchtofield>

<matchoperator>equals</matchoperator>

<matchagainst source=”static”>1</matchagainst>

</scope>

</scopes>

</role>

The role is broken into 3 sections: allowed, keywords and scopes. Allowed specifies the data sections that are available to this role, keywords declares the security keywords (which may not be used if the data sections are only ever allowed for this role) and the scopes which determine how the keyword scopes work. Generally the scopes configuration will always be as above and does not require any changes, with exception of the keywords. Therefore if a dynamic security configuration does not use any of the 3 keywords and you want a section shared by both to be available to this user then a keyword and scope configuration can be copied and renamed to the new keyword.

The main configurations here are the elements that are allowed. Each one of these will have a secure=”true” tag in the AppResources.xml. But, remember that if the data section is shared with a dynamic role it neither needs the secure=”true” tag in AppResources.xml nor does it need to be declared in the allowed list. Its security will be controlled by the keyword.

In each element there is a type tag (the contents are pre-defined by Nakisa), the objectname and the name. Depending on what you are securing the latter two will change. There are many different types available so I will list the most popular types along with the source of the objectname and name information you will need.

Type

Objectname source

Name source

Description

SearchControlField

Searchcontrol name

Field name

Search field

ListingField

Listing name

Field name

Search display field

DetailsSection

Detail name

Section name

Detail section

DetailsReport

Detail name

Report name

Report (e.g. analytics)

DetailsLinkedDetails

Detail name

Linked detail name

Linked detail section

DetailsDataField ***

Detaildata name

Field name

Single data field

OrgChart **

Orgchart name

OrgChart (e.g. Position Hierarchy)

OrgChartView

Orgchart name

View name

View

OrgChartHierarchyDetail

Orgchart name

Hierarchydetail hierarchy

Details panel

DetailsPresentationTab

Presentation name

Tab name

Details panel tab

ModuleControl **

Module name

Application module

Note: * has a subobjectname tag after the objectname, which is the fieldset name. ** has no name tag.

Now let’s take a practical example. Let’s say I wanted to restrict access to the contact data on the Position details panel to only users that had the ROLE_HR role. Looking in AppResources.Xml I can see that “Address”, “Email”, “Telephone” and “Sec. Phone” are all in the fieldset of one section of the Position Details Panel’s detail configuration.

To restrict the section I would need to use the DetailsSection type. In AppResources.xml I would navigate to the DetailsSection in the Position Details Panel and in the section tag I would simply add the secure=”true” attribute. Below is a visual example, with the additional configuration in bold:

<section name=”ContactInfo” enable=”True” secure=”true”><section name=”ContactInfo” enable=”True” secure=”true”>

Dynamic Security

Dynamic security allows users with a dynamic security role to see restricted data for an area of the hierarchy configured in a hierarchy scope in that role. It uses the user’s starting point(s) as the basis for the “root” of the data hierarchy. This basically means that restricted data defined with a securitykeyword tag only starts showing for the part of the hierarchy that begins from the root(s) of the logged in user. Generally this is only used for Staged implementations because accessing SAP data in the Liver version is controlled by SAP authorizations.

Now I say root with an s in brackets because it is possible a user (e.g. a Business Partner or Talent Management Specialist) would have access to more than one area of the hierarchy that they are responsible for. In this situation the root would start from all of the different roots. The hierarchyscope configuration (see below) can have a rootvaluedelimiter value that allows OrgChart to read each root between the character defined in the rootvaluedelimiter tag. For the Live architecture there is no additional configuration needed, but for Staged architecture a new field would have to be created to concatenate all of the root fields plus the delimiter character. This would also need to be in the data element that issued for the User Population.

A typical ROLE_Manager role would look something like this:

<role name=”ROLE_Manager”>

<allowed>

<element>

<type>OrgChartView</type>

<objectname>SAPOrgUnitOrgChart</objectname>

<name>SAPOrgUnitFTEView</name>

</element>

<element>

<type>OrgChartView</type>

<objectname>SAPPositionReportingChart</objectname>

<name>SAPPositionFTEView</name>

</element>

<element>

<type>DetailsSection</type>

<objectname>SAPOrgUnitDetailsConfiguration</objectname>

<name>DemographicsTab</name>

</element>

<element>

<type>DetailsSection</type>

<objectname>SAPOrgUnitDetailsConfiguration</objectname>

<name>StaffingTab</name>

</element>

<element>

<type>DetailsSection</type>

<objectname>SAPPositionDetailsConfiguration</objectname>

<name>EmployeeDetailInfo</name>

</element>

</allowed>

<keywords>

<keyword name=”PositionSecurity” scope=”PositionSecurity” />

<keyword name=”OrgUnitSecurity” scope=”OrgUnitSecurity” />

<keyword name=”EmployeePositionSecurity” scope=”EmployeePositionSecurity” />

</keywords>

<hierarchyscopes>

<hierarchyscope name=”PositionSecurity”>

<orgchart>SAPOrgUnitOrgChart</orgchart>

<scopehierarchy>SAPOrgUnitHierarchy</scopehierarchy>

<datahierarchy>SAPOrgUnitHierarchy</datahierarchy>

<dataelement>SAPPositionDetailsDataElement</dataelement>

<maptoDataHierarchyId>OrgID</maptoDataHierarchyId>

<maptoDataHierarchyElementId>OrgID</maptoDataHierarchyElementId>

<rootfrom source=”user”>Org_unit</rootfrom>

<allowedrelations>

<direct>true</direct>

<indirect>true</indirect>

<root>true</root>

<notdirectindirect>false</notdirectindirect>

</allowedrelations>

</hierarchyscope>

<hierarchyscope name=”EmployeePositionSecurity”>

<orgchart>SAPOrgUnitOrgChart</orgchart>

<scopehierarchy>SAPOrgUnitHierarchy</scopehierarchy>

<datahierarchy>SAPOrgUnitHierarchy</datahierarchy>

<dataelement>SAPEmployeeDetailsDataElement</dataelement>

<maptoDataHierarchyId>OrgID</maptoDataHierarchyId>

<maptoDataHierarchyElementId>OrgID</maptoDataHierarchyElementId>

<rootfrom source=”user”>Org_unit</rootfrom>

<allowedrelations>

<direct>true</direct>

<indirect>true</indirect>

<root>true</root>

<notdirectindirect>false</notdirectindirect>

</allowedrelations>

</hierarchyscope>

<hierarchyscope name=”OrgUnitSecurity”>

<orgchart>SAPOrgUnitOrgChart</orgchart>

<scopehierarchy>SAPOrgUnitHierarchy</scopehierarchy>

<datahierarchy>SAPOrgUnitHierarchy</datahierarchy>

<dataelement>SAPOrgUnitDataElement</dataelement>

<rootfrom source=”user”>Org_unit</rootfrom>

<allowedrelations>

<direct>true</direct>

<indirect>true</indirect>

<root>true</root>

<notdirectindirect>false</notdirectindirect>

</allowedrelations>

</hierarchyscope>

</hierarchyscopes>

</role>

The first thing that stands out is the addition of the hierarchyscopes configuration instead of the much smaller, and simpler, scopes configuration in the static role. Each hierarchyscope defines the parameters for displaying data with the securitykeyword key. Adding the security keyword to your AppResources.xml is the same as the example given in the previous section. However, it must be noted that the each hierarchyscope only works for one data element. Therefore any data from a data element not defined in a hierarchyscope will not be shown if secured with an existing security keyword.

Importantly for this type of configuration the fields in your data element that match the hierarchy ID field and, where it exists, the hierarchy parent ID field of the hierarchy must be defined in the detaildata configuration. This is done with a fieldset called ID that has the ID(s) defined in it.

Next up is the hierarchyscope configuration. This is what controls the access to the data defined with your security keyword. A typical hierarchyscope might look like this:

<hierarchyscope name=”OrgUnitSecurity”>

<orgchart>OrgUnitOrgChart</orgchart>

<scopehierarchy>OrgUnitHierarchy</scopehierarchy>

<datahierarchy>OrgUnitHierarchy</datahierarchy>

<dataelement>OrgUnitDataElement</dataelement>

<rootfrom source=”user”>ParentNo</rootfrom>

<allowedrelations>

<direct>true</direct>

<indirect>true</indirect>

<root>true</root>

<notdirectindirect>false</notdirectindirect>

</allowedrelations>

<rootvaluedelimiter>,</rootvaluedelimiter>

</hierarchyscope>

The values for each tag are displayed below:

  • orgchart – the orgchart to which your hierarchy scope will apply
  • scopehierarchy – the root hierarchy of the orgchart
  • datahierarchy – the hierarchy in the orgchart that your security applies to, e.g. in the OrgUnitOrgChart either OrgUnitHierarchy for OrgUnits or PositionHierarchy for Positions
  • dataelement – the data element that is the source of the data you are securing (this will be different in every hierarchy scope, as only one hierarchy scope is required for each data element)
  • rootfrom – for source=”user” the field in the User Object that matches the hierarchy ID field
  • allowedrelations – these settings control the scope of data to be seen with this hierarchy scope and are all true/false Booleans:
  • direct – the data can be seen for direct reports
  • indirect – the data can be seen for indirect reports
  • root – the data can be seen for the root object
  • notdirectindirect – the data can be seen for all objects that are not direct or indirect reports
  • rootvaluedelimiter – used as a separator for multiple root IDs in the rootfrom field

Once this is mastered it creates powerful security capabilities that allow all types of data to be displayed to different users in different ways. The flexibility of OrgChart in its data design allows a vast number of combinations to secure data. When using a database very complex security architectures can be built to harness security in a similar way to SAP. The robust security means it can be hard to get right first time – or even second time! – but it also means if it fails or isn’t configured correctly no data will show. In the event of part of the security process failing no restricted data will be shown.

Using testallowlist.aspx (.NET only)

As a side note Nakisa provide a test script called testallowlist.aspx that shows system, server and application information from OrgChart at runtime. Within this information is the authentication, user object and role information. Usually if these sections are blank then something is not configured right. Usually this file can help debug what the problem is alongside the configuration files.

Summary

Security is difficult to get right the first time and take a long-time to figure out the problems. It is worth budgeting plenty of time the first couple of times in order to do the necessary tweaking of configuration required to get it right.

It is also worth noting that the XML architecture in 3.0 will change from the traditional structure it has had for several versions. While the file structure may change I’m hopeful that the configuration should not change significantly. Until I actually get my hands on it I won’t know for sure.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Mohammad Ali
    Hi Luke,
    Good to see the security blog. Will try it out soon on our test system. However, I am expecting the next major release 3.0 would perhaps offer more flexible yet comprehensive security features.
    Regards.
    Mohammad
    (0) 
    1. Luke Marson Post author
      Hi Mohammed,

      The security model is already very flexible so I am not sure what improvements can be made. As far as I’m aware there are no changes in 3.0 other than adding some additional functionality in the Admin Console for configuring security.

      Best regards,

      Luke

      (0) 
  2. Stephen Burr
    Good in depth look at security based on your hard earned experience! 

    Is it worth just putting the script in testAllowList.aspx on here? Do you have a jsp version suitable for NW CE yet?

    Also, 3.0 will be encrypted (as per previous versions), so will require a trained partner at the very least to do some of the more advanced (e.g. dynamic security) this configuration you discuss here. 

    Finally, where that leaves the client in terms of support (if customised without using the Admin Console) is still a grey area.

    Stephen

    (0) 
    1. Luke Marson Post author
      Hi Stephen,

      There is no testallowlist for Java yet, although I understand that Nakisa have an internal request to create one in the subsequent future.

      I expect there will only be support for customisations if they have been completed by a Certified consultant. The new Certification is very rigourous and can only be obtained with practical experience.

      Best regards,

      Luke

      (0) 

Leave a Reply