Roles & User Authentication

Roles & User Authentication

Overview

Share GIS has a security model based upon authentication & roles. When a user is authenticated with the application iShare GIS will recognise a number of roles associated with the user. The roles control which Map Sources the user can access and whether they can edit any of the layers within those Map Sources.

Authentication

Authentication is generally through a SAML Single Sign-On method such as Microsoft's Entra ID. More information on the set up of Entra ID and iShare GIS can be found here. It is possible to use Windows Authentication but that requires the management of user accounts on the iShare GIS server itself. It is much easier for an organisation to handle authentication through a SAML SSO method. 

Once authenticated, Entra ID will pass a user's claims to iShare GIS that equate to roles. Roles allow read and write access to Map Sources. For instance, a user of a Planning department logs into iShare GIS. Entra ID passes a claim to iShare GIS that the user is a member of the Active Directory Planning group. That group name matches a role in iShare GIS which allows the user access to the Planning Map Source.

Because the iShare GIS web application is authenticated it is not possible to use it from within a Remote Desktop Connection to the server. For this reason, a second web application has been set up for administrators and Astun support staff to use. It can be found at http://localhost:81/iShareGISLIVE.WebLocal. 

Managing User Access Using Roles 

iShare GIS can be used to control the display of information that is sensitive, or which requires filtering from general use. For example locations of domestic abuse crimes should not be widely available, and detailed planning applications should probably be only available to those in the planning department. The mechanism which iShare uses to do this is Roles.

  • Roles can be allocated to Map Sources, with the result that those Map Sources are only visible to users who have the required Role.

  • The 'default' Map Source is available to all authenticated users.

  • Roles also control editing rights for individual layers within a Map Source.

  • The allocation of Roles is made by linking the Role to a local Windows Group defined on the GIS server.

  • So authentication provides claims that equate to local Windows Groups, that equate to Roles.

For example, if you wanted to allow only members of the Planning team to view planning data, you would:

  • In iShare, create a 'Planning' Map Source and the required layers within it.

  • In the SSO configuration, e.g. MS Entra ID's Enterprise Application configuration, the 'Planning' Active Directory group would be added to the application.

  • In Windows, create a local Windows Group, e.g. 'Planning'. No local membership is required.

  • In iShare, create a role e.g. 'Planning', and link it to the Windows Group 'Planning'.

  • In iShare, allocate the 'Planning' role to the Planning Map Source. This Map Source is now considered 'restricted'. Each Map Source can be assigned multiple roles.

  • To allow users to edit layers in Planning, you would add the Role to the specific layers.

There are some important points to understand when managing Roles:

  • iShare uses MS Entra ID (or an equivalent SAML authentication mechanism) to receive claims, and hence role membership.

  • In the iShare GIS web interface, Map Sources correspond to Profiles.

  • If no Roles are allocated to a Map Source, it will be visible to all users

  • As soon as one or more Roles are allocated to a Map Source, it is only visible to users with those Roles

  • The default Map Source should not have Roles allocated to it. The default Map Source can be identified by inspecting "E:\iShareData\LIVE\Config\Webservice\config\iShareMaps.xml".

  • If users have the 'iShareAdmin' claim they will be able to see all Map Sources.

It is important to develop a detailed plan for data management and user access before creating Map Sources, Roles and Windows Groups. Once they are all in place it can be time-consuming to revise them. It is also recommended to use a prefix such as 'ishare_' when creating Active Directory groups as it then easier to keep track of which Active Directory groups are used by the application. And since these are variables used internally by the application and not visible to the users it is encouraged to use the same values when naming the Active Directory groups, the local Windows Groups and the Roles.