*all and Role based security

jjcnc

Active Member
Hello All

I got a question regarding security. I have two role defined with different securities( apps and action). Both also have *all N N for application. If I assign a user to both this role only one role's secuirty will work. Is this normal and if it is normal I can I go around this. I would like to define different security based on role and give roles access to user ( could be more than one role per useR). Has any one faced this issue?
 
Are both roles entitled to access the environment you are logging in to?

Gerd
 
Yes,

Environment access is not he problem. Once they go in , the Role with higher sequeunce take prioirty in case they choose *all as the role. They can choose individual role then the security fo that role applies. But when they chose *all, security of role with higher security applies.
 
You can run into all kinds of issues when you try to apply multiple roles to a user and want security to be role based. I am currently struggling somewhat with this issue. First and foremost we are using QSoft to manage security as this tool helps a great deal in managing security issues, regardless of which strategy you are trying to implement. I set up security based on roles, for example, a AP clerk needs to have the power user role and the inquiry only role. I apply both roles to the user and both set of securities, inquiry and power user authorities. Problem is the power user security is always going to override the inquiry only security so even if the user applies the inquiry only role, they may have more than inquiry-only access because the power user security is granting them that access. The only work around I know of to defeat this is to create different user accounts for the different roles. Yuck.
 
I am not a security expert, but we have run into this problem also. Our solution is to not allow our users to sign on using *ALL role. They are forced to enter a specific role when signing on. This is a pain for them, but the only way we asure the correct security is being enforced. With HTML client, they can open two sessions, which helps.
 
Hello,

This will not work whenyou use collabrative potal as collabrative portal take *all as the default security ( it wont let you choose the role.
Noiw what I undertand from this is that the this is not a bug, but this exactly how it wil work , which sucks and kind of defeat the purpse of having multiple roles.
 
You can separate the two functions within a single ID by creating a role that is separate from the *all role. We use a role building block concept for 8.10. In this concept, a role is created and given security for a specific function. These building block roles are then combined into the *all role. Some users require a combination of functions with incompatible security. Their primary function goes under * all. Their secondary function role is built like an XE group and is not assigned to *all. They they can chose which way to go at sign in. But, they cannot be in both roles simultaneously.
 
take a look at your Role Sequencing. This stung us as well until we discovered that is was causing us a similar problem.
 
Hello All

This is how I resolved this issue.

Created two role role1 and role2 both the role have seprate application and action secuirty. Role2 have the higher sequence. I put *all NN on role2 only. And I was able to get the desired results.

thank you all for your help
 
When you say "Higher sequence", do you mean the one that is higher up (visually) in the stack, or the one with the higher (greater) numeric value for sequence number ?

THank you.
 
DEAK,
The higher up on the listing a ROLE sits, it overrides the roles below it for the same objects.
So if ROLE_X sits above ROLE_Y
ROLE_Y has Y Y for RUN and INSTALL for an application
ROLE_X has N N for RUN and INSTALL for the same application

You grant both roles to a USER then the results will be. . .
Security works from the bottom up.
ROLE_Y allows the user to run the application then
ROLE_X takes it away so the USER does not have access.

Thus, the inquiry only type access would be granted near the bottom and the more powerful ones higher up on the list.
 
Bob, thanks for your input & example.

Wow, the doc I read from PS describes it quite differently. I can't get to it now. I will reference it in my next post.

It said:

a. the roles are "read" from the top down (low to high seq#)
b. the roles with the higher seq# takes precedence* over a lower number role.
c. *They didn't go into enough detail about the meaning of precedence, but I think means that in the case of conflicting security (and only in that case), the higher # role wins. In the absence of "conflicts", the functionality of *ALL is purely cummulative.

The experts at my place have always said that *ALL gives you the MOST restrictive role. I think that's an oversimplfication. If everything above is correct, then it could just as easily render the LEAST restrictive access, depending on how you've defined and sequcnced the roles.

I certainly need to give more thought to our roles. We haven't done any logical/deliberate resequencing.

Def'n of "conflict", I think, means 1)the same object, 2)same type of security (app/action/etc), 3)different value.

Guess I need to test it myself as everyone else does. Seems to be no black&white answer. Recent Sec Principles class from PS Education was somewhat of a letdown in that they couldn't really nail this down.
 
In role conflicts, the highest numeric sequence value wins. I agree with the list in your email but in row security add table. For example, F0006/MCU security does not conflict with F0901/mcu security. Also, role design is critical. If you mix too many security types in one role, you have fun troubleshooting. Finally, we developed an interactice app which shows all roles, security within roles, and the sequence number of the roles for any given user. It also allows selection of *all vs non-*all roles for a user. This is allowing us to more rapidly identify potential conflicts much greater ease. (see attached screenshot)
 

Attachments

  • 85148-Security review.pdf
    57.4 KB · Views: 218
You are all right, sort of.
If you are looking at the screen for a user that shows the roles that have been granted to that user. . .Forget all the rules.
The list is not in any particular order.
Not alphabetical
Not by date granted
And definitely not by lowest to highest (or vice versa) in true Role sequence.
The only way to know is to do a screen print then go into the Role sequence screen and click the + by each ROLE and note the number given to it.
They are seen from lowest to highest and the higher ones overrule the lower numbered ones.
 
Back
Top