Author Topic: User Security in EA  (Read 7064 times)

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
User Security in EA
« on: February 23, 2013, 06:46:24 am »
Hi

I have One repository with multiple projects (root nodes) say for eg - A, B & C.

I have enabled user security and created groups similar to project names. I have assigned few users to these groups.

For example:

user a - Group A
user b - Group B
user c -  Group C

How can i control these users accessing other project data? Like user a should not be able to view/update/delete any of the Project B or C 's data.

Is there a way that the group we created under the project security can be linked to the project root nodes names in the repository?

Thanks
KN

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: User Security in EA
« Reply #1 on: February 23, 2013, 07:04:48 am »
You can create groups like RW_Package1, RO_Package2, etc. Then you can assign users to these groups as appropriate. As long as you are in a single repos this is fine. For multiple repos you need to synch changes to security via im-/export reference data.

q.

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: User Security in EA
« Reply #2 on: February 23, 2013, 07:09:19 am »
I did that...i created Group A - giving that group certain permissions and then i assigned that group to user a.

My concern is because there are many projects within one repository and there are diff teams for diff projects. Hence, say project team of Project A should not be able to see Project B data.

So what permission in Group A (giving such a name to correspond to the project name) should i give that the above is possible - that users in Group A should only be able to Project A data but not other projects - atleast update/delete...

jfzouain

  • EA User
  • **
  • Posts: 152
  • Karma: +6/-1
    • View Profile
Re: User Security in EA
« Reply #3 on: February 23, 2013, 07:12:50 am »
HI

make it simple, just create another project or another Repository if using SQL.
Best regards

Jose Zouain

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: User Security in EA
« Reply #4 on: February 23, 2013, 10:36:14 am »
Quote
I did that...i created Group A - giving that group certain permissions and then i assigned that group to user a.

My concern is because there are many projects within one repository and there are diff teams for diff projects. Hence, say project team of Project A should not be able to see Project B data.

So what permission in Group A (giving such a name to correspond to the project name) should i give that the above is possible - that users in Group A should only be able to Project A data but not other projects - atleast update/delete...
A r/o user has no rights. So the group has no permissions set. For the r/w users set at least the two Update and the Lock permissions. Others permission should be in "global" groups where you can allow to manage  calendars or other things. These groups are assigned to those people which need it.

E.g. you have group RO (which allows to read all content since you can't block reading content). All users will be assigned to that group. Actually you wouldn't need such a group unless you have some special permissions you want to grant to all r/o users (like exporting XMI). Then you have groups RW_packageX for all distinct packages. Assign RW_package1 to User A, B and C; RW_package2 to B and C and FancyOptions to user B. Now A can only edit package1, C can edit 1 and 2 and B can further do some FancyOptions.
q.
« Last Edit: February 23, 2013, 10:42:20 am by qwerty »

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: User Security in EA
« Reply #5 on: February 25, 2013, 07:02:24 pm »
The only way to prevent a certain user to see something in a model is to store this something in a different repository. (and don't give that user access)

A user can read either everything or nothing in a single repository.

Geert

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: User Security in EA
« Reply #6 on: February 26, 2013, 06:51:03 am »
Thanks everyone for the reply
Still have to try the options :)

Will update once I do so.

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: User Security in EA
« Reply #7 on: February 27, 2013, 03:49:22 am »
What is the difference between Manage Locks and User Security?


qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: User Security in EA
« Reply #8 on: February 27, 2013, 04:13:58 am »
Manage Locks allows to set/remove locks on elements/package/diagrams formerly set by users. Manage users will manage the users allowed to set /reset locks.

q.

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: User Security in EA
« Reply #9 on: February 27, 2013, 04:15:05 am »
so with the scenario that i mentioned in my first question about users updating/deleting elements from other project can be maintained with locks...right?

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: User Security in EA
« Reply #10 on: February 27, 2013, 08:30:39 am »
Yes. You set a group lock for the specific group (from an authorized user) and afterwards only members of this group can unlock and edit the according elements.

You need to setup a playground and test how it works.

q.

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: User Security in EA
« Reply #11 on: February 27, 2013, 08:42:29 am »
Thanks qwerty!!

Thts what i was testing right now....its working actually....the only i m figuring out is how to have a master admin...who has control on all projects root nodes/assign users to group/create group etc....found a way to that too....the admin needs to have separate login for each group...

what do you think can be other way?

KN

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: User Security in EA
« Reply #12 on: February 27, 2013, 10:15:27 am »
Quote
A r/o user has no rights. So the group has no permissions set. For the r/w users set at least the two Update and the Lock permissions. Others permission should be in "global" groups where you can allow to manage  calendars or other things. These groups are assigned to those people which need it.

E.g. you have group RO (which allows to read all content since you can't block reading content). All users will be assigned to that group. Actually you wouldn't need such a group unless you have some special permissions you want to grant to all r/o users (like exporting XMI). Then you have groups RW_packageX for all distinct packages. Assign RW_package1 to User A, B and C; RW_package2 to B and C and FancyOptions to user B. Now A can only edit package1, C can edit 1 and 2 and B can further do some FancyOptions.
q.
I thought I was quite clear with this post  :-/

q.

K N

  • EA User
  • **
  • Posts: 98
  • Karma: +0/-0
    • View Profile
Re: User Security in EA
« Reply #13 on: February 28, 2013, 01:53:45 am »
@qwerty: I was doing the way you suggested but probably i just put the same things in my words....and also its my first extensive experience with EA ...thnx for yr guidance  :)

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +396/-301
  • I'm no guru at all
    • View Profile
Re: User Security in EA
« Reply #14 on: February 28, 2013, 03:36:37 am »
I was just struggling over you final question
Quote
what do you think can be other way?

So probably you asked just for an alternative. I guess there is none. It's just noteworthy that the lock can be used vice versa: Require Lock To Edit. This is a good way for concurrent working in a global model, but likely not usable for what you want. I preferred open repositories without special package-privileges. Putting trust into the modelers is a way to motivate them. Assigning locks not so much.

q.