How to use XACML and PIP in real application? - xacml

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 xacml 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 xacml Specifications?
My understanding for this is : We can use spring-security 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?

Your question contains 2 questions:
How do I model my policy?
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.
Use the Multiple Decision Profile - this is part of the XACML 3.0 set of optional profiles, or
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 xacml 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:
Call getCarDetails(Object user).
Call the underlying db to retrieve all the cars
Call the PDP in an MDP fashion for all the records found to get a decision
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.

Related

Authorization of List/Search endpoints in REST API

I want to understand how to deal with authorization in REST API with endpoints like below
GET /resource/:id
DELETE /resource/:id
GET /resource
Assumptions
User Bob is authenticated.
Bob only owns resources with id 1,2,4,5,6 but 3
System has an Access Control and Busines Logic Layers
The business layer doesn't have any awareness of data ownership
Access Control Layer has policies for resources and users and it can check if users have the right to access resources and
reject the request with HTTP403 or pass it to the Business Logic
layer to be processed
Scenario
Bob sends a request to GET /resource/2, the application returns resource details with HTTP 200
Bob sends a request to DELETE /resource/3, and the application returns HTTP 403.
Bob sends a request to list resources GET /resources?page=1&pageSize=10, the application returns resource summaries of 1,2,4,5,6 but 3
Problem
The Access control layer can prevent(403) access to a specific resource by checking the claims of the user for a given resource with defined policies.
But It should not be PREVENTED(403) when accessing search endpoints. It should be FILTERED.
Approach 1
It may assumed that search would include summaries of resources that is not owned by the authenticated user.
Approach 2
Search endpoints may be entirely separated and have the awareness of resource ownership and have the responsibility of resolving ownership and filtering.
Other endpoints stay clean by having only business logic.
Questions
Which alternative approach is better?
Is there any alternative?
Am I mixing concepts of data ownership, access control, and business logic?
I think you are mixing these concepts. Let's start from the very beginning:
If a particular user, in this case Bob, is authenticated and his authentication records have policy which defines access to a particular set of resources ( or defines prevention of access to particular set of resources ) then that status should be PREVENTED. Why?
Bob is PREVENTED from accessing particular resources. FILTERED means filtering data and that's something that you can do even when Bob has access to the data. When Bob receives 200 OK status with records that he wanted, internal functionalities of the API can still filter the data that will be adapted to the policy Bobs authentication records hold.
If in our database we have set of records like this: [1,2,3,4,5,6,7,8,9,10]
And we want to create policies that will prevent some users from access a particular record then we can have policies set up in the way where we describe records that define access a particular user has. On example policy can define a record that holds number 3 in a array ( [3] ) and based on this we can create a logic that would obviously filter out the data that's in the array and return [1,2,4,5,6,7,8,9,10].
However, this model heavily depends on how your data is structured. Questions you might want to ask yourself before designing your policy records:
How are my records structured? Do they have records/tables that I can split my data into? If they do, I can define something like <COLLECTION/TABLE_NAME>:<ACCESS_LEVEL> which would in this case yield numbers:* or numbers:[1,2,4,5,6,7,8,9,10].
Can I save access needed into my records? Common practice is to have needed access definitions saved in the records or related records of the data you save. Something like: access_needed: [ "read", "write" ]
Again, it all comes down to your records and based on that you can structure how to define your policy format.

Is the appropriate way to fetch user roles/permissions/information from an ID Token or an API endpoint (or other)?

