B2B: Policy Design Best Practices
Role Based Access Contol (RBAC) has dominated authorization for many years and this is especially true when looking across the SAP application landscape. Whilst RBAC solved many of the problems of older access control solutions such as Access Control Lists (ACLs), it also brings its own problems, such as role explosion. Role explosion is where the number of roles grows almost exponentially in order to continue to meet the ever changing business requirements of securing access to applications. In many cases there can actually be more roles than there are users which causes an unnecessary administrative overhead.
This is where Policy Based Access Control (PBAC) comes in. PBAC allows you to use a combination of roles and attributes to build policies that can return an access decision, but the intention is that there is far fewer roles and policies to meet the same authorization requirements. PBAC is a fairly new concept in the world of authorization and it can be a fairly daunting process to create your first policy.
This article aims to guide you through the best practices when building and designing policies, but it does not guide you through a specific policy creation example, as this can be found in other public materials.
Policies are always defined in business language. For example, a policy might be defined as "Account managers can access account data". The benefit to this is that the same policy can be used to provide an access decision to different applications, regardless of the authorization language that they speak. Policies also support the scalability of the organization, so in the above example, it doesn't matter how many accounts there are, the policy will remain true but won't require additional administration to support new accounts.
Policies are built from the policy building blocks; identities, assets and conditions, or as I prefer to say; who, what and when. A policy defines who should have access to what, and under which conditions. There are considerations to be made when building policies from the building blocks.
Roles are one half of the 'who' policy building block, with dynamic groups being the other half.
When we talk about roles in the context of authorization we often think about things like Active Directory groups or technical system roles. These roles typically describe what access someone has, rather than who they are as an identity, but this method can only work when the person assigning the roles understands what access someone will get by assigning a particular role.
When we look at SAP Customer Data B2B, we introduce the concept of delegated administration, which allows members of external organizations to manage their own organization's users. They can invite new users, trigger reset password flows, revoke access and assign roles or attributes. Therefore it's important that the roles that are created in the B2B system can be understood by an external person:
For example, a pharmacy which has several different types of users connecting to a portal to perform their business activities, will know that their users are either a pharmacist, the pharmacy manager or an admin. They would not necessarily know that a pharmacist needs to be assigned to Active Directory group EXT_PH_EU_130 in order to get the access they need.
Roles should describe who someone is as an identity e.g. Doctor, Technician or Manager, rather than what access they should have.
Assets form the 'what' part of the policy and describe what the identities are being given access to. Assets can be anything from documents or products, to system technical roles and will largely depend on what the application expects to receive as part of the authorization decision.
When defining assets, you should always think about what the application expects to receive as part of the authorization decision.
More often than not, you will find that applications expect a list of technical roles to be returned, and therefore, these technical roles become your assets. Through the policy, you can create the link between the identity role e.g. Manager, and the technical role e.g. B2BManagerGroup.
Applications that require a list of roles to be returned as part of the access decision but also use SAML to receive these roles, must use the Claim attribute template, as this is the only template that can be mapped into the Just-in-time (JIT) provisioning configuration.
When defining an asset template you have a choice to create either an internal or virtual template:
It is important to choose the correct type of template to suit the asset. To take an example of SAP Commerce roles that form part of the B2B Accelerator, there are four fixed roles that do not appear to change regularly. These would be defined as internal assets.
Internal assets are typically in much smaller volumes and change less frequently. Virtual assets are typically in larger volumes and can change regularly.
This is not to say that because there are hundreds of assets, the internal template cannot be used, but there may be a larger administration overhead.
The main advantage to using internal assets over virtual assets is that you can ask open questions to the authorization API like "Which roles should this user have?", by making use of the authorization token. The authorization token which returns a list of assets which the user has access to because the assets are actually stored in SAP Customer Data. By using virtual assets you are restricted to asking closed questions like "Should this user have access to role X?", which requires you to pass the asset or list of assets into the request itself.
Use internal assets where possible.
When building policies, you can either link specific assets or groups of assets via dynamic lists. Dynamic lists use one or more asset rules to group assets together based on attributes. You might have rules which classifies documents into public and private based on an attribute value associated with the asset:
Asset rules and dynamic lists should be used where appropriate as they allow for scaling of organization authorization requirements.
Conditions allow you to define under what conditions access should be valid. By centralizing this as part of the policy, you no longer need to rely on changes in the application to make changes to the access requirements, and the same enforcement can be made across multiple applications.
Most commonly, these conditions are time-based such as day of the week or time of the day, but SAP Customer Data B2B also supports other types of conditions that can be passed with the authorization request. For example, the application might know whether the user has completed two factor authentication as part of their initial authentication and want to make this a condition of access to a particular asset. The application could pass this context to the authorization request and it can be used as part of the access decision.
Conditions can be used to remove the dependence on applications to manage the conditions of access.
Once a policy is built with the connected policy building blocks, it must be associated with an application. An application provides a set of credentials to identify a system which is requesting an access decision. By associating an application to a policy you are selecting that policy to form part of the access decision.
Applications should be created for each digital property as this will declutter the access decision response.
Building policies can be a daunting process for Policy Based Access Control newcomers, but well designed policies can reduce the administrative overhead often associated with authorization.
Simplify your data model to include just a handful of roles and use attributes in conjunction to define the 'who'. Make use of asset rules and dynamic lists to group assets together by common attributes.
By following these practices, you will find that you can vastly reduce the number of policies needed to support your authorization requirements.