Package level security

[Modesto Vega]

We have enable package level security in our repository. We are in the process of creating groups but have hit an unexpected obstacle.

I was under the impression that I could control access rights on a per package basis. However, I cannot seem to find a way of assigning groups to specific packages. Have I missed/misunderstood something?

If I cannot use package level security this way, how do I stop users from having full control over certain packages?

P.S.: We are using v13 but can upgrade to v14.

[Modesto Vega]

Let's me expand on this to see if I can get an answer, let's say I have a repository with the following structure:

Model 1
----> Use Case Model
----> Class Model
----> Component Model
----> Deployment Model
----> Project Model


Model 2
----> Use Case Model
----> Class Model
----> Component Model
----> Deployment Model
----> Project Model

The question are as follows:

• Can I have a group, let's say Business Analyst, with write access to the 2 Use Case Models and read only access to the 2 Class and Components models?
• Can I further restrict a group like this to restrict access to the relevant models in, let's say Model 2?
• Can I have a group, let's say Administrators, with full access to all models?

The missing link appears to be how to assign a group to a model or package - e.g., Model 1 or Model 1\Class Model, Model 2\Component Model.

Can I actually do this? Have I dreamt it?

Edit: All groups appear to apply to all models and package which means I don't seem to be able to restrict operations on models\packages depending on project roles. I certainly do not want business analysts or technical project managers messing around with class, component or deployment models.

[Geert Bellekens]

You could, if you use group locks.

Setup security and the proper groups.

Set a group lock on the use case packages for the Business Analyst group.
Now only members of the business analyst group will have write access to the elements in this package

Geert

[Modesto Vega]

Thanks Geert, security is set to Require User Lock to Edit. Groups are created. But how do I set up a group lock, this is the missing part (and the documentation does not help).

[Geert Bellekens]

You can't combine "require user locks to edit" and group locks AFAIK.

Geert

[Modesto Vega]

You can't combine "require user locks to edit" and group locks AFAIK.

Geert

I think that you are right, they are incompatible. I almost got this working but hit a couple of oddities. I'll update once I have overcome them.

[Modesto Vega]

Oh well!!! Nothing is straightforward with Sparx EA. This is what I found with v13 and will try the same with v15:

• I can only put a Group Lock in package if the user applying the group lock belongs to the group applying the lock. It does not matter if the user is an Administrador, if the user applying the lock is not in the group, the group does not appear in the lists of available groups
• When applying locks with “require user locks to edit” disable, there is an option called ”User lock - lock this Package so that only you can make further edits; other users cannot unlock or edit the Package” which appears to be equivalent to “require user locks to edit”
• Only one group can lock a package. It not seem to be possible to have 2 groups with a lock on the same package but different permissions. This is a bit annoying, specially with nested packages.
• At least in v13, a group cannot be made a member of another group. This would be an elegant way of working around the 1st problem instead of having to add individual administrative user to each group

[Paolo F Cantoni]

Hi Modesto,

We're about to turn the paradigm on its head.  In the past, we've created groups based upon the roles/agency etc.  Data Architect, Solution Architect, Business Analyst etc.

In our repository, we have Enterprise level branches and Project-based branches.  We're going to try to assign groups to the various branches. So we'll have things like
Enterprise Present, Enterprise Roadmap, Enterprise History, Project 1, Project 2 etc.
Each user will then be assigned to the groups (branches they can modify).  So, for example, I. as Modelling "God", can change every branch.  This Solution Architect can work on Project 1 and Project 3, their assigned projects.   That Enterprise Architect can modify Enterprise Present, Enterprise Roadmap, Project 3 and Project 5 - the projects they have oversight for.  Only "God" can modify Enterprise History - since it is a set of immutable snapshots taken at points in time.

We haven't implemented it yet, but that's our plan.  It may be a viable solution for your Use Case.

Feedback welcome, especially before we implement.

Paolo

[Modesto Vega]

Based on our experience you may face several problems:

• It is really package level security and not model level security (I think you know what I mean)
• AFIK (v13/v14), you cannot assign 2 groups to a model or package. This has significant implications (please keep reading)
• Your package hierarchy (including Models) needs careful consideration, specifically how deep it is and how specialised the packages are. There are various ramifications to this
• Because only one group can be assigned to a model, applying model based security may be problematic. You probably need to use package level security for each model. For example, if you keep business, enterprise, IS and data architecture within the same model and you need/want to restrict what people working in each area can do in the other areas, model level security doesn’t allow you to that, you need to set security for each package in the model.
• Irrespective of your chosen approach on the previous point, AFIK you cannot give your business analysts and architects different permissions on the same package (this is a serious limitation)

P.S.: I'll post an additional note later on our repository structure and how we are securing it.

[Geert Bellekens]

Just a note.

I've never used these group locks at any of my clients.
We usually set-up security with the option "Require User Lock to Edit", nothing more.
The rest is all a matter of agreements and education.
We tell the users which parts they are allowed to change, and which parts they aren't.

I have never had an incident where people locked a package they weren't allowed to and started changing stuff.

At some clients we also setup version control integration for certain packages. Mostly because of other reasons (packages used for code generation, or packages that are shared in different repositories). This version control integration has the added benefit that you can limit the users who can check-out/in in the version control system.

Geert

[qwerty]

What Geert said. I happened to run into a customer where they started with those group locks. Accidentally (whoa!) one set RULtE and that caused a big turmoil. Now they don't dare to do this again with first announcing (and educating users). Well, they are now stuck with a lot of admin work and users moaning about useless locks being set and hindering them in their daily work (like Import XML not working due to an unidentifiable lock) :-/

q.

[Modesto Vega]

Geert and qwerty, thanks for the warning but it is not enough to make me change our repository security approach. Our repository is too large to allow anybody to apply locks at the wrong level. I still have mild nightmares remembering what happened when, as part of performance experiment, we tried to put a package lock to high up in the model/package hierarchy: Sparx crashed.

By using groups we can reduce the size of accidental locks.

[Paolo F Cantoni]

Something is confusing me about this thread.

We never had any of these problems even using the "Classic" group approach, over many years.

I think it's that we DON'T use version control.  Consequently, we don't get locked Folders, we do occasionally get locked Diagrams, but typically that's it.

Modesto, will you be using version control?

Paolo

[Modesto Vega]

Something is confusing me about this thread.

We never had any of these problems even using the "Classic" group approach, over many years.

I think it's that we DON'T use version control.  Consequently, we don't get locked Folders, we do occasionally get locked Diagrams, but typically that's it.

Modesto, will you be using version control?

Paolo

Thanks Paolo, there is confusion in this thread and hadn’t noticed until you raise it.

It is no possible to have accidental locks with groups, because by definition every model/package, including content, with a group lock is already locked to the group and only group members can change it (without having to lock anything)

We are not planning to use version control. Instead auditing is enabled to as a safeguard.

There is some talk about using baselines but will explore this when everything else is in place.

We are thinking about using Transforms or Message composer as a form of branching.

[Paolo F Cantoni]

[SNIP]

We are not planning to use version control. Instead, auditing is enabled as a safeguard.

[SNIP]

We've been told that auditing is a very "heavy" process.  So we have steared clear.

We use regular snapshotting via Transfer Project to create clones of the repository at specific points in time (takes less than 10 mins a time).  If we need to recover something, we are able to merge the current state of the repository with the clone as required via queries.  In over 5 years, there hasn't been any significant issue with recovery (including losing over 300K connectors due to some underlying SQL Server problem (beyond our control) on a number of occasions).

If you DO go the auditing route, we'd be very interested in your experiences.

Paolo