When creating an Angular web application that also has a backend API, I feel like there are a few different options when it comes to getting User Info such as roles/permissions/display name/email/etc.
We can use an ID Token to store user claims like this. That token can be put into local storage or a cookie and the Angular app can read it and render the UI/guard against unauthorized route navigation/etc as soon as the app spins up (since the ID token is available right then and there).
We can NOT use an ID Token for this information at all and instead have an API endpoint that we have to call every page re-load to fetch this data. The server would decode our access token/ID token and return the data in JSON format.
Lastly, there could be some hybrid solution where basic User Info like names/emails are stored int he ID token and available right away, but user permissions (which could be a larger payload and maybe not wanted in a token that should be small) could be fetched via an API
Is there maybe a 4th option I didn't think about?
I haven't been able to find many conventions around which of these options is the best. I like the ID token option as it requires no "blocking" of the UI until the API request is done making the page load that much faster, but I'm not sure if that goes against other conventions.
All your approaches rely on a permissions-based system where you would have been granted permissions upon login. These are sometimes referred to as birth rights since they are typically given when the user is created or whenever their permission sets change. The typical way to carry birth rights around is to have them as scopes / assertions inside an identity token (e.g. OAUth 2.0) that you pass along from service to service.
You can also have your applications retrieve additional permissions / roles / entitlements from a backend store (a database for instance) based on the user ID so that you know what your user can or cannot do.
So far this is essentially role-based access control / permissions-based access control.
The main challenge with that approach is role explosion / permissions explosion as well as token bloat (too many permissions in the token) and administration pains - you have to assign roles and permissions to users all the time. You have to deprovision. It becomes a management nightmare and a risk you may have the wrong permissions set for users. You then need to think about identity and access governance as well as recertification. Heavy.
What's the alternative?
You definitely need some roles - yes - but they should be kept to a minimum - essentially the business roles you need in your apps e.g. a doctor, a nurse, a non-medical staff rather than doctor_hospital1_unitA.
You should then express your authorization as plain-old English policies using any number of attributes - not just user attributes but also contextual information (time, location), resource information (what type of object, who owns it, where is it? How sensitive is it?), and action information (view, edit, delete...).
Sample Policies
A doctor can view a medical record if they are assigned to the patient the medical record belongs to
A nurse can view a medical record if the medical record is in the same unit as the nurse
A non-medical staff can view the financial section of a medical record but not the medical section.
Attribute-Based Access Control
Following this approach is called attribute-based access control (abac). In ABAC, you clearly decouple your app from the authorization process. Authorization is expressed as policies rather than code which makes it easier to:
update
audit
review
How to implement?
You have several options to implement ABAC (from open-source to commercial). You can go down the XACML (xacml) path, the ALFA alfa path, or others. They all have similar architectures with:
the notion of a policy decision point (PDP): a service that evaluates the authorization requests against the set of policies you defined and produce decisions (Permit / Deny) that can be enriched with additional information e.g. order to do two-factor Authentication.
the notion of a policy enforcement point (PEP): an interceptor that sits in front of or inside your API that will send an authorization request to the PDP.
I've written about the architecture more in detail in this SO post.
ALFA Example
In ALFA, a sample policy would look like:
policyset viewMedicalRecord{
target clause object == "medical record" and action == "view"
apply firstApplicable
policy allowDoctors{
target clause role == "doctor"
apply firstApplicable
rule allowAssignedPatient{
permit
condition patient.assignedDoctor == user.name
}
}
}

XACML Obligations are explanation or ask for more condition

