A New Door Opens – Using Attribute Values Passed from Your Application to Impact Filtering
In the latest release of Axiomatics Data Access Filter MD (ADAF MD), we introduced a neat little feature called user-defined symbols. This feature enables you to pass attribute values from the data requesting application, and from these values impact the evaluation of the access control policy and, hence, the filtering of data received by the application.
In this technical blog post, we’ll look at how this new feature can be used to solve a particular business case – namely the need to impersonate a user or delegate access control rights.
Claims manager Bob covers for Julia
In two previous blog posts, which can be found here and here, we used the example of a data access policy for claims managers and insurance claims. We’ll continue to use this example. Here’s the business case for this blog post:
Claims manager Julia, who covers the Gothenburg region, goes on vacation and leaves claims manager Bob in charge of her work. The requirement is that Bob can cover Julia’s work while Julia is away—while, all the time, a stringent and consistent data access policy is maintained.
What can Bob do?
Let us start by looking at the part of the policy that governs what Bob can and cannot do while working on behalf of Julia.
Several things can be said about this rule:
- The protected table is called SCOTT.CLAIM. This table contains information about insurance claims.
- The effect of the rule is to deny modification to three columns in the table SCOTT.CLAIM. The three columns are: POLICYID, APPROVED, and ASSIGNEDTO.
- The rule applies when a claims manager logs in on behalf of someone else and tries to update one or more of the columns mentioned above.
- The boolean attribute called subject.impersonated is used to capture the fact that a claims manager is working on behalf of someone else, in which case it has a value of true.
It is worth noting that this is a simplified way to model impersonation. To implement more sophisticated access control, that is, whether Bob is allowed to impersonate Julia and what data Bob can access in such situations, requires more information being made available to ADAF MD’s authorization engine, namely the identity of both the impersonator and the impersonated subject.
Impersonation using user-defined symbols
Now that the policy is in place, what is needed is to make sure that the subject.impersonated attribute is set to true when Bob logs in to work as Julia. There is more than one way to implement this in XACML; for example the subject.impersonated attribute could be provided by a Policy Information Point (PIP). But in this example, we will use our new ADAF MD feature, user-defined symbols.
Consider the following SQL query produced by the application:
SELECT /*impersonated=true*/ * FROM SCOTT.CLAIM
We set up a user-defined symbol and use ADAF MD ‘s support for regular expressions to extract information encoded in the SQL statement.
Here is the regular expression that we use: “.*/\*impersonated=([^\*]+)\*/.*”
This information is then mapped to an attribute. In this example, we will populate the subject.impersonated boolean attribute.
If the encoded comment is not present in the query or is malformed to the point that the regular expression does not match, then no value is extracted. Consequently ADAF MD does not include the subject.impersonated attribute in the evaluation and the rule does not match. If the extracted value is not a boolean value (that is, not true, false, 0, or 1), ADAF MD blocks the query and returns an error to prevent any potential violation of the policy rule.
Who is the impersonator?
This approach assumes that the support for impersonation can be provided by the application in a way so that when Bob is authorized to work on behalf of Julia, the application indicates that subject.impersonated must be set to true by including a comment in the SQL query. Therefore, in this example, the actual identity of the impersonator is insignificant. However, we should make the point that the policy could be modeled in another way, for example, where the user identity is taken into account.
Business case in action
Here is some sample data for the SCOTT.CLAIM table.
When a client in Gothenburg calls to file a new claim, Bob logs in on behalf of Julia and enters the new claim. To keep the example simple, the application is assumed to authorize claims managers who can work as Julia.
The application that Bob is using issues the following INSERT query:
values (‘C0010’, ‘elsa-dog’, 1000, ‘Brain surgery’, 0, 0, ‘Julia’)
The claim data is inserted as is because Bob is working as Julia and therefore can insert data as Julia. Also there is no rule in the policy that forbids this particular action. In previous blog entries, there is a rule R2 that says that Bob cannot insert claims in regions that are not his own. However, this rule is not applicable in this case because Bob is logging in as Julia.
If Bob needs to update a payment detail for one of Julia’s already approved claims, he will login on behalf of Julia and try to make the update. The application that Bob is using will then issue the following UPDATE query:
update /*impersonated=true*/ scott.claim set amount = 5000 where policyid = ‘oscar-car’
Again, the query will succeed because Bob is authorized to change the AMOUNT while working as Julia. Or, rather, there is no rule that says that he cannot.
In a final example, see how Bob cannot change the approval status for Alice’s pipe replacement claim.
update /*impersonated=true*/ scott.claim set approved = 1 where id = ‘C0009’
This is because the policy does not allow Bob to update the APPROVED column. After the query is executed, the value of the APPROVED column stays the same. See below.
In this blog post, we have showed one example of how the ADAF MD feature user-defined symbols can be used. The example shows how an impersonation/delegation business case can be solved. There are other ways to solve this business case of course, and there are many further business cases that can be solved using user-defined symbols.