Externalized authorization

The Externalized Authorization feature enables you to enforce your business policies uniformly across all your applications.

A business can specify conditions to determine when to give a user access to their products, which means to authorize the user. These conditions form the business policy and can be based on user attributes, product attributes, relationships, user consent, and many other types of information.

Examples of policies

• "To view a product of type premium, the user must be a paying customer."

• "To receive monthly newsletters, the user must consent to the use of their email address by company X."

• "To view a confidential document, the user must be a doctor and the owner of the document must have given their consent."

• "To update a medical document, the user must be a doctor or a nurse and must have a caring relationship with the subject of the document."

• To use a smart device, the user must be the owner or have a relationship with the owner."

Applying a business policy consistently within a microservice-based architecture poses some challenges: each individual component must know which user is interacting with it and which authorizations are to be granted. To simplify application design and to make applications independent of policy evolutions, authorization can be performed externally. This ensures consistency between applications, in addition to security and scalability.

Externalized authorization with the OneWelcome Identity Platform

The OneWelcome Identity Platform offers help with externalized authorization by providing an API-based system:

1. Config API: Define customized policies.

2. Authorization API: Take policies into account to make authorization decisions.

   

Configuration of policies: Config API

The policies for each tenant can be managed in your relationship management portal.

Information model

The Config API enables tenants to define policies that can be used by the Authorization API to make authorization decisions for the other OneWelcome Identity Platform APIs and for the tenant's applications.

Objects and attributes

Policy name attribute

Each policy must be provided with a name that can be linked to the attempted action by following the naming convention: targetType:action.

• The most common actions are read, create, update, and delete. The Relationship Management API also makes use of additional actions such as relationships:list.

• The type of target (resource in the authorization request) can be among others:

  • an ActorType, such as user,
  • a ResourceType, such as pet,
  • a RelationshipType with the from and to types,such as user:is_admin_of:subscription,
  • an Invitation (for a specific type of relationship): {fromType}:{relationshipType}:{toType}:invitation, such as user:is_coadmin_of:subscription:invitation.

Examples of policies

The Rego attribute and the graphical representation

The policy conditions are specified by using the OPA policy language Rego. The Rego data can be entered directly via the create/update policy endpoint or can be automatically converted from the graphical representation created in the relationship management portal.

Example of the graphical representation in the relationship management portal

The above graph represents the action user:is_member_of:subscription:invitation:create. The converted Rego data of this policy can be found below.

Rego example

rego: "

package sandbox_small_pond_c0ec.user.is_member_of.subscription.invitation.create

default outcome = "deny"

outcome = "allow" {
  user_is_admin_of_subscription
}
{
  user_is_coadmin_of_subscription
}

user_is_admin_of_subscription {
 input.graph.subject.is_admin_of[_].subscription.id == input.resource.to.id
 input.graph.subject.type == "user"
    }

user_is_coadmin_of_subscription {
 input.graph.subject.is_coadmin_of[_].subscription.id == input.resource.to.id
 input.graph.subject.type == "user"
     }
"

Executing policies: Authorization API

Information model

The tenant's applications and the APIs can send a request to the Authorization API to execute a policy and thus determine whether a specific action is authorized. The authorization request is based on the XACML specification, which specifies four parts in the request: subject, action, resource, and context. The Authorization API can enrich this input with relationship information (graph) as provided by the Relationship Management API. All above information can be used to determine the authorization decision based on the corresponding policy. The response is an object containing the outcome (generally allow or deny) and optionally other data. If the policy specified in action does not exist, the response is by default deny.

To make an authorization request, use the following endpoint:

• Authorize request

Endpoints Overview