Access Control

Per default, access to information in the identity store from the Identity
Management User Interface is limited based on access control on tasks. If different
groups of users (for instance several companies) share the same identity store, you
may want to prevent the users of the different groups/companies to see each other's
data. You can use the fields in the "Access limitations" group box to specify these
access restrictions. The access limitations are a global setting that restricts
which entries will be returned when a user searches for entries in the "Manage" tab
and when adding references.
The mechanism relies on two attributes, the "Search attribute" and the "User
attribute". The attribute defined as the search attribute must be defined on each
entry of this entry type. In the simplest form the same attribute is defined as the
user attribute. To define a user's access, the user's user attribute is compared to
the entries' search attribute, and only those entries that have the same value as
the user's user attribute are displayed.
Wildcards are accepted in the "User attribute", so that a range of values can be
valid when comparing the "Search attribute to the "User attribute".

Attestation
You use attestation to periodically confirm users' access rights to critical
resources.
Normally, users' access rights to critical resources are controlled by assigning
specific roles and there is a risk if these roles are assigned to the wrong people.
Assignment to these roles should periodically be verified by someone who is
responsible for the resource or assignment.
The verification is done by executing an attestation process for each role or
privilege. Note that for one given assignment, there is one (and only one)
attester. The attester will only see the assignments for which he or she is
responsible. The attester has the option to confirm or reject the assignments, as
well as delegating the responsibility to another person.
All attestation operations are logged, so that they can later be audited.

Whenever a new task is started, a new record in the audit table, with a new audit
ID, is created for this task. This is called the root audit for the task. The ref
audit column of the new record will be set to the same as the audit ID, to indicate
that this is the root.
A running task may also start an event task, which may be done in many different
ways. Some examples:?
By executing one of the result handling tasks (onOK, OnFail etc).?
By executing the initialize task (task group/action task).?
By changing attributes or entries which have event tasks (add, modify or delete).?
By assigning an "Add" or "Remove" member event task to a role or privilege.?
By assigning or removing a privilege, and the corresponding provisioning or
deprovisioning task is started.?
By modifying an entry which has a privilege with a modify task.
In either case, an event task is started, which will get a new audit record and a
new audit ID. In this case, the ref audit column is set to reference the parent
task. In this way a hierarchy of audit records are created, as the tasks are
executed.
A special case is calling uProvision function, where it is possible to specify
which reference to set. This should normally be set to the parent audit ID, but if
used with care, this can be set to link the task to any audit ID.

To any role or privilege assignment, it is possible to add a reference to a given

context that limits the validity of the assignment to that specific context. A
context may be a region, a project or an organizational unit. The purpose is to
reduce the number of roles. This can for example be used in the following
scenarios:?
Project management
In this case the context is a project. A limited number of roles are defined, for
example project manager, test manager, development manager, marketing manager etc.
A new entry type is defined for the project. Each project is defined as entries of
this entry type. An assignment will then consist of the combination of a role and a
project