1
votes

How to cover following scenario using XACML (with WSO2 PDP) and PIP (if required).

In Used Car application, in particular location, salesperson are allowed to view-update car price. They can only view cars which are assigned to them.

Now from a prespective, we can create policy for salesperson role and based on location hide the particular menus.

But what to do with the method getCarDetails(Object User){...}?

here based on UserID (salesperson) we will show the list.

How to design this with Specifications?

My understanding for this is : We can use and add "salesperson" role on top of this method. But it will only restrict other users from different roles. from there I am confused that should we use database call as per our traditional applications with userid and get the list of cars or is there a way to get fine-grained access with xacml?

1
Where does your question re. PIPs come in?David Brossard

1 Answers

2
votes

Your question contains 2 questions:

  1. How do I model my policy?
  2. How do I protect my application? (Enforce the decisions)

First of all, let's model your policy in ALFA:

Rule: A sales person can view a car if and only if the car's assigned salesperson identifier is equal to the requesting user's identity.

In ALFA, this becomes:

namespace com.axiomatics{
    /**
     * A sales person can view a car if and only if the car's assigned salesperson 
     * identifier is equal to the requesting user's identity.
     */
    policy viewCars{
        target clause user.role=="sales person" and actionId == "view" and objectType=="car"
        apply firstApplicable
        /**
         * 
         */
        rule allowAssignedUser{
            permit
            condition car.assignedSalesPerson==user.identifier
        }
    }
}

That's your modelling sorted.

Now, with respect to the second question: how do I enforce the authorization? I would argue against mixing roles managed by Spring Security and XACML policies unless you correctly document them.

There are two approaches you can take.

  1. Use the Multiple Decision Profile - this is part of the XACML 3.0 set of optional profiles, or
  2. Use the Reverse Query approach - this is specific to Axiomatics only. I am not sure WSO2 supports it.

The Multiple Decision Profile (MDP) defines how you can send multiple authorization requests written in to a Policy Decision Point (PDP) using a single request. This saves you several round-trips. The response you will receive will contain as many decisions as authorization requests in the original request sent. You save on transport time and on evaluation time too. Use the MDP when you know how many items you want to protect and when that number is anywhere between 1 and 1,000 but not greater (though, of course, it is always worth a try). You can read more on the MDP on the Axiomatics blog. In your case, the flow would be as follows:

  1. Call getCarDetails(Object user).
  2. Call the underlying db to retrieve all the cars
  3. Call the PDP in an MDP fashion for all the records found to get a decision
  4. Return only those records for which you had a Permit

The main drawback is that you may end up receiving thousands if not millions of records from the database. Using the MDP then is not practical.

The Reverse Query approach is interesting albeit specific to Axiomatics. It defines a new interface on top of a XACML PDP which lets you query the authorization engine in a reverse way. Instead of asking:

  • Can Alice view car #123?

The Reverse Query lets you ask

  • Which cars can Alice view?

Instead of the response being a Permit or Deny, the response is a filter expression such as a SQL statement e.g.

  • SELECT id FROM cars WHERE assignedSP='Alice';

All you have to do then is use the SQL statement against your database to query it and return only the entitled data. This works no matter how much data you have in your database. You can find more information on the ARQ SQL via this webinar.