Environments at the User level

[dschleicher]

As background, we have 26 separate legal entities, each of which has their own production environment. We set up Roles with access to all environments, and then at the User level we would assign the specific Environment each user should have access to. We recently installed ESU JK20085 with SAR #8946906 and Environments can no longer be assigned to Users. This is going to substantially increase our security maintenance. As an example. we currently have three Cash Receipt Roles, with varying levels of security access for each Role. Each separate entity may wish to use any/all of these C/R Roles for various staff members at their entity. If we cannot assign Environments at the User level, we would potentially need to set up 78 Roles (3 C/R Roles for 26 Environments), just for Cash Receipts. And this is just for the Production environments; it doesn't even consider Test environments (we have 26 Test environments as well). We have around 20 regular Roles, so this change means we will now need to create/maintain over 500 Roles, most of which are all duplicates with the exception of the Environment that is assigned to each one. We have used our current setup for over 5 years, as we upgraded to 8.10 in April 2005, and now this ESU/SAR eliminates this functionality.

Does anyone else see this as a major issue?

Thanks,

Dave Schleicher
LOGIS
8.12, 8.98.2.3, Windows 2003, SQL 2005, OAS 10.1.3.1

 

[jdel6654]

If you read 647914.1 it says that environments can still be assigned at the user level but JDE recommends not doing so. In other words, this feature still works.

Is there a reason why you don't continue to use envs at a role level? Is it causing a problem for you?

 

[dschleicher]

With ESU JK20085/SAR 8946906, the Environment Row exit is no longer available when a User is selected. Oracle said this application could be customized to make it available, but we would therefore no longer be supported if we had issues in this area.

Our current setup with Environments assigned to the Users continues to function correctly, but our concern is if there is a code change in the future that "breaks" this functionality. We did customize the P0092, but don't want this to be our long term solution; instead, we would prefer they reverse this SAR change so Environments at the User level are once again supported.

 

[KSI]

The problem with env to roles, in Dave's situation, is the roles give access to all environments assigned. There is no way to 'negate' env access, so you end up creating env-specific roles.

We use roles for env access, with the same issues. Roles need to be duplicated for each env they will be accessing.

If there is a way to activiely block env access at the role level, I would like to hear about it.
Example: AR_Role set to envs DV TR PY PD
User given AR_Role and NO_TR_Role to block acess to TR.

 

[brother_of_karamazov]

[ QUOTE ]
With ESU JK20085/SAR 8946906, the Environment Row exit is no longer available when a User is selected. Oracle said this application could be customized to make it available, but we would therefore no longer be supported if we had issues in this area.

Our current setup with Environments assigned to the Users continues to function correctly, but our concern is if there is a code change in the future that "breaks" this functionality. We did customize the P0092, but don't want this to be our long term solution; instead, we would prefer they reverse this SAR change so Environments at the User level are once again supported.

[/ QUOTE ]

I suppose you can thank me for the absence of the Environment exit for users. I submitted a SR asking that administrators no longer be able to perform environment assignment functions that are disallowed/not recommended (i.e. assign environments at the user level). While I would prefer that the environments assignation follow the old rule of User->Group/Role->*PUBLIC if it does not then the ability to assign an environment at the user level should not be allowed. This request resulted in the SAR you reference.

