Feature: Externalized Authorization

The Scaled Access Externalized Authorization feature allows the customer to enforce their business policies uniformly across all their applications. 

About Externalized Authorization

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

Examples of rules

“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, ensures security, and allows for scalability.

Externalized Authorization with Scaled Access 

Scaled Access offers help with this so-called Externalized Authorization by providing an API-based system to:

  1. Config API: Define customized rules and policies.
  2. PolicyChecker API: Evaluate rules.
  3. Authorization API: Take rules into account to make access decisions.

PII protection

All Personally identifiable information (PII) is persistently stored in the Identity Management user repository only. The Scaled Access APIs do not persistently store any PII. Even though PII can temporarily occur in volatile memory, it is not kept in any database nor log of the APIs.

Sign up to continue reading

You’ll get access to all of our Tech Center documentation on consent, externalised authorisation & relationships.

SIGN UP

We use cookies to enhance your experience. Find out more. By continuing to visit this site you agree to our use of cookies. X