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.
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
}
}
}
I tried to understand RBAC in order to determine if it is a good solution for our problem.
Let say that the context is a bank. Among the several actors, we have account managers and clients.
I think I have understand RBAC for the account manager. If we imagine Account Managers can create, modify, view and remove accounts, then:
Account Manager is a role,
create, modify, view, remove are the operations,
accounts are objects
create account is one of the permissions associated to the role Account Manager
But my problem is about clients ... They can consult only their accounts.
My problem is: How can we specified this particular account in RBAC? Is it at least possible or must I choose another way of manage access control? And which of them?
As mentionned, Attribute based access control may be the good solution. And XACML could be used in an application with complex policies.
Here is a very understandable documentation about ABAC in Spring Security
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.
I have two trusted web properties Product A and Product B where I want to find or create a corresponding account on Product B using email whenever I create an account on Product A. What's the proper way to accomplish that in the realm of OAuth2?
To put it another way, from my understanding, regular Oauth2 flow will require the user to manually authorize Product A to access Product B by redirecting user to Product B to login or create a user before continue on Product A. I'd like to skip this step and allow account on Product B to be automatically created without user interaction. I can think of some custom ways to accomplish it, but how do I achieve that following OAuth2 best practices?
Why create the account?
OAuth has no abilities to create or to modify an account.
OAuth only provides DELEGATION of permissions by the end-user to an application.
Often sites will create a unique Identity Information Entry on their site to store site specific preferences or "tracking" information in that entry. Hoe this is performed varies widely but SCIM is fast becoming the "Standard" method to use.
-jim
All my seniors, I have a security rule for Human Resources Employee and Contract.
If user is manager role, user can see all data in contract including wage (salary). Otherwise, if user is assistance HR role, she can see all contract data except employee wage.
Can I hide (invisible) fields in OpenERP with related security? Can I create a security rule like that? Need any access right mechanism.
In the XML side of this field wage, you just need to add the manager group. For example:
<field name="wage" groups="base.group_hr_manager"/>
Now only the user having the HR manager permission can see this field. No others will be able to see this
Yes you can do it in OpenERP. Apps have already common access rights to use for security purpose. but even you can modify for particular users.
For that you have to use GROUPS. Groups is specific group of people can assign some specific validations. I have already answered regarding this. You can find it here