Control resource access with Access Filters

An Access Filter is an IAM resource that defines a permission boundary for access requests. Access filters can be applied to certain types of entities, including:

Realms
Users
Apps
Roles

In the closed organization setting, admins must add at least one access filter before any identity can access resources and services. Additionally, access filters can only grant access to an organization's subscribed resources and services.

Admins can assign up to five Access Filters to an individual identity.

Behavior

When an identity restricted with an Access Filter makes an access request, the request must pass one of the filters in order to continue through the evaluation process.

An Access Filter contains a list of statements that determine how it evaluates access requests. The following table gives an outline of a statement:

Property	Description
`permissions`	One of `unscoped`, `scoped`, or `linkable`. • `unscoped` provides access to services and resources outside of projects. • `scoped` only provides access to services and resources linked or created in projects. • `linkable` designates services and resources available to be linked to projects for scoped access.
`service`	The `serviceId` sent in the access request.
`action`	The `action` sent in the access request. A filter should have one of either `action` or `actionAccessLevel`.
`actionAccessLevel`	The access level of the action in the request. A filter should have one of either `action` or `actionAccessLevel`.
`resource`	Optional. The resource in the access request.
`scope`	Optional. The scope of the access request.
`evaluate`	This statement determines whether to evaluate the permissions that match. Available values are `true` or `false`.
`priority`	An integer representing the statement priority. Possible values range from 0 to 1000, with 1000 being the highest priority.

Every access request is checked against any applicable Access Filters. This includes any Access Filter attached to the requester, the requester's realm, or any of the requester's roles.

Each statement in the Access Filter that matches the requested service, action, resource, and scope is collected and sorted according to the configured priority value. The statement with the highest priority is then used to evaluate the request. If this statement's evaluate value is true, the statement's corresponding permissions category is evaluated in the access request. Otherwise, the category is skipped.

If multiple statements match, and all have the same priority, but have different values for evaluate, whichever evaluation returns true takes precedence over the others, and that category of permissions is evaluated.

Access Filter Types

Three types of access filters can be assigned to an identity. Each identity can have a maximum of five filters, but this can include any combination of the three filter types.

Platform Access Filters

Predefined access filters are the default filters on the HERE platform. These filters are based on roles assignable to users or apps, such as OrgAdmin or ResourceManager, and reflect the abilities and restrictions of those roles.
"open", "strict", and "closed" filters are also categorized as platform access filters and these can be attached to users or apps as well.

Custom Access Filters

Custom Access Filters offer more granular and expressive control on the resources and services that can an identity can access. For example, you can use a wildcard character * in a filter statement to evaluate an identity's ability to access any or all of the resources, actions, or services available in a realm. This includes any resource or service available to the organization via a subscription.

Virtual Access Filters

Virtual Access Filters use subscription information to enable the creation of an access filter without designating the resources or services to be provided. If an organization has multiple subscriptions, each subscription can have its own virtual access filter.

Default (Implicit) Access Filters

The HERE platform applies certain access filters by default to newly created entities, without requiring explicit attachment. These implicit filters enforce the principle of least privilege from the moment an identity is created.

Default behavior for apps

When a new app is created, the Restricted IAM Access filter (hrn:here:authorization::HERE:platform:filter/restricted-iam-access) is automatically applied. This filter restricts access to IAM APIs that expose PII data and prevents creation of IAM resources, while preserving access to HERE location services and basic non-PII IAM data.

Entity Type	Default Filter	Effect
App	`restricted-iam-access`	Blocks PII-exposing IAM APIs and IAM resource creation
User	None	No implicit filter applied

Opting out of the default filter

If your app requires broader IAM access, an OrgAdmin or an identity (user or app) with manage access to the app can explicitly detach the default filter:

olp permission access delete \
  hrn:here:account::<realm>:app/<appClientId> \
  hrn:here:authorization::HERE:platform:filter/restricted-iam-access

Once detached, the platform records the explicit opt-out. The filter will not be re-applied automatically, even if the identity is updated.

Opting in to a stricter filter

For apps that do not require any IAM operations, HERE recommends applying the Block IAM Access filter instead:

