(Peter Pichler)
if isUserInRoll(“BOSS”) RULES
Best practice from 20 years.
G26 Federation Austria [Government to government]
There was a discussion yesterday about role-based aces control. It is a way how we in Austria organize government to government relations. We have government to government or we have user portals from home organizations of the people with all of the devices of the users of organizations for all governmental applications. This can be a highly sensible application, it can be police-related.
There is something like an application portal, like service provider implementation.
It is better to use a name in a role like “Manager”, “Boss” or however. See picture
The question is “Is this a bad practice or best practice”. In yesterday’s session, policy-based access control, it was described as bad practice.
In Austria government to government federation, this works fine and therefore I would consider this as best practice.
We need to discuss what is manager, is it a technical application-specific role or is it a business role?
My question is if this is bad practice what is best practice?
If this is a technical role than this is the way to do it, because somehow you have to put it into code. If it is a business role this is bad practice.
It is seen as a technical role. This is a solution that…but the alternative approach like a role-based access control approach with policy enforcement point or policy decision point. You pass user and the resource to the policy decision point. The policy decision point has some rules like modern JSON frameworks.
If it is a good practice or not, it depends on the role modeling you make.
Q: Is it a function or is it a service? A: Role is a function from a certain API like java or Microsoft. (//admin) This is just a method from java.
It does not have a policy in that sense. Whatever, this is an APPI defined in the service specification in java. You can put another business logic: This standardized authorization from Java.
Q: You could override the user role and extend whatever is behind that. What is the responsibility of the container, and what is of the application? A: Application makes that and to assign this role to the user is outside of that application.
Q: I am rookie with respect to SAP, but they have certain standardized access control systems where they have matrix organization for transaction etc. A: It is not a very good example.
Does anybody know the rights management …? For me it is an ideal point and every method of interface is one echolontis and you can make role to combine all these things together and then on the other side you have users (open ID or local users). You make robinings between them.
That is a completely new concept. You can call it RBAC
I have not seen many applications doing this in such a clear way.
What is really different to standard RBAC?
The first time I have seen it it is completely implemented and not halfway implemented. Example: Someone made a clear concept of this but nobody is using it. It does not make any sense. This is ok if you have a user in the role manager. If you work on a very cred you have function. If the function is the admin of the complete application. It is not a good idea.
As we established the Austrian app protocol in Austria we have a bad design on the application side. I think this is the essential point. This is not the bad practice. Bad practice is to have a bad role model. Another point is the term role-based access control. It is a very confusing term. You have a user and you have some roles.
I disagree with that. RBAC is, Kuhn has been publishing on that, and definition is: The role is grouping together a number of rights. These are actually rights to do something to target application.
Sometimes they are doing something and sometimes they are just a bunch of people. RBAC is totally fine.
ABAC is different. Example: the path from where I am coming and 2 or 3-factor authentication is mapped in an attribute and this is part of ABAC rule. If you are entering an application from an outside network, you have the same role, but based on ABAC part attribute you have different rights. The roles are same but you are coming from different organization.
This is a policy decision. Another point: The example, internal police in Austria. All police have the same role, and based on location and duty they are different.
In Austria we have applications with resources and resources that have roles rights and … these roles’ rights could be boss and worker. We have resources with diff labels (e.g, boss and worker).
I described this as a mandatory access control system. Because we have resources we define special labels for these resources and we assigned explicitly for our applications more generalized labels because the user has this label.
I think, we are talking a lot about it and it does not make too much sense for me, what is a real meaning of a word, because we have to define how we want to use it that we are able to talk with each other.
The terms role, app role,.., entitlement and privilege are well defined in each specific context. And we have confusion in Austrian government as well.
If you are talking with people from other quality management about roles, they have completely different role definitions. They are different in each specific context. However the terms for RBAC are fairly well defined as I mentioned in “Kuhn”.
I don’t think that the problem lies in IM systems sitting between them. The main problem is sitting on the other side. I am very often in a business to help organizations modeling their organizations and their roles inside organization.
Other part are apps which are not clearly and good designed to help/support RBAC modeling behind them, because you need policy, people, workflows. To define policy you need to file a ticket and to bring business and IT together. You need to bring everybody together and also best thing is to have reviewing cycles.
Q: Would role be something resource-specific, or general attribute? A: It is a group of resource-specific rights. Not organization specific.
The basic meaning of roles in RBAC is more towards the resource side. You have something like job title, job functions and inside there are roles. I mean organization roles.
What university federations have is … the organizational role usually.
Their access management is attribute-based. It is ABAC.
If I am high school teacher, job title is a function: See photo JT->LF->OR
And on the other side: BR->AD->Entitlement and OBR->OR
Most of Austrian government federations have application specification roles, but in the ministry of justice, they have everyone in organizations who have some function in ministry to map organization roles.
In Austria we always discussed global roles. At the moment we are typically on application-based roles and not general roles. Normally I can say minister has role minister. It is a general role.
If you are going back to larger federation like health care you have got global roles. If I am teacher at university, I have an approvement, I have a global role teacher and affiliation to the universities where I am teaching and this is the ABAC part.
Another example is bank branches. The person that has assigned the role branch manager and then you need a context because it is branch manager of a specific branch. You have OU. OU is a specific branch and you would pass it to a specific role. This is not RBAC. In RBAC you cannot pass.
It is a mandatory access system. We have in Austria in the government field someone who may only do what he should do, what is his responsibility.
I know that each MAC mandatory access control can be expressed in RBAC but not other way around.
The typical use case when describing the system was fileX and RBAC is much more general.
The context management system is also good.
Why what we have in BBP is not mandatory to access control?
In mandatory access control, the policy forces you to assign certain access rights to an object.
Mandatory access control does not have any hierarchy concept. It is flat. With resource-specific labels are what we have … RBAC is more expressive but is more hierarchy process.
I don’t think we are different in a technical view. It is just terminology. Maybe I need to read the original paper from “Kuhn”.
In Austrian government: the main problem we have seen down there, most of the apps are pure relying on RBAC. It would have been better if we have had more focus on attribute-based access controls in this area.
We have a clear standard for geographical…
There is a limited standardization for regional and organizational construction. If you would have strict control, then we could have a very strict scheme which would be much easier to implement.
We have a standardized role parameter but it came very late. OKZ (OrganizationKennZahl) means organization ID.
We would be good if we had more standardized role parameters but it is good.
Conclusion: This code is an antipattern. You need to map the technical role in app to a function role (or whatever). First step from app role should be to provide the business readable name for the technical role. For most cases, in general, you have for these 80% standard function that would have VM manager. How much can we deploy? This is typical example form of RBAC. It is an additional attribute. These 6-7 roles are mapped into functional role. Within the application there is a role in a virtual machine. I would say it would be great to have global roles, but it is very difficult to define it. The university failed already.
In Austria, if you are working for businesses, say USP, there should be legally defined roles in laws and they could be mapped and they are mapped. You have roles for a public tender which are clearly defined but they failed to standardize their organizations as well.
