|
[Home]
[About]
[FAQ]
[Software]
[Documentation]
[Contact]
System Administration - Signet Roles & Internal
Privileges
Rev. 10-Feb-2006
This describes the Signet controls for managing its own internal
privileges. It defines 4 basic roles, starting with a definition
of Signet itself, as a Subject, and how that is leveraged to
enable subsequent human roles. The following subjects/roles are
identified:
| application/signet |
– |
Signet itself, defined as a Subject entity with a subject
type of application. |
| person/sysadmin |
– |
Signet System Administrator, a central role for a specific
site or deployment of Signet; possibly the same person
responsible for installation and operational matters. |
| person/subsys-owner |
– |
Subsystem Owner, a technical role supporting analysis,
definition and administration of subsystem metadata and
assignments. |
| person/ur-grantor |
– |
The person at the top of a delegation hierarchy or
the head of a delegation chain within a subsystem; a
person or persons with system-granted initial assignments
from which all privileges are delegated. |
Signet as Subject Entity
To initiate system internal privileges, there must first be
a subject identity for Signet itself, one with a subject type
of application, a subject ID of signet, and a
subject name of Signet. This entity is built into Signet – it
is not connected to any external source. This entity has two
capabilities used by the system:
- It is the source of granted privileges over internal Signet
system actions as described below.
- It is the actor on any system-initiated action, e.g., it
will be identified as the "revoker" when a lifecycle
event (expiration or affiliation change) causes the automatic
revocation of services.
The Signet subject has hard-wired granting powers over
all functions in all subsystems. Note that Signet can extend
capabilities to others (can grant), but cannot itself act on
those privileges. In this way, neither Signet nor individuals
proxying Signet have inappropriate privileges across systems
whose authorizations are being managed in Signet.
The Signet System Administrator
The Signet application has no capability of logging in and
taking action in the interface. This requires a human actor – the
system administrator. The sysadmin role is defined as
a person who may proxy Signet online. A proxy assignment is
done via a command line utility by someone who is already the
de facto system administrator, in that they control the software
management utilities that are a part of Signet. This is the
assignment which gives that person online capabilities
as system administrator.
| |
proxy grantor |
proxy recipient |
limit (subsystem) |
| 1. |
application/signet |
person/sysadmin |
[none] |
Use the system utility found in signet/util/SignetProxy/ – the
run.sh or run.bat script as appropriate. The command takes
two arguments:
- Action to take – grant | revoke | list
- For grant or revoke, a login ID from the subject table
e.g., ./run.sh grant jpoole
Once enabled in this way, the System Administrator role is
always proxying the "Signet" user and its powers,
in all his or her online actions. In this way, all subsequent
actions by the System Administrator in maintaining privileges
can be done through the UI using standard system functionality.
Subsystem Owners
One of the capabilities the Signet sysadmin now has is the
ability to designate owners/administrators of subsystems. This
is also done through proxy, with the System Administrator
passing on a subset of their proxy powers. In this case, the
System Administrator does the following:
- Logs into the Signet UI (as themselves)
- Uses the "Acting in Signet" control on the front
page to indicate they are acting for Signet (not as themselves)
- Once acting as Signet, uses the "Designated Drivers" control
to "designate my [Signet's] granting powers"
- Grants Signet granting over to an individual for a specific
subsystem:
| |
proxy grantor |
proxy recipient |
limit (subsystem) |
| 2. |
person/sysadmin |
person/subsys-owner |
subsystem |
As you can see, the Subsystem Owner is very much like the
System Administrator, except that privileges are constrained
to a single subsystem.
What can a Subsystem Owner do? They can designate other Subsystem
Owners by following the same procedures described above:
| |
proxy grantor |
proxy recipient |
limit (subsystem) |
| 3. |
person/subsys-owner |
person/subsys-owner2 |
subsystem |
More importantly the Subsystem Owner, when "acting for" Signet,
can grant any function defined for a subsystem. This supports
three important capabilities:
- The Subsystem Owner can establish "ur grantors" – the
person or persons who have the highest real business powers
over the privileges managed by the subsystem. They get their
powers via standard assignments done by the Subsystem Owner
(acting as Signet) for each applicable function for the appropriate
scope.
- The Subsystem Owner can manage assignments as required
by changes in definition or policy, including updating or
revoking privileges.
- The Subsystem Owner is the person of last resort in any
exceptional granting, editing or revoking situation.
Because such "super" granting powers are available
only by Proxy, all Subsystem Owner actions are recorded as
done by "Signet", proxied by an individual.
In principal, subsystem owning privileges also includes the
authority to use subsystem utilities, like load/update metadata,
seed assignments, etc. However, these functions will be done
through the system administrator until an online administrative
environment is supported.
|