While I am not sure why environments at the user level are no longer recommended I can say that the User->Group->*PUBLIC concept is broken. If one assigns an environment to a user whose role has environments assigned, it will not override the role environment assignment. In order to limit confusion about how this now works (or rather doesn't work), the ability to assign an environment at the user level needed to be removed.

 

[dschleicher]

I do understand the reasoning; however, for us (and maybe other clients) this is a huge issue. As a work-around, is there a way to force users to sign in with *ALL? If so, could we create 26 Roles that don't have any security set up, but only have access to a specific environment? That way we could assign two Roles to each user, one for their Security Workbench security, and the other would restrict them to only their environment.

Or is this not possible, or recommended? Or would it not even work?

 

[cncjunior1]

[ QUOTE ]
I do understand the reasoning; however, for us (and maybe other clients) this is a huge issue. As a work-around, is there a way to force users to sign in with *ALL?

[/ QUOTE ]
Yes, within the JAS.INI you can configure this.

[ QUOTE ]
If so, could we create 26 Roles that don't have any security set up, but only have access to a specific environment? That way we could assign two Roles to each user, one for their Security Workbench security, and the other would restrict them to only their environment.

Or is this not possible, or recommended? Or would it not even work?

[/ QUOTE ]

In the situation you mention above it wouldn't even work. The reason JDE looks at the environments at the role level now is because of the whole '*ALL' option. When you log in as *ALL it looks at the roles the user has assigned to them AND ONLY the roles that have that particular environment assigned to them also. For example, if a user has ROLE1, ROLE2 and ROLE3 assigned to them and ROLE1 and ROLE2 just have access to PY1 and ROLE3 only has access to environment PY2, when the user logs into environment PY1 as *ALL, they are only really logging in with whatever access is defined for roles ROLE1 and ROLE2, because ROLE3 only has access to PY2.

This is why assigning roles at the user level is pretty much a mute point now, because if the role doesn't have access to the environment the user wants to sign into then the user won't have the access to either.

 

[cdawes]

Okay I have to chime in here.

Originally starting on 8.9 with JAS the environments only worked at the ROLE level.

This changed at somepoint and recently looks like it changed again. I'll have to validate to know for sure but on 9.0.1 looks like the roles worked at the user level.

Not sure why this is at environments should ONLY be at the ROLE level. Why else would we have role based security.

I too did enter a SAR bu the SAR was for Portal and not for JAS.

The OPPOSITE situation was occuring for Portal! For JAS you could have environments defined at the user level and at the ROLE and all the user level stuff would just be ignored.

When you logged onto Portal it would read only the user level records - functioning the exact opposite was as JAS. So I requested that this be fixed in a SAR. I assumed that Portal would be made to only read the roles but this may not have occurred and (need to check) I swear I recently saw JAS reading records at the user level.

Again, JAS reading user level environment records makes no sense so I'm hoping my brain has taken a mental holiday and I was just seeing things.


Colin

 

[jdel6654]

I am not sure it is a 'mute' point now. It is not a moot point because you have some situations where you actually want to prevent certain users (eg. consultants) from having access to some enviornments (eg. PD) but you still want them to have access to that same role's security in another environment (eg. PY).

If you assign the specific environments at the user level, you can effectively block them from using the PD environment for that same role.

 

[dschleicher]

I probably should clarify my example of using *ALL to help us with this. So the first role (ROLE_CR) would have access to all environments, and then F00950 records granting appropriate access. The second role (ROLE_EN_PY) would not have any F00950 records, but just have a specific environment assigned (for example, PY). A third role (ROLE_EN_PD) would also not have any F00950 records, and it would only have the PD environment assigned to it. If a user should only have access to Cash Receipts in PY both the ROLE_CR and ROLE_EN_PY would be assigned to them, and the setting would be in place to force a *ALL login. Would this give them their appropriate Cash Receipts access, but only in PY? Likewise, someone that only needs Cash Receipt access in PD would be assigned ROLE_CR and ROLE_EN_PD. Finally, if a user needs access to Cash Receipts in both PY & PD, all three Roles would be given to them.

 

[brother_of_karamazov]

[ QUOTE ]
I am not sure it is a 'mute' point now. It is not a moot point because you have some situations where you actually want to prevent certain users (eg. consultants) from having access to some enviornments (eg. PD) but you still want them to have access to that same role's security in another environment (eg. PY).

If you assign the specific environments at the user level, you can effectively block them from using the PD environment for that same role.

[/ QUOTE ]

I agree, the whole thing should work like security does: User->Group->*PUBLIC

 

[Luke Phillips]

Hi Chaps,

The problem here is that security is cached before the effects of F00950 come into play - so row security on F95921, F0093 etc doesnt work. However security on F95921 is effective - this means that if Fastpath is closed, users wouldnt get to programs that they are only authorised to when inside a different environment from the menu.

Obviously this workaround wouldnt normally be acceptable so we need to request that JDE either implement the user,role,*public hierachy (which would be ideal) or restore it to how it was. They could create an INI setting to either enable or disable the use of F0093s at the user.

 

[Luke Phillips]

I am not sure this would work because when you sign on with *all roles you get only the roles that have the allocated environment. Can you not create row security roles containing access to the relevant companies (F0010)? This would mean that users gaining access to unauthorised environments (companies) couldnt do much.

Another alternative would be to place security on F9000. Obviously this only works if the menu is divided (by company in your case). It is a bit messy though...

 

[hjkl]

We are trying to find a workaround for this change as well. Not quite the 26 environments of the OP but half a dozen at the current count and a security team of two to manage them. Having to create and manage environment specific roles for each one is definately going to create extra work for us.