Evaluating User Rules

User rules determine which rules that exist in a model are offered for the user to select upon login. A normal user can only log-in to a model with a user role. Other rules determine administrative rights.

Familiarizing Yourself with Rules

What will be regulated?

Model Admin Rules specify whether and in which models a user can carry out administrative tasks.

Model Server Rules specify whether and in which single sign-on repositories a user can carry out certain administrative tasks.

Version Rules specify whether a user can start and edit managed models.

You are only allowed to log-in to the model as a normal user or model administrator or to the model server as a repository administrator if you have the rule assigned to you specifying that you can do this. At least one role needs to be available for normal users.

Restriction

If no rule exists in the central user management on the main license server for any rule type, then all users are allowed to use the full scope of the functionality restricted by this rule type. This makes is easier to carry out Innovator administration.

As soon as a rule exists for any rule type, then you can only use the functions made accessible by these rules. You need to explicitly create rules for each rule type if you wish to use functions of other rule types.

Effect of Login Rules

Login rules define which roles should be available for a user in a project, repository or model when they log-in to a model.

The list of roles the user can take on according to the list is compared with the existing roles in the model when a user logs-in to a specific model. The roles available to the user appear for them to select when logging-in.

Login rules are generally first created for user groups in the Groups tab. You then define specific rules for individual users in the Users tab. These rules should be unique and reachable. Avoid contradictory rules for groups to which the same user is assigned, for example.

You can maintain all existing rules in the Login Rules tab. You can sort and filter all rules. This makes it easier to identify which rules cannot be reached and therefore have no effect, in order to change or delete these rules.

Effect of Model Administrator Rules

The model administrator rules define whether a user can log-in as a model administrator or request temporary model administrator rights and in which models of single sign-on repositories they can do this.

Model administrator rules control authorizations for the following actions:

Rename Model
Save or load model templates
Revoke access or read rights
Activate change logging
Manage alternative display languages for diagram contents

A rule can use an option to define that it can be used only by plug-ins to execute commands that require model administrator rights. This means that end-users cannot request administrator rights via the interface.

You can maintain all existing rules in the Model Admin Rules tab. You can sort and filter all rules. This makes it easier to identify which rules cannot be reached and therefore have no effect, in order to change or delete these rules.

Effect of Model Server Rules

Model server rules are used to determine whether or not a user can carry out administrative tasks and in which single sign-on data repositories.

Model server rules control authorizations for the following actions:

Log-in as repository administrator (no password required)
Create, rename, and delete models (in the administration program)
Start a model server (also using the command line)
Close a model server (also using the command line)

You can maintain all existing rules in the Model Server Rules tab. You can sort and filter all rules. This makes it easier to identify which rules cannot be reached and therefore have no effect, in order to change or delete these rules.

Effect on Version Rules

Version rules specify whether a user can start and edit managed models.

Version rules control authorizations for the following actions:

Create a successor or sub-version from an existing model version
Starting and Stopping Model Versions
Update model versions (particularly recommended after carrying out a time consuming action)
Move model versions within the model hierarchy

You can maintain all existing rules in the Version Rules tab. You can sort and filter all rules. This makes it easier to identify which rules cannot be reached and therefore have no effect, in order to change or delete these rules.

Rule Evaluation Steps

All rules that are relevant for a user are displayed in the Users tab in the Configure User Logins dialog.

The direct user rules are always listed before the inherited group rules and their order can be changed.

Groups which the user is a direct member of are shown before groups that the user is an indirect member of. Inheriting groups of a hierarchy level are displayed together. Inherited rules cannot be moved. You cannot influence the order of the hierarchy levels and the groups of the same hierarchy level.

Rule evaluation for login rules and model server rules is carried out in several steps:

The first hit for the current login data (user and model) is found in the direct user rules and used regardless of whether it is an exclusion rule or an enabling rule. The order in which the user rules appear is, therefore, relevant!
If no hit is found in the first step, the system searches for a suitable rule in all groups of the next hierarchy level one after the other, so starting in those of which the user is a direct member. The first hit is used. The order in which the group rules appear is, therefore, relevant!
If the user is a member of multiple groups in a hierarchy level, the group rules must not have any overlapping applicability if it should be possible to determine the order of the rules unambiguously. Otherwise, the order of creation of the rules is decisive.
If neither step (users or groups) finds a hit, this means that the user is unable to log-in to the model or login is denied on a non-single sign-on repository. The user also does not have administrator rights for standalone model servers or managed models.

When logging-in to models, a list of roles appears for the user, which is then compared with the roles which currently exist in the model. The roles available to the user appear for them to select when logging-in.

Recommendations

Here are a few definition tips for configuring rules and how to proceed when evaluating rules:

Arrange specific rules (with certain naming patterns and few wildcards) before general rules.
Do not define conflicting rules in groups which the same user is assigned to.

The interface indicates rules that cannot be reached with the icon and rules that are ineffective due to projects that do not exist with .