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.
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
}
}
}
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 like to how a 4 eyes principle can be defined in ALFA. (Axiomatics)
For example:
A bank employee wants to create a new account for a customer. He can create it, fill in all the client information and settings. But he needs to be unable to activate this account, unless his manager has approved him to do so.
So, when the bank employee presses the "activate account" button, a policy needs to enforce that his manager has to approve this first. Sounds like an obligation to me, or are there better ways to enforce this with a policy?
Can somebody give me an ALFA example how to doe this?
This is a great question. There are two ways you can do this. As you pointed out, you could use an obligation. Your policy would be as follows:
a user with the role==employee can do the action==activate on a resource of type==bank account if and only the employee created the account --> PERMIT + obligation "pop up approval dialog for manager to sign the activation".
If the PEP fails to comply with the obligation then the account cannot be activated (the decision is switched to a DENY).
Doing so, though, gives the PEP a lot of work (the obligation to implement) and it creates a synchronous flow.
An alternative is to create another attribute to be used in the policy. That attribute could be managerApproved and employeeApproved. That creates an asynchronous flow but it means that you need to keep the values of managerApproved and employeeApproved in a database somewhere.
The policies would become:
a user with the role==employee can do the action==activate on a resource of type==bank account if and only the employee created the account --> PERMIT + obligation "email the manager a link to approve the activation".
a user with the role == employee can do the action==activate on a resource of type==bank account if and only if isManagerApproved==true
a user with the role==manager can do the action==approve on a resource of type==bank account if and only if the creator is in the list of subordinates.
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.
OK, so it's a badly phrased question. But it's hard to explain in a single line.
I've tried to read the Shibboleth documentation and being a newbie got out of my depth fairly rapidly. I don't really want to spend days understanding it if an expert can take half a minute to say "no chance, that won't work".
I have many groups of users, lets say (for now) that groups are different companies.
What I'd like to do is only allow users to see some fields from other companies.
For example I'm Alice in Company A and I can see that Bob in Company B has an email address bob#b.com. He can see that I'm alice#a.com
However everyone else in Company B can see that Bob has a last name and a phone number etc.
And everyone else in Company A can see my details.
To make this more complicated, lets say that Bob and I become friends and decide we want to share our information then we create a "transient" group "alice&bob". Because we are both members of that group, we can both see each others full details. (But nobody else in A can see Bob's details unless they are also friends and vice versa)
I can sort all that out in application code by querying all attributes and relationships and only showing what's relevant but for extra security I'd like to limit the disclosure of information at source.
I think I need to use attribute filters but not sure if they are able to give me this level of control. With this flexibility of being able to form relationships, will I need to build filter files on the fly and then end up with thousands of filters that Shibboleth starts to choke on because the logic is so long.
Something like the "is requester in group" filter rule :
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeRequesterInEntityGroup
The answer above is quite good, but i believe that non shibboleth users will find it confusing.
The quick answer is You really don't want to do it this way, it may be possible to do but for 100% there are better tools to do it.
Ok, full version now (sorry for being too obvious i some places).
In shibboleth architecture we can distinguish two main components.
Identity Provider IdP- which holds information about users from specific organizations.
Service Provider SP - which are generally some service or protected resource, for which we can define some access rules
In your example credentials for Alice and Bob could be stored in different IdP, because they are member of different organizations/companies, or (which isn't exactly matching the whole pattern) you can have one IdP for all users, and "company" is just one of user attributes. IdP doesn't provide you any kind of api that will give you opportunity to access users attributes for any user, apart from the one that is being authenticated.
On the other hand you have your SP, which hold some super secret resources, for which you can define policies. And in which you would like to define polices for user information.
And here lays the problem, on SP side you don't have access to whole users database, that's the way Shibboleth works. You can of course treat all users information as a resource in your SP, but why in the hell would you like to use Shibboleth if you have clear access to all users credentials on you application side?
If you store all users information on you service side I believe that any well designed relational database with some kind of authentication for your service will be better than shibboleth for this job.
Hope that helped.
This is not a job for Shibboleth or for most SAML/SSO providers, for that matter. The attribute filtering you speak of is used for filtering those attributes between the IdP and SP ... which is basically saying : let service provider or "application" B see the following attributes from IdP A.
Once you transmit the attributes to the SP on the other end, Shibboleth does not (and indeed cannot) provide you with a mechanism to prevent users of application B from seeing any data that you present to them ... in fact, they really shouldnt be able to see any data transmitted by the IdP unless you are exposing it in someway via your application.