Reference roles from an identity provider in policies

This how-to describes how you can reference roles from an Identity Provider in policies when you have connected security.manager for OGC with an Identity Service.

Once you have connected security.manager for OGC with an Identity Service, security.manager for OGC can enforce policies based on roles that users have been assigned at the Identity Provider.

Assume the Identity Service is connected to a Keycloak as the Identity Provider. In Keycloak, an account "miller" was created and assigned to the role "managers". You can now define a policy in security.manager for OGC that allows the role "managers" to access the layer "hotels" of a WMS. When a person logs in to Keycloak as "miller" in the browser and subsequently accesses the WMS via security.manager for OGC, they will be granted access to the layer "hotels".

Prerequisites

You have connected security.manager for OGC with the Identity Service.
Identity Service and security.manager for OGC are accessible in the browser via the same domain, for example as https://id.example.com/… and https://secman.example.com/secman-ogc/….
You have an account with the Identity Provider that is connected to the Identity Service. This can be, for example, an account in ArcGIS Portal or Keycloak.

Determine available role names

Which role names you can use when defining policies depends on the configuration of the Identity Service that you have connected with security.manager for OGC. In the Identity Service documentation, you can find detailed information under Role assignment about which role names are assigned to users depending on the configured identity provider.

Determine roles of an account

For a specific account, you can determine the assigned roles by calling up the Identity Service in the browser:

Call up the home page of the configured Identity Service in the browser, for example https://id.example.com/identity/.
Click on the link under Login, for example https://id.example.com/identity/account/login.
Log in with your account to the Identity Provider if prompted.

After successful login, you will be redirected back to the Self endpoint of the Identity Service, whose address ends with /identity/account/self. The response contains information about the logged-in account, including the assigned roles.

Example response from the Identity Service

{
  "authenticated": true,
  ...
  "loginName": "miller",
  "username": "miller",
  "email_verified": true,
  "mail": "...",
  "roles": [
    "offline_access",
    "uma_authorization",
    "managers"
  ],
  "groups": []
}

In this example, the account "miller" is assigned to the roles offline_access, uma_authorization, and managers.

Create policy

With the information from the previous sections, you can now create a policy that allows access to a layer only for users with a specific role.

Open the policy file of the service you want to protect.
Create a policy for the role that should be allowed access to a layer, for example:
```
"policies":[
  {
    "layers": ["hotels"],
    "roles": ["managers"]
  }
]
```
Replace hotels with the actual name of the layer you want to restrict access to. Replace managers with the actual role name used by the Identity Provider.
Save the file and restart Tomcat.

Test policy

Log in

To test role-based access, you must first log in via the Identity Service:

Call up the home page of the configured Identity Service in the browser, for example https://id.example.com/identity/.
Click on the link under Login, for example https://id.example.com/identity/account/login.
Log in with your account to the Identity Provider if prompted.

After successful login, you will be redirected back to the Self endpoint of the Identity Service, whose address ends with /identity/account/self.

Call up protected service

Now call up the URL of the protected service in the browser, for example https://secman.example.com/secman-ogc/path/to/my-services/wms?service=WMS&request=GetCapabilities. For the browser to transmit the login information from the previous step as a cookie, you must call up the URL of the protected service in the same browser and in the same domain as that of the Identity Service. You must call up e.g. https://secman.example.com/secman-ogc/… when the Identity Service is accessible under https://id.example.com/….

If you have configured everything correctly, you should now have access to the layer allowed for the role.