olp permission access set \
  hrn:here:account::<realm>:app/<appClientId> \
  hrn:here:authorization::HERE:platform:filter/block-iam-access

Visibility

Implicit default filters appear in the access filter list for the entity (via olp permission access show) even though no explicit attachment record exists. They are treated as attached for both access control decisions and API responses.

IAM Security Filters

The HERE platform provides two predefined access filters specifically designed to restrict how AppIDs interact with IAM APIs:

Filter Name	Filter HRN	What It Blocks
Block IAM Access	`hrn:here:authorization::HERE:platform:filter/block-iam-access`	Blocks access to all IAM APIs (authorization and account services). Recommended for apps that do not require any IAM operations.
Restricted IAM Access	`hrn:here:authorization::HERE:platform:filter/restricted-iam-access`	Blocks IAM APIs that expose PII data and prevents creation of IAM resources. Apps retain access to basic IAM data such as plans and permissions.

Restricted IAM Access — what is blocked

When applied, this filter prevents the identity from:

Accessing PII data — realm members, invites, group members, role entities, and grant details
Creating IAM resources — projects, groups, apps, secrets, and resource policies
Viewing account executive contact information

The following access is preserved:

Reading subscription plans and resource plans
Viewing your own permissions
Accessing subscribed HERE location services (maps, routing, geocoding, etc.)

Block IAM Access — what is blocked

When applied, this filter blocks access to all IAM APIs, including everything the Restricted filter blocks plus:

Reading any authorization or account service endpoints
All project management operations
All role and policy management operations

Managing IAM security filters via OLP CLI

List available platform access filters:

olp permission access filter list --type here-platform

List filters attachable to members:

olp permission access filter list --member-only

Attach a filter to an app:

olp permission access set \
  hrn:here:account::<realm>:app/<appClientId> \
  hrn:here:authorization::HERE:platform:filter/block-iam-access

Verify attached filters:

olp permission access show \
  hrn:here:account::<realm>:app/<appClientId>

Detach a filter:

olp permission access delete \
  hrn:here:account::<realm>:app/<appClientId> \
  hrn:here:authorization::HERE:platform:filter/block-iam-access

⚠️
Security Notes

Do not embed OAuth credentials (Access Key ID and Access Key Secret) in publicly distributed applications, mobile apps, or devices without applying an appropriate access filter.

Without an access filter, applications with valid OAuth credentials can access IAM endpoints that reveal personally identifiable information, including email addresses, user names, roles, and invitation statuses of realm members.

Always apply the most restrictive filter that allows your application to function correctly.

Only identities with the OrgAdmin role can override access filter restrictions.

Filter Assignment

Access filters can be assigned based on an entity's organization, role type, directly to the entity itself, or implicitly by default.

Org - Realm-based filters are also known as organization settings. The three available access filters are open, strict, and closed.
User/App - Direct assignment of access filters to users and AppIDs by using any of the three access filter types as shown in the section above. Up to 5 access filters can be assigned to an identity.
Role - Pre-defined access filters for roles that are automatically provided to a user/app when a role is assigned to that identity. For example, an OrgAdmin will have the Org level access filter of “Strict”, and so any user or app with this role will have access to all resources and services available in the realm. Other roles have their access as described by the permissions provided here. These access filters are predefined and cannot be edited.
Implicit default - Filters automatically applied to newly created apps. See Default (Implicit) Access Filters above.

Examples

Strict

