Contact usRequest a demo

Accessing Unblu with service principals

Most administrative tasks in Unblu assume that whoever is carrying them out has the ADMIN or SUPER_ADMIN role. However, because user roles in Unblu are hierarchical in nature, users with these roles have access to the same functions as users with the SUPERVISOR and REGISTERED_USER role: They can join conversations, for example. More often than not, employees tasked with administering Unblu Spark are not trained to interact with customers.

Many organizations also want to restrict access to personally identifiable information (PII) to as few people as possible, while still ensuring a sufficient number of people are available to administer applications.

Service principals

Service principals let people carry out administrative tasks using Unblu’s web API without needing a user for that purpose. They’re instances of the ADMIN or SUPER_ADMIN role but they aren’t associated with a user. In other words, service principals don’t have an Unblu person. As a result, service principals lack access to most information available to users with client-facing roles (REGISTERED_USER or SUPERVISOR).

Types of service principal

Unblu has two different types of service principal:

  • Global service principals have the SUPER_ADMIN role. They’re created in the main account of an Unblu Spark deployment.

  • Account-level service principals have the ADMIN role.

Differences between service principals and users

Although service principals are instantiations of user roles, there are important differences between a service principal and a user with the same user role:

  • As mentioned above, service principals don’t have an Unblu person associated with them. They therefore can’t be used to call web API endpoints that determine which person a call relates to based on the authenticated user making the call.

    For example, a service principal can set labels on another user by calling /persons/{personId}/setLabels because the person to set the labels on is a path parameter of the call. On the other hand, calls by a service principal to /authenticator/getCurrentPerson result in an error.

  • Since service principals don’t have a username or password, they can’t be used with the Unblu UIs. They only work with the Unblu web API.

  • Users can only create API secrets for themselves, both in the Unblu UIs and through the Unblu web API endpoint /users/{userId}/createApiSecret.

    Service principals can create API secrets for other users.

Creating service principals

You can create service principals in the Unblu Configuration interfaces:

See also