Signet Concepts, Glossary, Features - Signet ...

素行 2007-06-01

展開全文

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.

CONCEPT	DEFINITION
*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. Refer to the examples at the bottom of this page to see how privileges are defined in Signet, using the following building blocks:

TERM	DEFINITION
*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. For example, scope is the extent or realm within which a privilege is valid. Given the [2nd] example at the bottom of this page, Jessica would not have access to Staff Application Data at [other scopes of] the Library, nor at Student Services, etc.
*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:

TERM	DESCRIPTION
*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 explained with the following examples:

Example #1 - Principle Investigators May Approve Purchases

The Dean has delegated a privilege to all Principal Investigators, that they may approve purchases for research projects in the School of Medicine up to $100,000, but only after completing training. Additionally, this statement holds true until an expiration date of January 1, 2008, and only as along as a PI remains a faculty member within the School of Medicine.

... where

Privilege / Lifecycle	In Signet Terms...
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

Example #2 - A Manager Is Granted Access to Data

Another example: if Jessica were a manager within Human Resources at Michigan University of Science and Technology (fictitious..M.U.S.T.):

The Director gives permission to Jessica, such that she may access Staff Application Data within the Human Resources department. She may view this data, with transfer/copy access only. She may have this access only after completing Privacy Data Policies training and until April 29, 2007 (the end of the spring semester.)

where..

Privilege / Lifecycle	In Signet Terms...
... by authority of the Director (of HR)	grantor
the Manager	grantee (group/role)
after completing Privacy Data Policies training	prerequisite
may access Staff Application Data	function
in the Department of Human Resources	scope
She may read (view), with transfer/copy access	limit
until April 29, 2007...	conditions