CONCEPT

The act of allowing access to facilities, programs, 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.

A declaration or claim. Typically, when the term assertion is used 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.

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".

The process of confirming the identity of the subject. 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).

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 subject has "authority" to take an action. In this sense, authority and privilege can be used interchangeably.

The process of deciding if a subject (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 subject against the policies or rules governing that resource to determine if an action is permitted for a subject.

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.

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.

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.

a collection of subjects and/or groups.

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.

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.

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 do not have  privileges, but instead provide a mechanism to confer privileges to all members of a group or roles 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.

The process of providing subjects with accounts and establishing the data necessary to manage the accounts.

A collection of privileges usually relating to a capability or responsibility/position/job function of a subject. Collections may be comprised of any combination of implicitly and/or explicitly defined privileges. A role does not necessarily fully represent all of the capabilities of a subject.

A person, program, device, or other relevant entity which can authenticate to a system, and to which an authorization may apply. (Note well: A subject is never a group, since a group does not authenticate.)

   CONCEPT

is a 3-part entity, consisting of a subject + function + qualifier. (Formerly called an AUTHORIZATION) Note that these 3-part structures bear some similarity to the 3-part structures in RDF: Subject + Verb + Object

A collection of functions which are typically related in some way. For example, all of the functions within a category may apply to single application, a set of closely related applications, or a related group of business processes.

is the component of an A-spec that describes the action (or role or group of actions) that the person is allowed to perform. 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 a particular business function or task. 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.

• Each function belongs to a "Category", or application area
• Each function must be interpreted by downstream applications (those that use the Roles Database for access control) to represent some action or set of functionality within the application. Thus, the creation of functions must be coordinated with the application developer.
• Some functions can apply to more than one application, e.g., financial reporting authorizations apply both to the financial system and the data warehouse.
• Functions can have parent/child relationships; an authorization for a parent function implies authorizations for all child functions as well.

is an authority management system.

Qualifiers limit the scope of a function. Qualifiers can be associated with functions in multiple categories. Qualifiers can be applicable to a subset of functions within a category. Qualifiers are typed. Examples of qualifiers include an account number, organization number, budget group, etc.. Qualifiers belong to a hierarchy. Since qualifiers of each type are organized into a hierarchy, a qualifier can also be a branch of the tree of account numbers, a branch of the tree of organizations, etc. Qualifiers are generally extracted from other systems as part of a nightly feed. Some functions are either "all or nothing" and do not require a qualifier; in these cases a placeholder qualifier of NULL is included in the authorization.

    TERM

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.

The subject who is receiving privileges. Within perMIT, this is always applied to an individual subject.

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.

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.

The thing to which a privilege applies, e.g., files, web pages, actions, etc. In perMIT 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.