Tricky multiple roles Security in EO8.9

gerd_renz3

VIP Member
Hi List,
I am trying to implement for the first time security with multiple roles in EO8.9. First I found that really cool and we developed this idea:
A General role would close *ALL apps, then open some basic ones like BV, WSJ. Each user would have this General role and another role according to his/her functions. The General role has lowest priority in the role sequence. This works fine when the user logs on with *ALL roles. But what if some sly person would log on with his functional role only? He would not have the initial prohibition any more and most everything would be open.
Do I need to close *ALL for *PUBLIC? I would not like that because we have a lot of development going on and it would hamper it.
Can I force users to always log on with *ALL roles?
Should I work with two different F00950 tables, one for Production, one for the rest?
Has anybody else worked with E8.9 security yet? Am I missing a point here?


Another question: users seem to be able to drag an drop task (menus) into other locations in Solution Explorer. How can I secure that?


Thanks, Gerd
 
We aren't using 8.9 here yet but...why don't you close *all for *public,
and then the role(s) would open the required security. So for the developers
or IS staff role of say 'developer' would open *all for the group. That is
how we basically have it setup in Xe, with each group opening the areas of
the system required for their group.. 8.9 uses roles, but the idea of
layered security is the same. You have a 'close system' template, and then
each group over rides it with the access they require.
When you do figure it out, let us know, as we will be upgrading to 8.1
next year and will have the same issue..

-John




Xe, Update6 SP19.1_B1
SQL2k SP2, WIN2k SP4
Metaframe XPa SP2
 
Oi Gerd,

Como vai? I haven't played in the EO 8.9 playground yet (that's a project for later this year), but my security model is *public no access. We created some high level user groups like CNC, developer, applead that have wide-open security, but all of the rest are closed. One thing that you need to do is lock down fine-cut for all users other than CNC and a few trusted developers. This will lock down your menus so that users cannot drag items around. I left the favorites view open to my users so that they can create their own custom menus, but the rest of the menu tree is locked down tight.

Tchau,

Gregg Larkin
Administrador De Sistema Norte-Americano
Empresa Uma
 
1) in Security Workbench there is a security type for solution explorer, under that security you can stop users from moving tasks around on you, among other security holes, like allowing anyone to update the documentation on tasks.

2) I think you are missing the point on roles. Multiple roles are an option in OneWorld Xe, the only difference with E8.9 is that they can sign on with the role or *ALL roles. The *ALL is not supposed to be a general role. *ALL is to allow a user who has multiple roles to sign on with the authority of both roles. We have about 20 security groups, who all see different tasks. I set each one of those security groups up as a role. I built a task tree for our company combining all of the tasks that our company uses, then went through the exercize of fine cut/security group to only allow specific roles to specific tasks. Right now, using OneWorld Xe, the users with multiple roles have to right click and select a new role if they want to see the tasks associated with the other role. With E8.9 they will be able to sign on with *ALL for role, so they will be allowed to see all tasks for all roles.
 
Thanks for all the answers.
I guess one point that I was missing when I first played with it was that the *PUBLIC role is still working as it always was. I also found a previous post of Gregg saying that it is recommended to close all doors for *PUBLIC and then open whatever necessary for each role. I would say now that is the ONLY way the multiple role feature will work at all.
But there is still time to get it right. Our GoLive is only after tomorrow, April 1st. And it´s not a joke!

Thanks, Gerd
 
Re: RE: Tricky multiple roles Security in EO8.9

We are live on 8.9 I was asked to tell what we ended up doing, here it is:
We chose all doors close and put that in the *PUBLIC role. We then had a BASIC role that all user would get which opened all basic programs like BV, WSJ, etc.
Then we created roles for GL, AP, AR and so on. Users would get the BASIC and one or more of the fucnional roles. BASIC had lowest priority in the role sequence.
The tricky part was not to close things that other roles would leave open. For example, previously, giving app-security YES on a given programm would not make it necessary to open action security as well. Now it is, because another role could close that partially, even though being on a lower priority.
At one point we added an extra role, added it to a couple of users and then pulled our hair out not knowing, why the extra security would not allow additional programms. We had forgotten to add the PD9 environment to the new role.

So, when previously security was logically like a spreadsheet, now it has an extra one or two dimensions due to the combination of roles and due to the fact that a role can be granted only in some environments.

As things get more complicated we have to get smarter. Otherwise Darwin will get us.

My humble experience with 8.9 security.

Gerd
 
Back
Top