- SAP Managed Tags:
On Tuesday 10th March we presented the latest Customer Data Cloud Webinar with the focus on how to unlock your journey with a foundation of success. The presenters of the session were:
In this webinar, we introduced Policy Based Access Control and took a deep dive into the policy building blocks, before showing a working demonstration of how we can understand what access different user personas should have via real time API calls. You can find a link to the recording here.
This blog post focuses on the steps required to build the policies which are necessary to achieve the correct access control for the following document access use case:
The end goal is to make an API call which returns a list of documents which are approved or rejected for access:
Before we attempt to build a policy, it is first important to define what Policy Based Access Control (PBAC) is and what problems it solves versus traditional access control mechanisms such as Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC).
PBAC allows you to define policies which can use both roles and attributes to enforce an access decision. This typically allows you to create a much smaller number of policies than you would need roles, if using RBAC, but also supports use cases where attribute assignment is not possible, if using ABAC.
The other benefit is that the effect of the policy is not just localized. Different entry points can consume the same policy, even if they speak different authorization languages. As an example, you could have a policy which is ‘Account manager can access their accounts data’. A business owner can understand that language, but what does it actually mean? It might mean access to specific records in a CRM but maybe the same accounts are also available in another system. We want to enforce the same decision across entry points.
So, what is a policy? Simply put, a policy defines who, can access what, and under what conditions (when).
To build a policy, we must first construct the policy building blocks, which map to the policy definition we outlined in the previous section:
Let's take a look at our original use cases and create the configuration for each of these building blocks.
We can identify a number of personas from the original use case, including Staff, Manager and Editor, and these becomes roles which identify the people who need access. These roles are created under the Identity menu:
The other requirement which also relates to the 'who' is to only allow access to documents from the staff members country. However, we can meet this requirement as part of the 'what' configuration, so no further setup is needed here.
We are trying to protect access to documents in our use case, and therefore the 'what' becomes very easy to define. However, there are a number of components that need to be configured before the building block can be added to a policy.
Firstly, we define actions that can be performed for our document, which in our case were view and edit. Of course, actions like delete or archive are also valid document actions, but are not needed for our particular use case. So, the first thing we create are our actions:
Next, we create an asset template that defines what we are accessing. A template defines a set of attributes associated to an asset, which can be used as part of the policy. Of course, a document can have many attributes such as name and file type, but in our scenario there are two important attributes which are necessary to define in order to achieve our goal:
We create the asset template and associate our previously created actions to it:
The most important configuration when creating this document template is the repository type. Here we select Virtual Repository, which indicates that we will not store instances of this template within the Customer Data Cloud platform. As a general rule, when choosing whether an asset template is internal (instances are created and stored) or virtual, we should look at the following criteria:
Where we have either a large volume, or a constantly changing list of assets, such as documents, the assets should be virtual.
Next, we define asset rules. An asset rule allows you to define a condition which must be met in order for the policy to apply to an instance of a document. In our case, we'll use asset rules to meet the following requirements:
We first create a rule which allows us to identify documents which are secure. We can do this by looking for a true value in the Secure attribute we defined on the asset template:
Next, we create a rule to identify documents from the same country as the user. In this asset rule, we are actually comparing the value of the Country attribute which we defined on the document asset template to the profile.country attribute of the Customer Data Cloud user account:
This rule allows the policy to dynamically determine whether a user should have access to a document by comparing attributes on both the 'who' and 'what' sides of the policy in real time.
The final step of the 'what' definition are creation of dynamic lists. Dynamic lists are an extension of asset rules, except a dynamic list can contain one or more asset rules, which allows us to perform and/or operations across multiple rules. In our example, we create a few lists which allow us to meet the requirements defined previously. The first list combines both the country specific documents and secure documents rules:
The second list includes only the country specific documents rule:
Even if there is only one rule associated to a dynamic list, it must still be created, because dynamic lists can be directly associated to policies, whereas asset rules cannot.
The requirements clearly state that documents should only be accessible on weekdays, and this defines the 'when', or conditions of access. We configure a time-based condition to support this use case which includes the days Monday to Friday:
It would be possible to configure a further time-based restrictions as part of this condition, but for our use case, it is not defined and therefore not required.
Now that we have created all the necessary policy building blocks, the next step is to connect them altogether as part of a policy. We have created three policies to meet our requirements:
If we ignore the third policy, which allows general country based view access, we can take a look at how the others are built.
To allow managers to view secure documents we need to first connect the Manager role on the left side (brown). Next, we connect the secure documents in country dynamic list (blue) to the right side. We also link the weekday condition to the left side (red). Finally we associate an application (purple) for which the policy is applicable.
To allows editors to edit any document, regardless of country, we first connect the Editor role to the left side (brown). Next we connect the all documents dynamic list (blue) which does not include the country specific document rule and therefore selects all documents. Finally we link the weekday condition (red) and application (purple):
Now we've finalised the policies as per the requirements, and are ready to request an access decision via API call.
The Customer Data Cloud platform allows applications to make real time API calls to determine access. There are two types of requests:
The type of request which can be made is largely based on the type of asset (internal vs. virtual) that is created. The authorization token returns a list of assets where access has been granted, and therefore requires that the assets are created as internal assets. The authorization request returns a permit/deny response and expects an instance of the asset to be passed into the request itself.
So, in our use case, we've defined a document asset template, but we've chosen to not store them as internal assets. Therefore, we pass instances of these assets into the request. We are essentially asking Customer Data Cloud the following question:
Do this user have access to view and/or edit the following documents?
When making the request to Customer Data Cloud, we need to pass the context of the user and the list of assets (with actions) that we are asking about. As an example, we'd pass the following request body:
The identity ID which is passed is the users Customer Data Cloud UID. The organization context is the organization that the user is associated to. We must pass this context because the user can be associated to more than one organization for which they might have different access.
Finally, we pass the list of documents, as defined by the asset template:
In the above example, we have a mixture of documents, including secure, non-secure, UK and German documents.
The decision we receive will depend on both the role and country attribute value of the user who is passed in the request. If, for example, our user is an Editor in Germany, we'd expect the following response:
The reason for this response is that Editors should be able to edit any document, regardless of document country. If we made this same request on a Saturday, we would expect all of the documents to appear in the list of rejected assets.
This ends our blog post which discusses how we can use the SAP Customer Data Cloud platform to easily setup Policy Based Access Control to meet complex access control requirements.
To learn more about Customer Data Cloud, please sign up for our next webinar on the 31st of March.
- Petra Ligthart – Senior Product Marketing Manager, SAP Customer Data Cloud
- Ed Knight – Technical Architect, SAP Customer Data Cloud
In this webinar, we introduced Policy Based Access Control and took a deep dive into the policy building blocks, before showing a working demonstration of how we can understand what access different user personas should have via real time API calls. You can find a link to the recording here.
This blog post focuses on the steps required to build the policies which are necessary to achieve the correct access control for the following document access use case:
- Staff should only be able to view documents from their country
- Only Managers should be able to view secure documents
- Only Editors should be able to edit documents
- Editors can edit any document, regardless of country
- Documents should only be accessible for viewing or editing on weekdays
The end goal is to make an API call which returns a list of documents which are approved or rejected for access:
Policy Based Access Control
Before we attempt to build a policy, it is first important to define what Policy Based Access Control (PBAC) is and what problems it solves versus traditional access control mechanisms such as Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC).
PBAC allows you to define policies which can use both roles and attributes to enforce an access decision. This typically allows you to create a much smaller number of policies than you would need roles, if using RBAC, but also supports use cases where attribute assignment is not possible, if using ABAC.
The other benefit is that the effect of the policy is not just localized. Different entry points can consume the same policy, even if they speak different authorization languages. As an example, you could have a policy which is ‘Account manager can access their accounts data’. A business owner can understand that language, but what does it actually mean? It might mean access to specific records in a CRM but maybe the same accounts are also available in another system. We want to enforce the same decision across entry points.
So, what is a policy? Simply put, a policy defines who, can access what, and under what conditions (when).
Policy Building Blocks
To build a policy, we must first construct the policy building blocks, which map to the policy definition we outlined in the previous section:
- Who
- What
- When (or other conditions)
Let's take a look at our original use cases and create the configuration for each of these building blocks.
Who can access?
We can identify a number of personas from the original use case, including Staff, Manager and Editor, and these becomes roles which identify the people who need access. These roles are created under the Identity menu:
The other requirement which also relates to the 'who' is to only allow access to documents from the staff members country. However, we can meet this requirement as part of the 'what' configuration, so no further setup is needed here.
What is being accessed?
We are trying to protect access to documents in our use case, and therefore the 'what' becomes very easy to define. However, there are a number of components that need to be configured before the building block can be added to a policy.
Firstly, we define actions that can be performed for our document, which in our case were view and edit. Of course, actions like delete or archive are also valid document actions, but are not needed for our particular use case. So, the first thing we create are our actions:
Next, we create an asset template that defines what we are accessing. A template defines a set of attributes associated to an asset, which can be used as part of the policy. Of course, a document can have many attributes such as name and file type, but in our scenario there are two important attributes which are necessary to define in order to achieve our goal:
- Secure - flag defining if the document is a secure document
- Country - defines the country which the document belongs to
We create the asset template and associate our previously created actions to it:
The most important configuration when creating this document template is the repository type. Here we select Virtual Repository, which indicates that we will not store instances of this template within the Customer Data Cloud platform. As a general rule, when choosing whether an asset template is internal (instances are created and stored) or virtual, we should look at the following criteria:
- What is the volume of assets?
- How often do the assets change?
- Are assets already managed in another system?
Where we have either a large volume, or a constantly changing list of assets, such as documents, the assets should be virtual.
Next, we define asset rules. An asset rule allows you to define a condition which must be met in order for the policy to apply to an instance of a document. In our case, we'll use asset rules to meet the following requirements:
- Only Managers should be able to view secure documents
- Staff should only be able to view documents from their country
We first create a rule which allows us to identify documents which are secure. We can do this by looking for a true value in the Secure attribute we defined on the asset template:
Next, we create a rule to identify documents from the same country as the user. In this asset rule, we are actually comparing the value of the Country attribute which we defined on the document asset template to the profile.country attribute of the Customer Data Cloud user account:
This rule allows the policy to dynamically determine whether a user should have access to a document by comparing attributes on both the 'who' and 'what' sides of the policy in real time.
The final step of the 'what' definition are creation of dynamic lists. Dynamic lists are an extension of asset rules, except a dynamic list can contain one or more asset rules, which allows us to perform and/or operations across multiple rules. In our example, we create a few lists which allow us to meet the requirements defined previously. The first list combines both the country specific documents and secure documents rules:
The second list includes only the country specific documents rule:
Even if there is only one rule associated to a dynamic list, it must still be created, because dynamic lists can be directly associated to policies, whereas asset rules cannot.
When is the access valid?
The requirements clearly state that documents should only be accessible on weekdays, and this defines the 'when', or conditions of access. We configure a time-based condition to support this use case which includes the days Monday to Friday:
It would be possible to configure a further time-based restrictions as part of this condition, but for our use case, it is not defined and therefore not required.
The Policy
Now that we have created all the necessary policy building blocks, the next step is to connect them altogether as part of a policy. We have created three policies to meet our requirements:
- Managers can view secure documents
- Editors can edit documents
- Staff can view documents
If we ignore the third policy, which allows general country based view access, we can take a look at how the others are built.
To allow managers to view secure documents we need to first connect the Manager role on the left side (brown). Next, we connect the secure documents in country dynamic list (blue) to the right side. We also link the weekday condition to the left side (red). Finally we associate an application (purple) for which the policy is applicable.
To allows editors to edit any document, regardless of country, we first connect the Editor role to the left side (brown). Next we connect the all documents dynamic list (blue) which does not include the country specific document rule and therefore selects all documents. Finally we link the weekday condition (red) and application (purple):
Now we've finalised the policies as per the requirements, and are ready to request an access decision via API call.
The Access Decision
The Customer Data Cloud platform allows applications to make real time API calls to determine access. There are two types of requests:
- Authorization request
- Authorization token
The type of request which can be made is largely based on the type of asset (internal vs. virtual) that is created. The authorization token returns a list of assets where access has been granted, and therefore requires that the assets are created as internal assets. The authorization request returns a permit/deny response and expects an instance of the asset to be passed into the request itself.
So, in our use case, we've defined a document asset template, but we've chosen to not store them as internal assets. Therefore, we pass instances of these assets into the request. We are essentially asking Customer Data Cloud the following question:
Do this user have access to view and/or edit the following documents?
Making the API call
When making the request to Customer Data Cloud, we need to pass the context of the user and the list of assets (with actions) that we are asking about. As an example, we'd pass the following request body:
{
"identity": {
"id": "6d7fdb8c4b914e5a9603392cceae1d95"
},
"context": {
"organization": "f7ea0d72-69f4-4fee-9039-72a17720362f"
},
"assets": [{
"type": "Document",
"path": "Document 1",
"actions": ["edit"],
"attributes": {
"Name": ["Document 1"],
"Type": ["pdf"],
"Secure": ["false"],
"Country": ["uk"]
}
},
{
"type": "Document",
"path": "Document 2 (secure)",
"actions": ["edit"],
"attributes": {
"Name": ["Document 2 (secure)"],
"Type": ["pdf"],
"Secure": ["true"],
"Country": ["uk"]
}
},
{
"type": "Document",
"path": "Document 3 (secure)",
"actions": ["edit"],
"attributes": {
"Name": ["Document 3 (secure)"],
"Type": ["pdf"],
"Secure": ["true"],
"Country": ["de"]
}
},
{
"type": "Document",
"path": "Document 4",
"actions": ["edit"],
"attributes": {
"Name": ["Document 4"],
"Type": ["pdf"],
"Secure": ["false"],
"Country": ["de"]
}
}
]
}
The identity ID which is passed is the users Customer Data Cloud UID. The organization context is the organization that the user is associated to. We must pass this context because the user can be associated to more than one organization for which they might have different access.
Finally, we pass the list of documents, as defined by the asset template:
- Type is the name of the template
- Path is a unique ID for the instance of the template
- Actions are the actions for which I'm asking the access question for
- Attributes contain the attribute values which are associated to that particular instance of the asset
In the above example, we have a mixture of documents, including secure, non-secure, UK and German documents.
The decision we receive will depend on both the role and country attribute value of the user who is passed in the request. If, for example, our user is an Editor in Germany, we'd expect the following response:
{
"approved_assets": [
{
"action": "edit",
"type": "Document",
"path": "Document 1",
"attributes": {
"Type": [
"pdf"
],
"Secure": [
"false"
],
"Country": [
"uk"
],
"Name": [
"Document 1"
]
}
},
{
"action": "edit",
"type": "Document",
"path": "Document 2 (secure)",
"attributes": {
"Type": [
"pdf"
],
"Secure": [
"true"
],
"Country": [
"uk"
],
"Name": [
"Document 2 (secure)"
]
}
},
{
"action": "edit",
"type": "Document",
"path": "Document 3 (secure)",
"attributes": {
"Type": [
"pdf"
],
"Secure": [
"true"
],
"Country": [
"de"
],
"Name": [
"Document 3 (secure)"
]
}
},
{
"action": "edit",
"type": "Document",
"path": "Document 4",
"attributes": {
"Type": [
"pdf"
],
"Secure": [
"false"
],
"Country": [
"de"
],
"Name": [
"Document 4"
]
}
}
],
"rejected_assets": []
}The reason for this response is that Editors should be able to edit any document, regardless of document country. If we made this same request on a Saturday, we would expect all of the documents to appear in the list of rejected assets.
Conclusion
This ends our blog post which discusses how we can use the SAP Customer Data Cloud platform to easily setup Policy Based Access Control to meet complex access control requirements.
To learn more about Customer Data Cloud, please sign up for our next webinar on the 31st of March.
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
