Protect an arbitrary service

This how-to describes how you can protect services for which security.manager for OGC does not offer fine-grained access control. These can be service types such as OGC API Features services, Web Map Tile Services (WMTS), or other arbitrary HTTP service endpoints.

You can use security.manager for OGC to control access to services that are not among the standard-supported OGC services WMS or WFS. However, in this case you must do without fine-grained access control because security.manager for OGC cannot analyze the service’s requests and responses. Instead, you can only protect access to the entire service and thus ensure that only specific groups of people can access a service.

Prerequisites

If you want to secure a service that is available on a different host than the host for which security.manager for OGC is configured, you must set up a separate installation of security.manager for OGC for it. In that case, follow the steps in the installation guide with the following deviation: Do not configure a WFS or WMS, but configure the arbitrary service directly as described in this how-to.

Configure the protected service

  1. Open the file server-config.json of the configuration.

  2. Add a new entry to services with the following properties:

    • path: Path to the target service on the given host, for example /path/to/ogcapi/features/v1/ for an OGC API Features service.

    • type: Type of the service. The value must be "FORWARD".

      Example entry for a protected service
      {
  "server": {
    "host": "https://gisserver.example.com",
    "services": [
      ...,
      {
        "path": "/path/to/ogcapi/features/v1/",
        "type": "FORWARD"
      }
    ]
  }
}

  3. Save the file.

  4. Restart security.manager for OGC so that the changes take effect.

  5. Test the configuration by calling the protected service through security.manager for OGC. Call the service URL by appending the service path to the base URL of security.manager for OGC, for example https://secman.example.com/secman-ogc/path/to/ogcapi/features/v1/.

The protected service is now reachable via security.manager for OGC, albeit without fine-grained access control.

Allow access for specific groups of people

You can allow access to the protected service for specific groups of people by creating a policy. With the roles that you specify in the policy, you determine which people from the identity provider configured in the Identity Service are allowed to access the service.

  1. In the policies directory, create a new policy file with the suffix .json, for example ogc-api-features.json.

  2. Insert the following content into the file:

    • layers: Must have the value ["*"].

    • roles: Specify the roles from an identity provider or predefined roles that should be granted access to the service. The following example uses the predefined role enhancedSecurity_authenticated that all signed-in people automatically have in security.manager for OGC.

      Example policy for a protected service
      {
  "policies": [
    {
      "layers": ["*"],
      "roles": ["enhancedSecurity_authenticated"]
    }
  ]
}

  3. Save the file.

  4. Restart security.manager for OGC so that the changes take effect.

  5. Test the configuration by first signing in at the Identity Service and then calling the protected service through security.manager for OGC.

    The example policy for the predefined role enhancedSecurity_authenticated allows access to the target service for all signed-in people. If you sign out from the Identity Service and call the protected service again, access should be denied.

Notes

  • If the protected service does not support evaluation of X-Forwarded-* headers, support for URL rewriting may be limited. See the how-to Configure URL rewriting for more information.

  • Protection of arbitrary HTTP services is limited to services that use the HTTP methods GET, POST, PUT, DELETE, and PATCH. Requests that use other HTTP methods are not forwarded.

  • security.manager for OGC does not support forwarding arbitrary request headers to the protected service. If the protected service relies on special HTTP headers, these headers may be lost when requests are forwarded by security.manager for OGC.