Hiding models and managing users

[jami]

Hi,
I am building a large repository in the organization.
I plan to build the following structure:
Model1: Architecture repository
Model2: Change repository
Model3: System X repository (requirements, use cases, etc.)
Model4: System Y repository (requirements, use cases, etc.).

The requirement that was set for me is that individual models must be hidden from external companies that may have access, for example, only to Model3.

To do this, I plan to create as many user groups as there will be Models. All internal employees will be added to each group. Thanks to this, when using the "Block and hide model for one group" option, each employee will see everything. External workers will only be added to the group they can see.

A lot of work appears in the case of creating a new Model for the next system. In order to be able to meet the requirement, I will have to add each individual user to a new group for this model.

What do you think about this approach and is it possible to add users collectively to a new permission group? I can import them from AD, I know, but if they are already in EA, it won't help.

[Geert Bellekens]

You can link EA groups to AD groups, and let EA manage all of this automatically.
No more user administration needed.

But be aware that the "Block and hide model for one group" is only a visual aid in the project browser, it's not security.
It will not "really" hide anything from things such as searches etc...
An external user will still be able to query the whole repository.

Geert

[jami]

Thank you for your reply. Yes, I am aware that "Hide..." is only at the Browser level.

But how does a link to ActiveDirectory work?

I tested this option and despite the fact that I have a link to AD, the user must be added to EA to be able to get to the repository. The Sync button works only as user import.

[Geert Bellekens]

You need v15.2

Then you link your group to an AD group in the manage groups dialog
and then you check the box "Automatically create or modify windows users or OpenID users" in the manage users dialog.

This allows you to move all of the user management to AD. Users are automatically created or removed in the correct groups.

Geert

[jami]

Thank you very much. It works!

Do you know if EA is able to get users out of AD in case of group nests in another group in AD?

I noticed that after unpinning a AD group from EA group, users are still assigned to this group in EA.

[Geert Bellekens]

Nesting doesn't work (I reported a bug for that)

The users are removed the moment they try to log-in. So you might still see a user in the manage users dialog, but only when this users tries to login, EA will refresh the AD details and deny the user access if he is no longer in a suitable AD group.

Geert

[jami]

I have one more case. You wrote that adding and removing users is automatic by EA.

I have 3 groups in EA connected with 3 groups in AD.
"User A" is in each of them so that he can see each model blocked for a given group.
But if I remove it from one group in AD, "User A" is still in that group in EA despite unpinning it from AD.
I check the box "Automatically create or modify windows users or OpenID users"

It follows that EA imports users from the attached AD group, but after removing the user from AD, he still remains in EA or am I doing something wrong?

[Geert Bellekens]

I have one more case. You wrote that adding and removing users is automatic by EA.

I have 3 groups in EA connected with 3 groups in AD.
"User A" is in each of them so that he can see each model blocked for a given group.
But if I remove it from one group in AD, "User A" is still in that group in EA despite unpinning it from AD.
I check the box "Automatically create or modify windows users or OpenID users"

It follows that EA imports users from the attached AD group, but after removing the user from AD, he still remains in EA or am I doing something wrong?

The removal from a group happens when the user logs in (or tries)
I have only tested the scenario where I have a user in a single group AD group connected to an EA Group, and then I removed that user from the AD group.
The next time this user tried to open the model he was denied access.

I haven't tested the scenario with multiple groups like you have.

Geert

[jami]

Hi,
I am continuing this thread as a new point has arisen.

I have a problem with the "Hide for other groups" option.
I have the repository configured in such a way that each RootNode has its own user group (integrated with AD). Each RootNode is set to "Hide for other groups" so that external workers cannot see other models. Internal employees are added to each group so they can see the entire repository.

The above configuration works in the company's network on form computers. However, if an external employee connects via a transfer station (he has a company account on it), EA does not import his data from AD, I have to add him to the group manually in EA and, interestingly, the "Hide for other groups" option does not work - he can see everything. If it connects to our company's computer - the models are hidden.

This raises a problem because I will have to set up a separate repository to hide some of the models. Is it possible to somehow configure it without building a separate repository?

I will be grateful for your help.

[Modesto Vega]

My experience with Sparx EA and AD groups is that Sparx EA does not synch or does not synch reliably. Each time we had an issue with somebody been added to an AD group, we solved the problem manually synching the group.

Having said this more details about what do you mean with a "transfer station" and what what type AD you are using - e.g., Azure or on-prem - may help.