In XACML, I am not sure if Obligations add more information or give more condition to rule decision. For example, I would like the response permits an access to a patient Electronic Health Record, BUT I would like to add obligations to deny access to specific records in the patient Electronic Health Record.
In XACML, obligations (and advice) are meant to enrich the response the PEP receives back from the PDP. They are not meant to convey authorization logic.
Examples
Two-factor authentication
This example revolves around trust / authentication elevation.
Q: Can I transfer $5,000 from A to B using basic authentication?
A: Deny. Reroute user to two-factor authentication page to elevate authentication
Q: Can I transfer $5,000 from A to B using two-factor AuthN?
A: Permit + obligation send email to sender.
Break The Glass
Can Alice view medical record #123?
Deny + obligation: if this is an emergency then wave the 'emergency flag' and request access again.
Can Alice view medical record #123? This is an emergency.
Permit + write inside the hospital the log the fact Alice saw record #123 and claimed this was an emergency.
The aforementioned example comes from the break-the-glass scenario that occurs in healthcare.
Controlling access to a hierarchy of things (items, records)
In your example, you want to control access to items and sub-items. For instance an EHR is made up of PII, PHI, and financial information. Can a doctor view a patient's EHR they have a relationship with? Yes they should be able to. But you'd like to mask or redact the financial information as it is irrelevant to the doctor.
In that type of scenario, I would write different rules - one per sub-item. I want the authorization logic to be visible. I want to know there is a rule about doctors viewing PII, PHI, or financials.
I would potentially use the Multiple Decision Profile to ask questions on the different parts of the record.
Of course, if all you want to do is systematically mask just the one field, then you could get away with an obligation.
Best Practice
When you write obligations and advice, you should try not to hide authorization logic inside them. Use them to enrich authorization flows.

CRUD only for the organization the user belongs to

Background
I'm building a application where all users belongs to a Organization. I only want the user to be able to Create/Read/Update/Delete records in the Organization they belong to.
I'm using sails, but I'm looking for Connect/Express-based, or a standalone answer as sails-permissions node module is unmaintained.
Question
How can one implement a authorization that allow CRUD only for the organization the user belongs to?
We are also not relying on sails-permissions. In our app, users can be members of multiple orgs.
We are using auth0 for all authentication activities, i.e. every request must include a jwt that is included in the request header. The jwt includes userId, orgId and role.
Sails policies decode the jwt and attach userId, orgId and role the the req object for all later checks.
Every model has the property orgId - we are using MongoDB.
Every controller, db operation, etc. adds this verified orgId to the query. Actually we have a small pipeline preparing the query: we add the orgId, in update cases we filter out unwanted property updates, etc.
This approach does not require additional db calls for separation of tenants.
Some models have specific access requirements per individual RECORD. Here we store allowedUser properties (one for read, one for update, etc.) on exactly this record and we extend the query once more so that only records are returned or updated or Xyz where the current user is included in the applicable allowedUsers property.
This approach also does not require additional db calls. This leverages MongoDB-specific query features, though.
We currently do not have ACL-like requirements which would be right between the 2 approaches I described above (re access control granularity).
You'll need to intercept each request using middlewares
combine them with a role system by checking if a certain token is present on request headers and in a acl map and finally, if the token is present in the acl map, see which permissions are related with this token.

XACML Policy Enforcement Point (PEP) Best Practices

I have the following scenario:
in a business workflow many decisions regarding different arguments must be taken.
eg: first check user roles, then do some business logic, then check business permission, ecc...
my question is:
assuming that on the PDP there are many policies for each of that arguments,
should the PEP do a single (big) xacml request to the PDP, containing all the attributes (eg: user roles, buisiness attributes, ecc)?
or
should the PEP do multiple (short) xacml request to the PDP, containing just one kind of attributes (eg: first call with user roles, second with business attributes, ecc..) ?
thank you
The PEP should never be aware of how many policies the PDP has let alone how they are structured. In addition, you should have one request per authorization question. If you have multiple use cases e.g.
create transaction
view transaction
print transaction
approve transaction
then you should do 4 independent XACML requests. 1 XACML request = 1 authorization request. If you created a single XACML request with a huge number of attributes, you wouldn't actually be asking 4 separate questions but rather a weird mix whereby you might be permitted if any of the provided attributes triggered a Permit (and of course that all depends on the policies and combining algorithms you have).
To save on roundtrip time (transport cost...), you can use the Multiple Decision Profile of XACML (MDP) whereby you can ask in one go:
Can the user create, view, print, approve transaction X?
The Axiomatics Policy Server implements the Multiple Decision Profile. You can read this blog post to understand how to create the request.
HTH,
David.