Concepts

This topic provides an overview of IAM concepts.

Authentication

Authentication identifies a user or an app, and determines what HERE resources and services the user or app can access. For example, when you log in to the HERE platform with a user name and password, you have access to your authorized HERE resources and services. The authentication process also gives you the option of using API keys, OAuth 2.0 tokens, and OIDC tokens to authenticate your identity.

For more information, see Manage authentication.

Authorization

Authorization designates what a user or app can do with the HERE resources and services they can access. You configure authorization levels using entities, permissions, roles, and resources. For more information, see Manage authorization

Entities

In IAM, entities define specific permission sets, collections of identities, and resources.

The following table provides definitions of the entities that comprise IAM:

Entity	Definition
Organization	Scopes all IAM entities, HERE services, and resources within the same security namespace.
Identity	The identifier for a user or app. Org admins and org inviters can invite new users to their org. For more information about users, see Invite users and Manage users. For more information about apps, see Manage apps.
Group	A collection of identities. Any identity can create groups. Both org admins and group admins can manage group memberships. For more information, see Manage groups.
Project	An access-controlled collection of resources, such as catalogs, pipelines, schemas, and services. Any identity can create new projects. Both org admins and project admins can manage projects. For more information, see Manage projects.
Resource	A HERE resource identified by a unique HERE Resource Name (HRN).
Permission	A rule for defining fine-grained access control to HERE services and resources. You manage permissions and can assign them to all identities and groups.
Role	A set of specific permissions assigned to an identity.
Policy and plan	A bundle of permissions through access policies and plans.
Resource policies and resource plan resources	A bundle of access controls to a project.
Access filter	Restrictions of access to resources, based on specific conditions.

Permissions

Permissions let you control access to HERE services and resources. You can manage permissions and assign them to any identity or group.

The following table provides definitions for the parameters used IAM permission statements:

Parameter	Definition
`id`	The unique identifier for a permission.
`serviceID`	The unique identifier for a service. You can use a service ID alias instead of the `serviceId`.
`effect`	Sets the permission to either `"allow"` or `"deny"`.
`action`	The action governing the permission. Each service has its own action defined.
`resource`	The resource associated with the permission. Each resource uses a unique HERE Resource Name (HRN)

The following JSON code block is an example of an IAM permission statement's structure, which represents a permission configuration.

    {
        "id": "PERM-5d595ef9-d081-4ea5-b404-4c7bd816aec6",
        "serviceId": "account",
        "effect": "allow",
        "action": "read",
        "resource": "hrn:here:account::olp-here:app/0A1B2C3D4E5F6G"
    }

Roles

Following the "principle of least privilege," you should only grant the minimum required level of access to a user or app in your realm. IAM roles allow you to customize and extend this access, as outlined in the following table:

Role	Permissions
User	Default role when no other roles are selected. This includes invited identities, such as users and apps, that don't have any existing roles associated with them. Based on your realm subscription, the default policy may grant additional permissions, such as being able to view all identities in the organization, create groups, create apps and projects and so on.
Marketplace Consumer	View, purchase, and subscribe to products and services in the HERE marketplace.
Marketplace Provider	Create and publish listings on the HERE Marketplace if also assigned the Org Admin role.
Org Admin	• Invite new users • Manage users • Manage groups, projects, and access There can be multiple admins within an organization, and each organization must have at least one admin. HERE recommends that you limit the number of org admins, and instead perform user management with groups by group admins.
Org Inviter	Invite new users.
Resource Manager	• Manage all apps • Manage all resources Org admins can toggle the Manage all apps and resources toggle on the user profile page in the Access Manager to become a Resource Manager.
Group Admin	Manage groups for which the Group Admin is the designate administrator.
IdP Manager	Configure or change the IdP information within the organization.
Project Admin	Manage projects for which the Project Admin is the designated administrator.
Monitoring Dashboards Editor	• Edit monitoring dashboards • Edit notification channels • Edit alerts.
Licensing Admin	Manage licenses for the organization.
Cross Realm Trust Manager	Establish trust with another org for the purpose of sharing resources.
Restricted Access	Restricted access to the platform, only allowing read permissions for access to subscribed HERE services available to the organization. Restricted access users have access to these subscribed services, but can't access the management platform.
Restricted App Access	This role allows the partner organization to prevent customer organizations from adding, deleting, or modifying existing app IDs. This is useful for managing subscriptions currently assigned to the organization app IDs, preventing the addition of subscriptions, or inadvertently deleting an app ID. The `RestrictedAppAccess` role also allows customer organizations to perform common tasks such as viewing usage and app IDs. However, customer organizations should only have the `RestrictedAppAccess` role applied, and no others. The combination of multiple roles provides the invited user with permissions that apply for all the roles, which nullifies the restriction on adding, editing, or deleting app IDs.

HERE Resource Names

IAM uses HERE Resource Names (HRNs) as a standardized way to reference resources across different services and accounts. HRNs are unique HERE authentications that adhere to the following structure.

The following code block defines a format for an HRN string:

hrn:{partition}:{service}::{account}:{resource}

HRN parameter	Definition
`partition`	The deployment region of the entity. The default value is `"here"` for everywhere except China, whose value is `"here-cn"`.
`service`	Service name of the entity. Available values are `"account"`, `"authorization"`, or `"iam"`.
`account`	The Organization/realm of the entity.
`resource`	The unique identifier for the resource.

The following table is a list of all current IAM HRNs:

Resource Type	HRN Format
Org/Realm	`hrn:here:account::{org}:realm/{orgId}`
User	`hrn:here:account::{org}:user/{userId}`
Invite	`hrn:here:authorization::{org}:invite/{inviteId}`
Application	`hrn:here:account::{org}:app/{appId}`
API Key	`hrn:here:account::{org}:apikey/{apikeyId}`
Access Key	`hrn:here:account::{org}:accesskey/{accesskeyId}`
Secret	`hrn:here:account::{org}:secret/{secretId}`
Identity Provider	`hrn:here:account::{org}:identityProviders/{identityProviderId}`
Device	`hrn:here:account::{org}:device/{deviceId}`
Group	`hrn:here:authorization::{org}:group/{groupId}`
Project	`hrn:here:authorization::{org}:project/{projectId}`
Project Policy	`hrn:here:authorization::{org}:project/{projectId}:policy/{policyId}`
Service	`hrn:here:authorization::{org}:serviceDescriptor/{serviceId}`
Role	`hrn:here:authorization::{org}:role/{roleId}`
Policy	`hrn:here:authorization::{org}:policy/{policyId}`
Plan	`hrn:here:authorization::{org}:plan/{planId}`
Resource Policy	`hrn:here:authorization::{org}:resourcePolicy/{resourcePolicyId}`
Resource Plan	`hrn:here:authorization::{org}:resourcePlan/{resourcePlanId}`
Access Filter	`hrn:here:authorization::{org}:filter/{filterId}`