|
[Home]
[About]
[FAQ] [Software]
[Documentation]
[Contact]
Concepts, Glossary, & Features
Rev. 9-Feb-2006
General Privilege Management Concepts
The language of Privilege Management is rich and often
interchangeable – one "may", one "can",
one "is authorized", "has permission", "is
allowed", "has access", etc. The definitions
below are meant to clarify general concepts and overlaps,
while the Signet glossary below defines terms specific
to Signet.
| Access Control |
The act of allowing access to facilities, programs, or
services to authorized persons (or other valid users),
and denying unauthorized access. Access Control requires
that rules or policies be in place, that privileges be
defined, so that they can be enforced. |
| Authentication |
The process of confirming the identity of the user. Since
computer identification cannot be absolute (e.g., passwords
can be stolen), authentication relies on a related concept
of level of trust, in which an institution relies
on good identity management practice (so that the institution
believes they have correctly identified an individual)
and secure mechanisms for sharing identity.
This is sometimes referred to as AuthN (authentication),
in contrast to AuthZ (authorization). |
| Authority |
A broad term than can cover most aspects of creating
policies and rules governing who has rights and privileges
for an organization. It includes the ability to control
the dissemination of those rights, as well as an organization's
responsibilities to enforce those rights. This is sometimes
referred to as AuthZ (authorization), in
contrast to AuthN (authentication).
It can also be used more specifically in a singular
authorization situation to say whether a user has "authority" to
take an action. In this sense, authority and privilege can
be used interchangeably. |
| Authorization |
The process of deciding if a user (person, program, device,
etc.) is allowed to have access to or take an action against
a resource. Authorization relies on a trusted identity
(authentication) and the ability to test the privileges
held by the user against the policies or rules governing
that resource to determine if an action is permitted for
a user. |
| Eligibility |
A concept closely related to authorization in that it
can use the same mechanisms of authentication, policies,
rules, and role evaluation. The differences are semantic – one
is "eligible for something"
as opposed to "authorized to do something" – so
each is appropriate to use to describe different use cases.
For instance, "all students are eligible for an email
account", vs "students in this class are authorized
to download course materials".
Eligibility is more akin to a "right", in
legal terms, than a "privilege", but the technical
differences in how they are accomplished in an online
environment are generally negligible. |
| Entitlement |
Often used the same as Privilege, entitlement carries
the feeling of something owed or of a right granted. We
make limited use of the word here. An authority related
eduPerson attribute
– eduPersonEntitlement – uses this term specifically
as an attribute that conveys ownership of the named right
or privilege, a token that can be used directly or in a
rules evaluation in determining authorization. |
| Identity Management |
Identity management is often used broadly to encompass
not only activities to correctly identify who a person
is, but also the manifestations of that knowledge through
infrastructure access and security services – single
sign-on, account/service provisioning, authentication and
authorization. Here we focus on a narrower definition,
principally the need to identify persons as one individual
despite multiple associations and roles, proper identification
of other entities and agents (organizations, applications,
etc), and the management of that information over time
and across the enterprise. |
| Privileges |
Etymologically speaking, a privilege is a "personal
law", making privileges a set of personal rights.
Privileges amount to the sum of what a person may do, as
granted to them or inherited. Groups or roles are said
to have privileges, but ultimately that is a way to confer
those privileges to all members as individuals.
In the context of a Privilege management system, Privileges
is used to describe the combination of a person or group,
their current permissions, and any qualifications to
those permissions. |
| Permission |
A closely related term to access control, a permission
is the control specifically related to a resource and an
action – a person must have permission to take that
action. Signet uses permission, in this sense, as the unit
of fine-grained privilege control. See Permission under "Permission
Building Blocks" below. |
Signet Concepts
Signet supports an approach to enterprise-wide privilege
management within an institution. It separates the management
of privileges from the interpretation or application of them.
It does this through a central, shared repository of privilege
information where privileges can be managed independent of
any specific system or technology that needs it. Such an approach
offers several key benefits:
- Simplification of privilege policy implementation, management,
and interpretation.
- Consistent application of authority rules via middleware
services and synchronization of privilege data across systems.
- Bringing together all privilege information about an individual,
so that it can be viewed together.
- Integration of privilege data with enterprise reference
data to provide extended services, such as automatic revocation
of privileges based on status and affiliation changes.
- Role-based authority, that is, management of privileges
based on institutional criteria, such as membership in a
group, rather than attached to individuals.
Signet addresses a number of common problems faced in managing
privileges in a large institution or across institutions and
services:
- Having to move across multiple security systems, multiple
interfaces, or multiple organization boundaries to establish
privileges.
- No easy way to package a set of privileges that requires
the coordination of multiple access privileges.
- No easy way to track those privileges, especially across
time.
- Revoking privileges in multiple systems is as challenging
as is establishing them, and requires complex coordination
across systems.
Benefits:
- Does not describe a single authority model, but rather
offers an environment in which many authority solutions can
be implemented.
- Supports hierarchically distributed control of authority
and privilege definitions, with minimal central administration.
- Supports hierarchically distributed delegation of assigned
privileges, as well as centrally managed model.
- Is well suited to academic institutions, due to the above
characteristics.
Finally, there are several key architectural principles underlying
the design of the Signet privilege management.
- Abstract privileges away from specific systems and technologies
for the user: Record WHAT it is a person can do, not HOW
they do it.
- Have the consuming system translate that into specific
technical terms for interpretation by systems.
- Assumes strong identity management that can reliably identify
a person in such a way they can be understood across multiple
systems.
- Sharing and reuse of authority components within and across
domains of authority.
- Open environment for any user to implement privilege management,
from individuals to projects to offices to schools.
Signet Glossary — Defining Privileges
An important Signet principle is the separation of the user view
of privileges expressed in readable business language, from the
system view of privileges expressed in technical permissions
and resource identifiers that make the plumbing work. Privileges
are defined in Signet using the following building blocks:
Subsystem
A Privilege Management System starts out empty,
a place in which a user can define their own authority needs.
Any defined authority is part of a subsystem, a separately
defined and managed section of the privileges space.
One small subsystem is defined by the authority system
itself to manage the privileges of the users, who then administer
the system itself. Otherwise privileges must be defined for
use. Subsystems not only provide high-level organization
to authority information for the user, they also establish
ownership domains each with their own rights.
Category
Optional way of organizing functions within a subsystem,
to group like privileges together for the UI.
Function
This is the basic unit of an authority assignment
from the end-user's perspective. It can represent a discrete
task or a collection of tasks that must be enabled together
for a person to perform that function. A good design will define
a function at such a level that a single assignment will suffice
to activate all the privileges required for a majority of common
needs, but not put so (too) much together that it cannot support
the required granularity of control. So it lies somewhere between
a job, which has many responsibilities, and a system
permission to perform an operation, such as updating a table
in a database.
Limit
Something to which a privilege is bound, such as
a department or budget, or constraints that can be applied
to users with access to a permission, e.g., a dollar amount
limit.
Privilege definitions and assignments consist of several additional
key features that help manage privileges...
Scope
All authority has some definition of scope, rules
that determine how broadly authority can be granted and how
broadly granted authority applies. Scope can be simple or complex,
but will express some form of hierarchical context in which
to understand levels of authority. Such hierarchies provide
a structure so that authority can be narrowed to the appropriate
levels of the institution, or choices, such as limits, reduced
to meaningful subsets. It also provides a meaningful framework
for a distributed model of authority control, where one can
pass on only privileges that one has, or a subset thereof.
The most useful scope is Organizational Scope – assigning
privileges at a specific location in an organizational tree.
The hierarchical nature of the Administrative and Academic
structures provide a natural scaffolding that supports the
distribution of authority to successively discreet portions
of the University.
Prerequisites
A pre-condition that must be met for authority to
become active, e.g., "training required". This facility
allows authority assignments to be managed ahead of a user's
eligibility to receive the attendant privileges. Prerequisites
support the automatic activation of privileges when specific
criteria are met.
Conditions
Something that must be true for the authority to
remain valid, e.g., "until date x" or "as long
as in department y". Conditional authority supports the
automatic revocation of privileges when the conditions are
met. The most important manifestation of this feature is to
withdraw access rights when a person is no longer associated
with an institution. [Signet v1.0 supports date-based conditions
only. Rule-based conditions are pending.]
Finally, Privilege definitions must develop into something
that systems and services can use to implement or enforce the
authorization conferred by Privileges:
Permission
The atomic units of authority control, representing
specific operations under authority control. Permissions are
expressed at the lowest level of resolution that applications
and services need, to determine whether a user can perform
an operation. They are how the business language of privilege functions get
translated into a technical language for interpretation by
applications or mapping into the subsystem's local security
terms.
Signet Glossary — Assigning Privileges
A Privilege assignment is the association of a function, scope,
and the subject (person or group) receiving privileges.
Any assignment contributes new privileges to the overall privilege
set of an individual, whether the assignment is directly
to a person or indirectly via a role or group. Signet preserves
the distinction between such person-specific and non-person-specific
privileges, allowing an interpreting system to enable privileges
altogether, or support interactions confined to people acting "in
a role" if so desired.
The following terms apply to the granting of privileges:
Delegation
This is the ability to extend privileges to others – you
can think of it as authority about authority. As part of the
support for distributed authority management, assignments can
be made with or without passing on the ability to further delegate
authority to others. Delegation works hand-in-hand with scope
to provide a chain of delegated authority along hierarchical
lines of an organization.
Designated drivers
Granting proxy – the ability for a
person to designate another to act for them in all privilege
management activities. It allows privileged people who actually
possess some authority to designate someone who can act in
their stead online. This is of practical benefit yet preserves
the proper chain of authority in the system.
Grantee
The subject who is receiving privileges. In Signet, this
can be either a Person or a Group.
Grantor
The person who is authorizing privileges for another. With
one exception, delegation is governed by the general principle
that you can give to others only privileges that you have,
or a subset of what you have. The exception is the special
case of Subsystem Owners who have "grant only" privileges
for their Subsystem. When "acting as Signet", they
have complete authority to initiate all privileges for a
subsystem even though they cannot wield them.
Notification
An important aspect of privilege management is the notification
to players about new or changing authority. This is particularly
crucial the more one allows the distributed application of
authority, or proxied or third-party actions. Feedback to
both the grantors and recipients of authority is an important
element of assuring the ongoing integrity of appropriate
privileges and to reduce risk of intentional or accidental
abuse.
Resource
The thing to which a privilege applies, e.g., files, web
pages, actions, etc. In Signet the resource is an implied
part of a privilege definition. For instance, a function
might be defined as access to course materials, telescopes,
computer resources, buildings, etc. – all of which
would be considered the resources.
Privilege Lifecycle controls
Signet supports the following features for automated control
of privileges over time:
- Auto activation – the enabling of privileges for
an assignment when an effective date is reached or
a prerequisite is met.
- Auto revocation – the withdrawal of privileges for
an assignment when an expiration date is reached or
a condition becomes false.
- Auto notification – standard notification associated
with assignments that are automatically managed, as well
as specialized notification for special conditions, such
as assignments not activated in a specific timeframe. [not
available in v1.0]
Signet Features
All these facilities together support the full feature set of
Signet, which can be summarized as follows:
| By authority of the
Dean |
grantor |
| principal investigators |
grantee (group/role) |
| who have completed training |
prerequisite |
| can approve purchases |
function |
| in the School of
Medicine |
scope |
| for research projects |
resource |
| up to $100,000 |
limit |
until January
1, 2008
as long as are faculty
members at ... |
conditions |
For additional terminology, please refer to the Internet2
Glossary
|