The following example demonstrates the behavior of system set to strict, wherein any unscoped request only evaluates unscoped permissions, and scoped requests only evaluate scoped permissions. The linkable permission type is never evaluated in any direct decision call.

   {
    "hrn": "hrn:here:authorization::HERE:platform:filter/strict",
    "name": "Strict",
    "statements": [
        {
            "description": "Allow unscoped permissions for any unscoped request with resource",
            "permissions": "unscoped",
            "service": "*",
            "actions": [
                "*"
            ],
            "resource": "*",
            "evaluate": true,
            "priority": 0
        },
        {
            "description": "Allow unscoped permissions for any unscoped request without resource",
            "permissions": "unscoped",
            "service": "*",
            "actions": [
                "*"
            ],
            "evaluate": true,
            "priority": 0
        },
        {
            "description": "Allow scoped permissions for any scoped request with resource",
            "permissions": "scoped",
            "service": "*",
            "actions": [
                "*"
            ],
            "resource": "*",
            "scope": "*",
            "evaluate": true,
            "priority": 0
        },
        {
            "description": "Allow scoped permissions for any scoped request without resource",
            "permissions": "scoped",
            "service": "*",
            "actions": [
                "*"
            ],
            "scope": "*",
            "evaluate": true,
            "priority": 0
        },
        {
            "description": "Deny linkable permissions for any scoped request with resource",
            "permissions": "linkable",
            "service": "*",
            "actions": [
                "*"
            ],
            "resource": "*",
            "scope": "*",
            "evaluate": false,
            "priority": 0
        },
        {
            "description": "Deny linkable permissions for any scoped request without resource",
            "permissions": "linkable",
            "service": "*",
            "actions": [
                "*"
            ],
            "scope": "*",
            "evaluate": false,
            "priority": 0
        },
        {
            "description": "Deny linkable permissions for any unscoped request with resource",
            "permissions": "linkable",
            "service": "*",
            "actions": [
                "*"
            ],
            "resource": "*",
            "evaluate": false,
            "priority": 0
        },
        {
            "description": "Deny linkable permissions for any unscoped request without resource",
            "permissions": "linkable",
            "service": "*",
            "actions": [
                "*"
            ],
            "evaluate": false,
            "priority": 0
        }
    ],
    "type": "here-platform"
}

Default Allow

This filter gives any request, whether scoped or unscoped, access to all three categories of available privileges.

{
  "hrn": "hrn:here:authorization::HERE:platform:filter/open",
  "name": "Open",
  "statements": [
    {
      "description": "Allow unscoped permissions for any unscoped request without resource",
      "permissions": "unscoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow scoped permissions for any unscoped request without resource",
      "permissions": "scoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow linkable permissions for any unscoped request without resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow unscoped permissions for any unscoped request with resource",
      "permissions": "unscoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow scoped permissions for any unscoped request with resource",
      "permissions": "scoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow linkable permissions for any unscoped request with resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow unscoped permissions for any scoped request without resource",
      "permissions": "unscoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "scope": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow scoped permissions for any scoped request without resource",
      "permissions": "scoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "scope": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow linkable permissions for any scoped request without resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "scope": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow unscoped permissions for any scoped request with resource",
      "permissions": "unscoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "scope": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow scoped permissions for any scoped request with resource",
      "permissions": "scoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "scope": "*",
      "evaluate": true,
      "priority": 0
    },
    {
      "description": "Allow linkable permissions for any scoped request with resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "scope": "*",
      "evaluate": true,
      "priority": 0
    }
  ],
  "type": "here-platform"
}

Default Deny

This filter denies all access, both scoped and unscoped, to any request seeking access to the three categories of available privileges.

{
  "hrn": "hrn:here:authorization::HERE:platform:filter/closed",
  "name": "Closed",
  "statements": [
    {
      "description": "Deny unscoped permissions for any unscoped request with resource",
      "permissions": "unscoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny unscoped permissions for any unscoped request without resource",
      "permissions": "unscoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny scoped permissions for any scoped request with resource",
      "permissions": "scoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "scope": "*",
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny scoped permissions for any scoped request without resource",
      "permissions": "scoped",
      "service": "*",
      "actions": [
        "*"
      ],
      "scope": "*",
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny linkable permissions for any scoped request with resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "scope": "*",
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny linkable permissions for any scoped request without resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "scope": "*",
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny linkable permissions for any unscoped request with resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "resource": "*",
      "evaluate": false,
      "priority": 0
    },
    {
      "description": "Deny linkable permissions for any unscoped request without resource",
      "permissions": "linkable",
      "service": "*",
      "actions": [
        "*"
      ],
      "evaluate": false,
      "priority": 0
    }
  ],
  "type": "here-platform"
}