MACE-paccman Glossary
Comments and feedback are welcome and encouraged. Authenticated users may post comments, or you may send e-mail to <mace-paccman-contact AT internet2 DOT edu>. Instructions for obtaining editing access can be found at http://middleware.internet2.edu/docs/internet2-spaces-instructions-200703.html.
General Privilege Management Concepts
The language of Privilege Management is rich and often interchangeable - one "may", one "can", one "is authorized", "has a privilege", "is allowed", "has access", etc. The definitions below are meant to clarify general concepts.
CONCEPT |
DEFINITION |
---|---|
Access Control |
The act of allowing access to facilities, programs, resources or services to authorized persons (or other valid subjects), and denying unauthorized access. Access Control requires that rules or policies be in place, that privileges be defined, so that they can be enforced. |
Access Management |
That part of Identity Management comprising the processes and tools used to associate privileges with subjects in accord with the wishes of Authorities. |
Action |
Function, Action, and Verb are close synonyms within the privilege and access control domain. They are used interchangeably in the tuple data model where a privilege is defined by Subject + Function + Scope. |
Assertion |
A declaration or claim. Typically, when the term assertion is used in conjection with privilege management it tends to connote a claim formatted with a particular formal syntax. For example the document or speaker may be talking about a claim formatted as an assertion conformant to the SAML specification. |
Attribute |
A distinct characteristic of a subject. An object's attributes are said to describe it. Attributes are often represented as pairs of "attribute name" and "attribute value(s)", e.g. "foo" has the value 'bar', "count" has the value 1, "gizmo" has the values "frob" and "2", etc. Often, these are referred to as "attribute value pairs". |
Authentication |
The process of confirming the identity of a principal. 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. |
Authority |
1) 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 process or workflow used to attest or assign rights and privileges , 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. |
Authorization |
The process of deciding if a subject (person, program, device, group, role,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 subject against the policies or rules governing that resource to determine if an action is permitted for a subject. |
Claim |
A declaration, or assertion, made by an entity. Hopefully the entity is a reliable third party. Examples of claims include names, affiliations, group membership, or capabilities. |
Delegation |
The process used, or task performed, by a grantor to assign privileges to other subjects within the limits of its authority. A subject with delegated privileges does not have to perform any type of impersonation in order to exercise the privileges. |
Effective |
Indirect, inherited. Opposite of immediate. An assignment is "effective" if it exists because of other assignments or rules. Some examples: |
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". |
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. |
Entity |
A collection of identifiers and attributes managed by an Identity Management System representing any real-world actor, such as a person, process, system, etc. |
Function |
Function, Action, and Verb are close synonyms within the privilege and access control domain. They are used interchangeably in the tuple data model where a privilege is defined by Subject + Function + Scope. |
Grantor |
A principal authorized to delegate some portion of its own authority and that has exercised that privilege. |
Group |
A collection of subjects, which can include subjects representing other groups. |
Identity Management |
Identity management is often used broadly to encompass not only activities to correctly identify and maintain attributes about subjects, but also the manifestations of that knowledge through infrastructure supplying 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, groups, services, resources, etc), and the management of that information over time and across the enterprise. |
Immediate |
Direct. Opposite of effective. An assignment is "immediate" if there is an explicit assignment from the subject to the resource (and perhaps including qualifiers). An immediate assignment does not depend on other assignments to exist. An immediate assignment can be unassigned directly. |
Namespace |
A domain in which an identifier is unique in representing a single object. |
Permission |
A closely related term to access control, a permission is the control specifically related to a resource and an action - a subject must have permission to take that action. Note - paccman is deprecating this term and suggest that privilege be used consistently. |
Policy |
A policy is used to describe general access control requirements. There are many existing proprietary and application-specific languages for creating policies, but XACML has several points in its favor: it's standard, it's generic, it's distributed, it's powerful. |
Principal |
A subject whose identity can be authenticated. |
Privileges |
Etymologically speaking, a privilege is a "personal law", making privileges a set of personal rights. Privileges amount to the sum of what a subject may do, as granted to them or inherited. |
Provisioning |
The process of managing attributes and accounts within the scope of a defined business process or interaction. Provisioning an account or service may involve the creation, modification, deletion, suspension, or restoration of a defined set of accounts or attributes. |
Qualifier |
In the context privilege manage and access control, Qualifier and Scope are close synonyms, often used interchangeably. A qualifier, or scope, mediates (or restricts) the applicability of a Verb or Function. |
Resource |
Resource and Target are often used synonymously when discussing privilege management colloquially. As with Target, the term is context dependent when used informally. At times, Resource is another close synonym of Qualifier and Scope. However, people tend to use this term when speaking about more "tangible" scopes such as "Oxford English Dictionary Online" or "Ethnic Newswatch". There are other qualifiers and scopes that people don't typically think of as a resource, for example "the category of HR", "NULL", and depending how closely you work with the financial system, cost objects and account numbers. |
Responsibility |
A responsibility is an action that a principal assigned to a role is expected to perform. Similar to a privilege except that the principal not only has the ability to perform the action, but is expected to perform the action. In the Kuali Enterprise Workflow system, an example of a responsibility is a step in a workflow where a subject needs to respond to a workflow action. Note that more than one person could have the same responsibility. |
Role |
Colloquially we use "roles" very broadly. In higher-ed some of the common roles are Dean, Department Chair, Principal Investigator, Faculty, Post-Doc, ... |
Rule |
A prescribed evaluation of data which is used to confer a privilege, to a subject or a collection of subjects. |
Scope |
See Qualifier |
Subject |
An entity whose identifiers and attributes are managed by an Identity and Access Management practice. |
Target |
The term "Target" should be deprecated. Target is a matter of perspective and context. When people are discussing privilege and access control informally, a target is often the same as a Resource. However, at other times, the focus is on the Subject. In yet different contexts the target is actually the set of people that have a specific verb and scope applied to them, as in the "target group". |
Verb |
See Function |
Workflow |
Workflow is concerned with the automation of procedures where documents, information or tasks are passed |
Comparative Taxonomy
During the June 2009 EDUCAUSE and Internet2 Advanced CAMP, participants suggested that MACE-paccman create a comparitive taxonomy that would explore the differences, as well the commonality, between several systems that have importance or relevance to the CAMP attendees and the MACE-paccman community. The subsequent work is taking place here.
References and acknowledgements
This glossary has been heavily influenced by the Signet glossary.
Other valued references include:
- Enterprise Authentication Roadmap
- Identity Gang's Lexicon
- Identipedia Terms
- SAML2 Glossary
- NIST Special Publication 800-63
- Internet Security Glossary
- Wikipedia
- eduPerson
- Practices in Directory Groups
- Privilege Management Recipe
- The Architecture Journal, vol 16
- Kuali Identity Management glossary
- Grouper glossary
- SPML Core
- NIST RBAC model
See Also: More generalized glossary work at https://spaces.at.internet2.edu/display/macepaccman/Another+Glossary+Page
4 Comments
Paul B Hill
"Approver" and "Approval" were suggested on one of the calls. Tom and I agreed to strike them from the glossary for now. Within the Signet and MIT Roles systems, this type of behavior would tend to be written into a FUNCTION within the privilege management system. They are related to some of the privileges that one desires to manage. They are not essential to the design and implementation of the privilege management system itself.
Paul B Hill
"Impersonation" has also been discussed. Within the Signet and MIT Roles systems, this type of behavior would tend to be written into a FUNCTION within the privilege management system. Impersonation is not essential to the design and implementation of the privilege management system itself.
Rich Stevenson
Should "credential" be added as a common term? "A credential is a special form of attribute or combination of attributes used during the authentication process to confirm a principal with varying degrees of assurance."
Michael P. Pelikan
Will be taking take a stab at "Member" and "Membership", compared and contrasted to "Affilate" and "Affiliation", if that's ok with you folks....
Would like to raise to a conscious level the need to distinguish (always) between in-system use of common terms as compared to their commonly understood use in The Real World. I see this already occurring above - and that's very good - I just want to make it explicit.
For example: "group" is a term that begs for this. One of the things that trips folks up is the semi-realization that there are "groups" (maybe call them "natural groups") in the The Real World that may or may not be reflected in the in-system world's definition.
For example, there is, just by virtue of its existance, a natural thing in The Real World which is the group of all Medieval Historians. There is a naturally occurring sub-group of that group comprising Medieval Historians in North America - this subgroup is itself also a group.
Groups as understood in our in-system space may or may not represent such Real World groups. We may define them by the union of a very limited number of attributes. We may do a query against attributes and come up with a result set comprising a bunch of Medieval Historians - but that is not automatically the same as creating an in-system Group of Medieval Historians, nor is the in-system group the same by nature as the naturally occurring group in The Real World. It may simply be a group of principals sharing an attribute or two to which we've applied the label "Medieval Historians" - see?
I think we'll run into some of these same issues whenever we hit a "commonly understood" Real World term that we've borrowed and applied for our in-system purposes.
So I guess this is a plea for an ever-present vigilance as to scope. As stipulated above, I see this already in the definitions above and I applaud it. By this comment I'm just trying to make that consciousness of scope explicit.
That's all for the moment - Thanks all...
Michael Pelikan