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.
Related
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
}
}
}
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.
Every user has one or more roles, every role has one or more permissions. So far I can gather all permissions that are associated to a user via the roles.
The Problem
Some permissions have some constraints. For example:
A user can edit all posts that belong to his site, but no other posts.
Therefore the permission "edit post" should have this constraint.
Regarding the model: If the Constraints are related to the permission, I can't resolve which constraints are active for the particular user.
The user model can have an attribute like "site", but not all users, that belong to one site should have the constraint mentioned above. Some of them should be able to edit all posts.
Question
What is the best way to determine which constraint is active for a particular user. Do I have to split this into seperate permissions and integrate the constraints into the permission model or is there a better solution? I stumbled upon attribute based access control but I am not sure if I should switch to a completely different appoach
Any help is appreciated :)
I replied the following to a previous similar question
You want to use a solution that is agnostic of the type of application it protects. That's the goal of XACML, the eXtensible Access Control Markup Language.
XACML provides attribute-based, policy-based access control (ABAC and PBAC). This gives you the ability to write extremely expressive authorization policies and managed them centrally in a single repository. A central authorization engine (called Policy Decision Point or PDP) will then serve decisions to your different applications.
The minimum set of attributes you will need is typically attributes about the user (Subject), the resource, and the action. XACML also lets you add environment attributes. This means you can write the following type of policy:
Doctors can view the medical records of patients they are assigned to.
Doctors describes the user / subject
view describes the action
medical records describes the targeted resource
of patients describes the targeted resource too. It's metadata about the resource
they are assigned to is an interesting case. It's an attribute that defines the relationship between the doctor and the patient. In ABAC, this gets implemented as doctor.id==patient.assignedDoctorId. This is one of the key benefits of using XACML.
Benefits of XACML include:
- the ability to externalize the authorization logic as mentioned by Bell
- the ability to update authorization logic without going through a development/deployment lifecycle
- the ability to have fine-grained authorization implemented the same way for many different applications
- the ability to have visibility and audits on the authorization logic
HTH
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.
I am working on an API in a system that has very complex access control rules. Often times there are complex SQL queries required to determine if a user has read or write access to a particular resource. This causes a lot of complexity and redundancy in our client applications as they have to know all these rules in order to determine whether to present the user with CRUD options for each object.
My goal is to reduce much of the complexity on the client side and house all the complex logic in the API. This way new client applications written against our API can avoid re-implementing the complex access rule logic on their side when ensuring that the UI only presents valid options to the user.
I am not sure what the best way is to handle this. I'm considering two different options but I don't know if there is a better or more standard way to expose generic access information to callers of an API.
Option 1
When a caller makes a GET request on a resource entity or collection of them, every returned entity will return an _allowed_actions field attached, which is an array of actions the caller is allowed to perform on that entity. For example, requesting a Listing object may result in the following response.
GET /listing/5
{
"id": 5,
"address": "123 Foo Street",
"city": "New York",
"state": "New York",
"price": 457000,
"status": "pending",
"_allowed_actions": ["READ", "UPDATE", "DELETE"]
}
Still unsure how to relate to clients whether they have the authority to create instances of a resource entity using this method, but perhaps the client will simply need to maintain enough understanding of the permission structure to determine this on its own. The access rules around creating instances are typically less complex than the READ/UPDATE/DELETE access rules so that doesn't seem too bad.
Option 2
Create a meta-API, which clients can make requests to in order to determine what actions they can perform on each resource. For example, checking what the client can do with a listing:
GET /access-query/listing/5
{
"allowed_actions": ["READ", "UPDATE","DELETE"]
}
And checking what options are allowed for listings in general, including CREATE:
GET /access-query/listing
{
"allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]
}
The benefit of this approach is that it allows callers to have a full understanding of what they can do on every resource in a generic way. This way clients wouldn't have to understand that the "create_listing" permission AND a non-probationary user status are required required in order to create listings. They can simply query for this information ahead of time.
The downside to this approach is that it increases the amount of requests. Rather than require clients to have an understanding of the permissions logic, they now have to query once to determine what they can do and a second time to do it.
I don't particularly care for either of these methods but they're all I can come up with at the moment. Is there a better way to go about this?
What you are looking for is fine-grained, externalized authorization:
fine-grained: you want to create authorization policies that take into account multiple parameters or attributes and possibly relationships between the client (the requestor) and the targeted entity e.g. a listing in your case.
externalized: you want to decouple the business logic from the authorization logic. In your question you complain about how complex the code and the SQL statements are becoming. This is a direct consequence of not clearly separating business logic from authorization logic.
There is a model called attribute-based access control (ABAC) that defines an approach to fine-grained externalized authorization. NIST, the National Institute of Standards and Technology, has produced a report on ABAC which you can read online.
OASIS, the organization for the advancement of structured information standards, has defined a standard called XACML (eXtensible Access Control Markup Language) to implement ABAC.
XACML brings you:
an architecture as illustrated below
The policy enforcement point (PEP) intercepts your API calls. It protects your API, inspects the messages and sends an authorization request to the policy decision point (PDP).
The policy decision point (PDP) evaluates incoming authorization requests from the PEP against a set of authorization policies written in XACML. The PDP eventually reaches a Permit or Deny decision. To reach decisions it may need to look up additional attribute values from databases, web services, LDAP, or files. These are called policy information points in the architecture.
a policy language: the XACML policy language is attribute-based which means it uses attributes to define what can be allowed and what is not. For instance, you could define rules such as:
a real estate agent can see all the listings if and only if the listing location == the agent location
a real estate agent can edit a listing if and only if he/she owns the listing
a real estate agent can close a listing if and only if the listing's item is sold and if and only if the agent is the person that sold the item.
a request/response scheme: XACML also defines a way to query the PDP and to get responses back. A PDP can be queried either via single questions or via multiple questions in a single request e.g.:
Can Alice view listing 123? Yes, permit.
Can Alice view, edit, or delete listing 123? Permit; Deny; Deny.
With a XACML-based approach, you get to maintain your business logic and your API separate from the authorization logic. This has several benefits:
you can always reimplement the API and keep the same authorization model
you can easily expand your API without having to rewrite the authorization
you can change your authorization logic independently of your code
you can audit your authorization logic more easily
your authorization logic is technology-neutral. It works for REST APIs, web services, databases, and more
I recommend you check out the following resources:
the OASIS XACML website
the ALFA plugin for Eclipse - a free tool to write XACML policies.
The XACML developer community
There are both vendor and open-source implementations of XACML:
Axiomatics is a vendor solution that provides both .NET and Java XACML implementations
SunXACML is a long-standing open source Java XACML implementation
HTH,
David.
Not trying to resurrect an old question, but I came here searching for almost exactly the same thing and wanted to add a solution that I think is more RESTful.
I haven't actually implemented this but think it may help others who come here...
Your second option is very nearly what I think should be done, but instead of a get use the OPTIONS verb to your resource which will then return an "allow" header with a list of available verbs for that resource.
OPTIONS /listing/5
Assuming your resources are fine-grained enough for this to make sense, then you would know if you can make a POST/DELETE