acciente / oacc-core

OACC (Object ACcess Control) is an advanced Java Application Security Framework
http://oaccframework.org/
Apache License 2.0
107 stars 23 forks source link

define multiple roles for a user with oacc #29

Closed audersch closed 7 years ago

audersch commented 7 years ago

In the feature list of OACC I find the following text "... OACC supports full RBAC ...". My question is: How I can define users with multiple roles?

Following I will describe my current scenario:

The following permissions we must define:

Can anybody help me? Thank you!

audersch commented 7 years ago

Oh, I found the answer her: https://groups.google.com/forum/#!topic/oacc-users/Y9n7VH6KI2w https://groups.google.com/forum/#!topic/oacc-users/Q4Es5UGltXc

fspinnenhirn commented 7 years ago

Thanks for your interest in OACC, Stefan! I'm glad you found what you were looking for before I even saw your question.

Please feel free to let us know if you have any other questions.

Regards, -Fabian

audersch commented 7 years ago

@Fabian: Thanks for your response!

Now I understand, how I can use *inherit. But now I have the following challange. Is there the possibility to define the following?

image

I can't use the functionality of domains, because a specialist can belong to several groups. The same applies to patients.

I tryed the example shown above in my implementation. But I can't checked the permissions like Has S1 the permission read for P1 with the function AccessControlContext.hasResourcePermissions, because the permission read isn't define for the class patient.

adinath-raveendraraj commented 7 years ago

Hi Stefan -- nice work on your progress in understanding OACC capabiilties! Interestingly, the scenario you are trying to model is in a domain we are familiar with. I have a question, and a solution to your problem.

I notice that [group P1] inherits from the patients [P1] and [P2], do you really need this? Typically, a group would have specific (i.e. non *inherit) permission to the objects that it has access to.

So instead of: [group P1] ==(inherit)==> [P1] [group P2] ==(inherit)==> [P2]

It would look more like the following: [group P1] ==(read/write)==> [P1] [group P2] ==(read/write)==> [P2]

Next, it looks like you want [group S1] to inherit the permission of [group P1], you currently have: [group S1] ==(read/write)==> [group P1]

Instead, it should look like: [group S1] ==(*inherit)==> [group P1]

Hope this helps, please let us know if you have more questions.

Regards, Adi

fspinnenhirn commented 7 years ago

Stefan, One of the points Adi was trying to make is that resources typically will not inherit from secured objects directly, but from resources that actually have concrete permissions on the secured objects. Similarly, you normally would not inherit from other authenticatable resources (users) directly, but inherit from a shared role.

I've taken the liberty to draw up a simplified example scenario, to further illustrate OACC's concepts when it comes to modeling RBAC, but please keep in mind that this might not necessarily be a solution to your specific domain.

acciente_visual_example_healthcarespecialties

In this example, we have two practicioners: Alice and Bob. To access patient charts, they don't have direct permission on charts, and they don't inherit any permissions from patients. In fact, a patient is supposed to have less permissions (READ only) on his/her individual chart, whereas Alice or Bob need to be able to WRITE to each chart, as well.

Because both Alice and Bob work at Hospital_A, they inherit READ and WRITE permissions on any patient charts of Hospital_A through global permissions on the ResourceClass-Domain tupel (PatientChart, Hospital_A) from the Practitioners user role. Think of this role as bundling all shared permissions between the different specialties. The global permission here helps with preventing an explosion of permissions for each new patient. In general, it's a good idea to try and find opportunities to employ global permissions when modeling your resources, because then you are unleashing the full power of RBAC. Don't forget, domains are a useful abstraction in your security model for that exact purpose, and they can even be hierarchical.

As you can see, Alice's specialty is RadioDiagnosis, whereas Bob is both a Surgery and Oncology specialist. The RadioDiagnosis specialty acts like a role that grants the additional ANALYSE_IMAGE permission on patient charts. So if you asked oacc.hasResourcePermission(accessor, chartOfPaul, analyseImagePermission) it would return true only when Alice is the accessor resource, and false when it's Bob.

For simplicity, the example diagram doesn't illustrate additional permissions for specialty roles other than RadioDiagnosis, and doesn't show any detail in the other domain.

In summary, the best practices here are as follows:

audersch commented 7 years ago

@Adi & @Fabian: Thanks for your responses and I wish you a happy new year!

I will show, if a can use global permissions. But with this solution I have an other problem (see example from Fabian above): Bob, Alice, Paul and Peter can be only in one hospital. What can I do If Bob works on Hospital_A and Hospital_B or Peter will transferred to another hospital?

If I use the solution from Adi, I have the following problem: If I have a change on the permissions for a group of specialist (e.g. group S1), I must update many relations.

I am afraid that I probably can not solve all my requirements with OACC. Maybe I will have a look for other approaches, for example neo4j.

fspinnenhirn commented 7 years ago

Stefan,

Doctors working at multiple hospitals and patients being admitted to more than one hospital are of course valid use cases and I didn't mean to suggest that OACC does not support these. A resource can be part of permission relationships with any other resource, regardless of which domain it belongs to. I've illustrated another model that takes those use cases into account, below:

acciente_visual_example_healthcarespecialties2

As you can see, I've moved the practitioners and patients into a separate domain. Bob is now a practictioner in both Hospital_A and Hospital_B, simply because he *INHERITs from the respective Practitioners role of each hospital. Similarly to Peter, who now has patient charts in both hospitals, Bob can access both of Peter's charts, whereas Alice is only authorized for the charts from Hospital_A.

The beauty of OACC is that you can model your security graph to fit your needs, and then don't have to worry about implementing the queries that traverse the graph when you are performing an authorization check.

Let me know if you have more questions, Stefan! I'm confident that you can make OACC work for your project, because I've used it in a similar healthcare setting before (;