Version 6 of Axiomatics Policy Server (APS) comes with a brand-new web-based Policy Editor which gives the user a completely new and smooth way of working with access policies as well as communicating them. This blog post explains why managing attribute-based access policies will be a seamless user experience (UX) when using the Axiomatics solution.
Putting the User Experience first
Many users have been struggling with writing and maintaining attribute-based access control (ABAC) policies. Firstly, it requires organisations to rethink from role-based access control (RBAC) to ABAC. For instance, organisations can now use a wider range of attributes e.g. citizenship, clearance code, classification etc. Access control is no longer about permissions and roles. Secondly, the workflows for creating, testing, maintaining, and deploying policies have not been as user-friendly as expected by policy authors. With the new Policy Editor, we have been able to create a policy authoring tool which overcomes these barriers to adoption so that the users can focus on the actual content and building of policies.
At Axiomatics we regularly collect feedback from our customers on how they want to work. During our product development we make use of UX tools such as user personas and effect maps where we map any set of product requirement back to a user need and an expected effect on the customer’s business. We work iteratively with interaction design and user tests to make sure that the solution works as intended. For instance, we wanted to speed up the learning phase for users who are not so familiar with building nested logical expressions. In the customer case further below you will understand how it works. The picture below is intended to give you an idea of the design progress.
The new Policy Editor: Anyone can write a policy
The Policy Editor in the Axiomatics Policy Server needs to cater to many kinds of users and their specific needs, since the division of tasks looks different from one customer organisation to another. The policy author may be a knowledgeable security architect, a developer with many other duties, or perhaps a business analyst. The Policy Editor works as a tool for all users: easy enough for the less frequent user, while not in any way limiting the possibilities for an advanced user.
Communicate and collaborate
The strength of the new Policy Editor lies in the ease with which one can switch between a high-level overview of the access policies and the low-level details of those policies.
On a high level, you create and communicate around the policy model in the Policy Design Board (image above).The policy is represented as a horizontal tree structure, which you, the user, can edit directly, for example by adjusting the description or re-arranging through drag & drop.
Note: If you need to manage and understand a large policy, the bird’s-eye view helps you to navigate (image below)
This visual design aims to bridge the gap between IT and the business side of an organization. You can easily explain how a request travels from the root policy down to a rule and how the evaluation sends back a decision. The product also supports multi-user collaboration on a policy.
On the low level, you dive quickly from the tree structure into any policy element to define it accurately, without losing the context. Let’s dive into a simple example in order to understand how this works.
Case: Who can access transaction and balance information?
Let’s open the Banking policy package. Basically, it contains two policies, where the first one is about who can access transactions, and the second one is about who can access a balance.
Note: This structure is resource-centric, meaning that it focuses on the resources first before looking at users and other attributes in the rules. You can choose to write policies in a user-centric way too: just drag & drop your items to reorganise according to your preferences.
A node in this tree structure represents a Policy Set, a Policy, or a Rule: they are the main elements of a policy package. The Policy Set in the above example is described as Banking. You can view and define the detailed content of a node by selecting it.
Let’s select the Transactions policy inside the Policy Set, as shown in the image below.
Note: The rules belonging to the Transaction policy have been minimized so that we don’t have to focus on them right now. This is very handy when working on a larger policy structure.
The selected Transaction policy, with the description Allow access to TRANSACTIONS, applies when the following is true:
the attribute resource-id has the value TRANSACTIONS.
So, when a request is about the particular resource TRANSACTIONS, this policy is applied, which means that the containing rules will be evaluated.
Let’s have a look at the first rule of the Transaction policy. In the image below the Managers can view or add transactions rule is selected. The description of this rule tells us that it will return a PERMIT decision if the following is true:
the attribute “role” has the value manager and
the attribute “action-id” has the value access.
The attribute dictionary in the new Axiomatics Services Manager (ASM) allows you to manage and organize your attributes inside namespaces. The attribute “role” in this example belongs to a namespace called “com.bank”. “action-id” is a standard attribute that comes from the XACML standard.
But hang on! Something is not accurate. The description of the rule says view or add transactions. So, let’s be that specific. First simply change the text field so that it says view instead of access.
Then click the button to formulate the second part of your description (view or add transactions).
Now select the appropriate attribute (action-id), operator (==) and value (add).
Voilà! As a matter of fact most access control use cases can be created this way. We call that a Target.
Let’s look at the second rule described as Users can view transactions in their own region.
This rule is a bit different since it directly compares two attributes. This capability is what makes attribute-based access control (ABAC) much more powerful and flexible than a traditional role-based access control (RBAC) approach.
The rule will return a PERMIT if the following is true:
the user is trying to view transaction, and
if the user is based in the same region as the bank. This last expression is called a condition and is built in a similar way to the target.
Let’s go back to the parent policy.
Note the drop-down box with the value DO. This policy has a Deny Overrides combining algorithm. This means that if any rule yields a DENY, then that DENY wins over any PERMIT decision.
By this case we have illustrated some of the strengths for APS 6 and the new Policy Editor. We see User Experience as a prerequisite to a successful product and the product will continuously be enhanced.
Are you already an Axiomatics customer and would you be willing to help us enhance our products? Email us at [email protected].