Download your copy of our State of Authorization: Playbook Edition Get it now »

Three challenges businesses encounter when introducing authorization

Every organization, no matter the industry, can encounter challenges when it comes to introducing authorization at the beginning as it is something new for everyone to adapt too.

However, it doesn’t have to be challenging as there are authorization experts that can guide your organization through the process and help address those challenges that arise.

So, what are the top three challenges most businesses encounter when introducing authorization policy?

1. Many are still thinking about roles and entitlements

The most common challenge that organizations encounter is that they are still thinking in terms of roles, groups and entitlements.

Often, organizations try to continue going through the process of role engineering, mining, and creation when attribute-based access control (ABAC) is introduced.

While there are some good things when thinking about roles, it doesn’t have to be that complex.

Instead, organizations should start to think in plain old English when writing policies.

When writing policies they should be in the following format: Subject + Verb + Object + Context.

As you you can see in this example, it’s written in a simple format that is easy to understand:

A policy "A manager can view any record" broken down into subject, verb, object and context. A manager is the subject, can is the verb, view is the object, and any record is the context in the policy.

2. Peppering authorization across multiple attributes

Another challenge that often arises when organizations start using ABAC is that roles and entitlements aren’t the only artifacts any more.

As a result, authorization information has been peppered across multiple attributes, like date of birth, risk score, role, department, or title and other attributes, like the resource you are protecting or creation date.

Peppering the information is going to make authorization governance harder.

In a traditional role-based access control (RBAC) model, the identity or security team keep track of the roles, provision the roles, and deprovision them.

But in an ABAC approach, the policies are tied together with attributes. This means that harmless attributes, like date of birth or employment date, are now privilege granting attributes.

3. Who owns the policy and drives it in organization

When adding a new artifact like ABAC to an organization there are many questions that will start to swirl around.

Many of the common questions include: what the lifecycle is, who will own the authoring of the policies, drive the tests and maintain the policies.

In the world of roles, it is normally the identity and access management (IAM) team who is responsible for storing and assigned the roles.

On the other side, you have the application team that discovers the roles they want to have and provide them to the IAM team.

When adopting an ABAC model the process is still the same – nothing has to change in terms of who owns/drives the policy.

However, externalizing authorization might offer the opportunity for the organization to rethink who owns/manages policy and adopt a DevSecOps model, whereby a team assembled from IAM/security, development and the business own/run policy.

The Axiomatics difference

Over fifteen years of experience

For over fifteen years, Axiomatics has delivered runtime, fine-grained authorization with ABAC to enterprises all around the world.

Over those years, we have seen a lot when it comes to policies, roles, entitlements and all things authorization, and our vast amount of experience has equipped us to better help our customers along their authorization journey and we have methodologies based on that experience.

A policy-first authorization language

Axiomatics uses a policy-first authorization language that has the structure to scale as your organization grows.

Many solutions only have the leaf of the tree in place where you’ll have policies.

But with Axiomatics, we provide the branching to support the leaves. This is the structure that holds it all together and makes it easier to manage and view all of the policies efficiently.

Plus, our policy language allows you to write regular language quickly within the daily workflow.

In our Policy Editor, you can write the policy in line with other development projects you are doing so you don’t have to go to a separate tool.

This saves time as you don’t have to go through a bunch of screens and clicks to get where you want.

Take the next steps on your authorization journey

Request a demo with our experts to see for yourself what our solution can do to elevate your authorization strategy and learn more about the importance of a policy-first approach to your enterprise’s goals.

Archived under:
  Join us on LinkedIn for more insights
About the author

As Chief Technology Officer, David has experience leading the design and development of Salesforce’s identity offering including customer identity and access management (CIAM). He is a founding member of IDPro, a co-author of the OASIS XACML standard, and an expert on standard-based authorization as part of an overall IAM implementation.