Signet -- Functional Requirements

http://middleware.internet2.edu/signet/docs/signet_func_specs.html

Signet -- Functional Requirements

Authors:
Lynn McRae, Stanford University (lmcrae@stanford.edu)
Minh Nguyen, Stanford University (mnguyen@stanford.edu)
Andy Cohen, Stanford University (acohen@stanford.edu)
Jennifer Vine, Stanford University (jvine@stanford.edu)

Draft 2, 10/13/04

Revisions:

10/13/04

General editing, strengthened sections on group privileges, Shibboleth interactions.

Contents

Overview
Defining Privileges
Integration with external data
Assigning Privileges
Viewing Privileges
Provisioning and use of privileges
Technical Requirements
Unresolved

1. Overview

Signet is a toolkit for creating and managing institutional privileges. At its heart is a philosophy that privileges are an expression of an institution‘s policies of rights and access that exist independent of specific online systems. Accordingly, Signet has structures for defining privileges according to business, not technical requirements, and other facilities that help provide enterprise access to privilege information or to map them into system-specific permissions.

Signet is a repository of Privilege information and data about how privileges are authorized. Signet does not itself apply or enforce privileges. Instead privilege information needs to be made available to other systems for interpretation and use.

Signet provides two web-based user interfaces to support distributed management of privilege definitions and assignments.

The definition and meaning of privileges in Signet is controlled completely by the offices, departments, projects, etc. that use Signet at an institution. Analysts specify these privileges through metadata that shapes the user experience in the UI, captures the rules governing who and how assignments are made, and determines the mapping of privileges into system-specific permissions.

Signet is based on the existing Stanford Authority system (3rd release, Fall 2003), refactored and generalized for multi-institutional use. Except as noted, this document is limited by design to a first-year delivery of an architecture and feature set that is derived from the Stanford system. Signet will include one new feature not found in the Stanford system -- the ability to assign privileges to groups.

The following overall goals apply to the development of the Signet product:

Simplification of privilege policy implementation, management and interpretation.
Consistent application of privileges via infrastructure services and via synchronization of privilege data across systems.
Bringing together all privilege information about an individual so that it can be viewed together.
Role-based authority, that is, management of privileges based on institutional criteria like relationship to a school or department rather than attached to individuals. Signet will address this in its first release by allowing privilege assignments to groups.
Integration of privilege data with enterprise reference data to provide extended services such as automatic revocation of privileges based on status and affiliation changes.

Signet will also adopt the following concepts and vocabulary (with one change) from the Stanford system:

Subsystem -- All privileges are defined as part of an authority subsystem, a separately defined and managed section of the privileges space. Subsystems provide large-scale organization to privilege information for the user and establish ownership domains over the definition of privileges. An institution will have multiple subsystems defined to accommodate privileges of different kinds and in support of different applications/services.
Function -- The basic unit of an authority assignment from the end-user‘s perspective. It can represent a single permission or a collection of permissions that must be enabled together for a person to perform that function.
Permission -- (called "entitlement" in the Stanford system) The atomic unit of privilege control, representing specific operations under authority control. Permissions are expressed at a the lowest level of resolution that applications and services need to manage access. They are how the business language of Privilege Management get translated into a technical language for interpretation by applications.
Limit -- Any qualifier to a privilege, such as a department or budget, or constraints that can be applied to users with access to a permission, e.g., a dollar limit.
Scope -- The facility to associate a privilege with a node in an organizational tree. As a specialized form of limit, scope defines hierarchical "umbrellas" where privileges apply to a specific node as well as to all child organizations. In addition, the hierarchical nature of an organization‘s Administrative and Academic structures provide a natural scaffolding that supports the delegation of privileges to successively narrower portions of an institution.
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 no longer true. The most important manifestation of this feature is to withdraw access rights when a person is no longer associated with an institution.

This document will refer to the general concept of "privileges" where possible, which in this context can be read to mean the universe of permission/authorization management that Signet addresses. It will specify requirements with regard to specific components per above only as needed.

Signet is both a User Interface and a toolkit. The software defining Signet should be implemented through open interfaces that allow sites direct access to system functionality at the API level, but this functionality is for the system maintainers and distributed developers, not as part of functionality that is exposed to end users.

Overall requirements:

Signet must be engineered as a toolkit:

Though phase 1 deliverables are articulated in this document primarily as UI features, all functionality must be internally available through well-defined interfaces that comprise the functionality set of the toolkit.
Exposure of the internal toolkit layer will be limited in the phase 1 release.

Signet must be fully auditable:

Logging -- there must be an operational record of application and process activity, e.g., transaction information, session and error traces, etc.
History -- Signet must record significant changes in privileges and privilege definitions as data and make that information about how a person‘s privileges has changed over time available to the end users.
Historical snapshot -- Signet must provide for a reconstructed view of Privilege information -- definitions, assignments and individual privileges -- at any historical point in time.

User Interface Requirements

Signet will support two user interfaces:

A UI for Subsystem owners to manage the definition of privileges.
A UI for end-users at an institution to assign and view privileges.

The user interfaces must be web/browser based.

The user interface must be available and fully functional on the broadest possible set of current browsers across the Mac, PC/Windows and unix environments.
Target versions and specific platforms (e.g., Mac9 vs X, Windows 2000 vs XP, linux vs Solaris, etc.) will be determined through development and by the Signet working group.
Signet should address ADA requirements for access as found at http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web.
If there are compatibility issues with older versions of any supported browser, they must be clearly identified.
The UI design should consider page flow strategies that assist with repetitive tasks like multiple assignments in a row (e.g., user settings or behaviors defaulted from previous actions).

UI authentication and authorization

Signet must support authentication-required access to an institution‘s privilege information.
Signet must work with an institution‘s web-based single signon implementation (e.g., WebISO, Web SSO, WebAuth, as determined by the working group and early adopters) and with Shibboleth.
Signet must support authentication through Shibboleth and deal with inter-realm identification issues (people outside your identity management system, required attributes, etc).
Signet must support authorization policies that determine who can access the user interface. Access must include those with current privileges, but controls should be provided that determine others who have access.
A user authorized to the user interface should have access to all available privilege information. There is not a requirement to provide view-access controls by organization or by kind of privilege. Partial or filtered views of privilege information to specific audiences could be misleading.
Signet must support authorization policies that determine who can be the recipient of specific kinds of privileges (by subsystem).

"About this program" page:

Information about each instance of a Signet web application -- version, start time, current configuration, metrics, etc. -- should be readily accessible to system administrators, consultants, and others who deal with the performance and health of the application and services.

There should be an easy way to dynamically add, change and withdraw transient messages to the user as they enter the applications, without editing the JSPs or needing to restart the app. This should allow for short term messages or alerts about schedules or changes to be posted by Signet support staff without operational intervention.
Securing the application and the use of https over http is a site consideration and not a Signet requirement.

2. Defining Privileges

General Requirements:

Signet must support a distributed model of defining and managing privileges.

Privilege definers (departments, projects, offices, etc.) must be able to create and manage privilege definitions within their domain with minimal reliance on resources that operate Signet itself.
Privilege definers must be able to autonomously manage assigned privileges themselves within their domain, e.g., establishing initial rights, applying bulk changes to applicable assignments based on policy or other changes, and similar data administrative duties.
Privilege definers, once established, must also have autonomous control over managing Signet privileges related to the above, that is, they must be able to manage their own rights regarding administration of their set of privileges.

Signet must support the expression of privileges in business or functional terms, independent of any specific system or technology.

Signet supports a model where persons managing privileges (the distributed end users of the UI) deal only in the language of intent. This shields users from the technical details of how privileges are implemented internally, and provides for continuity of privileges across changing systems.
Signet must provide for the translation of assigned privileges into system-specific terms to facilitate the mapping of Signet privileges to a specific application‘s security model.
Signet must provide for the translation of an assigned privilege into more than one system-specific permission so that a functional privilege can be applied to multiple systems or be the basis for more than one security setting as required to implement that privilege.

Information about Privilege metadata must be fully auditable.

Transactions against metadata must be logged.
A history must be available about changes to the metadata.
Signet must support the ability to reconstruct the content of Privilege metadata at any point in time in Signet‘s past.
Privilege data that is no longer active should be retained as deprecated or inactive, never deleted.

Subsystem Administrative UI:

This refers to an administrative UI that is available to those who own and manage the definitions of a subsystem and its parts. This is how Signet should offer distributed responsibility for privilege definitions without relying on central resources.

The Administrative UI must support the following subsystem management features for subsystem owners:

Initial definition of a Signet subsystem.
Ability to extend subsystem maintenance rights to others.
Editing (add, modify, delete) of functions.
Editing (add, modify, delete) of categories.
Editing (add, modify, delete) of permissions.
Editing (add, modify, delete) of limits.
Editing (add, modify, delete) of prerequisites.
Editing (add, modify, delete) of conditions.
Facilities to reissue privileges affected by any changes to privilege definitions.
Effective date and expiration date controls for all metadata, with automatic application of assignment reconciliation when the status of the metadata changes.

The Administrative UI must support the following assignment controls for subsystem owners:

Bulk load of assignments (for initial subsystem rollout or later expansion).
Bulk editing of limit values (to apply a policy change or related global change to the terms of privileges).
Facility to apply a new prerequisite for privileges to existing assignments.

Signet should perform the reconciliation of Assignments on the following subsystem definition changes:

Add or drop a permission from a function: reissue privileges for all people with active assignments for that function.
Drop a function from a subsystem: revoke all active assignments against that function.
Add limit to a permission: a default value for existing assignment is required. Apply the default and reissue privileges for all people with active assignments for affected functions.
Drop a limit from a permission: reissue privileges for all people with active assignments for affected function.
Drop a limit value from a limit: existing values as part of active assignments must be converted to a new, valid value as designated by the subsystem owner. Reissue privileges for all people with active assignments for affected function.
Add a prerequisite to a permission: no automatic action. Downgrading active assignments to withdraw permissions requires separate action.
Drop a condition from a subsystem: no action. assignments already system-revoked due to the condition will not be reinstated.

3. Integration with External Data

General requirements:

Signet will need to reference data defined externally to the Signet system. Signet must have a consistent strategy to support multiple plug-ins coded to published interfaces that provide access to institution-specific data sources.
For each type of external data, Signet should provide a plugin to a local internal datastore that can act in place of an external data store for development and demo and limited production use. It is not a requirement that the local data store be developed to act as a production solution when representing external data.
Plug-ins will be implemented as a Java class that implements the applicable interface. Some plug-ins will be developed as part of Signet phase 1 deliverables and be central to the product, but the architecture should provide for easy extendibility through the addition of new adapter classes.
Signet will provide utilities to bulk-load external data into its local datastores where needed. Ongoing synchronization of such locally stored data with the external source is a site-specific consideration.
External data sources should continue to provide information about both active and inactive entities so that historical references to such data as part of Assignments are not orphaned. Signet should be fault-tolerant of missing references, e.g., by displaying "Unknown person", "Unknown Organization" in the UI.
Note: Signet development has targeted some initial connections to external data or local equivalents. During phase 1 we will actively seek contributed development of adapters to additional external sources to extend the utility of Signet at multiple institutions.

Person data:

Signet requires a source of person information to identify all actors (those who assign, receive, manage and view privileges). This includes the entire domain of people who can log into the Signet UI or who can be the target of any privilege assignment.
Person information will also be needed in cases where conditional assignments require monitoring specific person attributes over time.
Signet should address issues around identifying and supporting users outside the institution‘s identity management system, e.g., inter-realm users.
Signet version 1 will include the following:

A database adapter to a local (Signet internal) datastore.
An LDAP adapter to a person directory supporting eduPerson attributes.
A utility to load external person data into the Signet Subject tables.

Organization data:

Signet must support access to one or more sources of Organization information for organizational hierarchies that can be used for scoping privileges.
Signet version 1 will include the following:

A database adapter to a local (Signet internal) datastore.
A utility to load external organization data into the Signet Tree tables.

Group data:

Signet must support access to a source of Group information, including membership, to provide the ability to assign privileges to groups.
Signet version 1 will support the following:

An adapter to Grouper.

Limit data:

Signet must support access to a source of data that defines a domain of valid choices for a limit.
Signet version 1 will support the following:

A database adapter to a local (Signet internal) datastore.

Rule data:

Signet must support access to an source that can provide responses to rules applied to grantees to support prerequisites and conditions.
Signet version 1 will support the following:

A database adapter to a local (Signet internal) datastore.

4. Assigning Privileges

Requirements:

In Signet, an assignment is a transaction that provides authorization for privileges. It alone does not activate a privilege. Signet will support effective dates, prerequisites and conditions that apply to an assignment and provide lifecycle management tools that enable privileges. Even then a privilege must be made known to systems that interpret permissions for a privilege to be in effect.
Since they are authorizing actions, Signet assignments may overlap and designate different limits and conditions. The privileges a person receives in the net of all active assignments.
Signet will not have support for negative rights, that is, the ability for an assignment to explicitly remove rather than grant privileges.
Signet must support the assigning of privileges to individual persons.
Signet must support per-subsystem rules for what constitutes a valid overall population that can receive privileges (e,g., only faculty).
Signet architecture must accommodate the assigning of privileges to other individual entities (applications, organizations, etc) as identified and applicable to an institution. Phase 1 will only support individual assignments to persons.
Signet must support the assigning of privileges to groups.
Signet must support the explicit, immediate revocation of privileges by authorized users.
Signet must make clear the distinction between the semantics of creating new assignments and editing existing assignments, since new assignments exist independent of existing assignments and do not supercede them.
Privileges are granted with the authority of the grantor at the time the assignment is made. They stay active (or pending prerequisites) per the terms of the assignment even if the grantor loses that authority.
Signet must support a delegated model of assigning privileges, where an individual, if authorized, can pass privileges on to others.

Signet must enforce a policy that "you can only assign privileges that you have". This means all that you have, or any subset".
Signet must enforce a policy that "you can only modify or revoke privileges that you would have the ability to assign in the first place".
Signet must support an organization based delegation model. Privileges must be able to be bound to an organizational hierarchy (scope), where privileges associated with a specific node in the hierarchy implicitly apply to all child organizations that are descendent from that node.
Organizational scope, when defined, must be part of determining the domain of privileges you can assign. You must be limited to that organization or any related child organization as defined by the hierarchy.
All qualifiers (limits) to privileges must support rules of "same or less/fewer" in determining allowed assignments.
Conditions are not part of the privileges per se and are not part of the "you can only give what you have rule". For instance, if you have a privilege only for a month, you can nonetheless grant it to someone else for a year, or "as long as you are here".

Signet must allow the assigning of privileges themselves as well as associated delegation rights, that is, the ability to assign those privileges to others. These must be independently controlled, so that the recipient of an assignment...

Has/can use privileges and can assign those privileges to others
Has/can use privileges but cannot assign those privileges to others
Has/cannot use privileges but can assign those privileges to others

The ability to only pass on specific privileges that you yourself cannot exercise supports a model where a trusted agent -- a central office administrator or proxy for a high-ranking official -- has the responsibility to seed privileges at the highest level to start the chain of delegation.

Signet must prevent the assigning of privileges to oneself to prevent the holder of grant-only privileges from activating the privileges for themselves, or from extending conditions beyond other authorized assignments.
Signet must support proxied use, where one individual acts on behalf of another:

Temporary, time-based delegation, from one individual to another.
Longer-term "acting-for" designation for assigning Privileges where one acts as the online agent for another (e.g., a higher ranking University official).
When desired, privileges received "by proxy" must be distinguishable from privileges received directly.
Signet must have the ability for Privilege definers to augment the system with Proxy types of their own.

Signet must support the seeding of initial privileges through assignments done by Signet itself, and such assignments must be recorded/auditable the same as other assignments.
Signet must support the following automated controls for managing the life cycle of privileges:

Prerequisites -- a condition that must be met before assignments relating to permissions controlled by the prerequisite will be turned on. A prerequisite once met is latching. It is not tied to an ongoing criteria that must be monitored once the prerequisite is satisfied.
Prerequisites are associated with individual permissions that are part of an assignment. Signet must allow a subsystem definer to determine if an assignment can be partially activated or must meet all prerequisites before any of the permissions are released.
Conditions -- ongoing criteria that must remain true for an assignment to remain active. Signet must monitor information about privilege holders in order to automaticlaly revoke privileges when an assignment condition is not longer true.
Once a condition becomes false and the privileges revoked, they will not normally be reinstated even if the condition beomces true again.
Signet must have a strategy for rapid reinstatement of system-revoked privileges that are determined to have been revoked in error (e.g., incorrect information about faculty or staff status).
Signet must have built-in effective-date and expiration date support for any assignment.

Signet will maintain a per-individual awareness of privilege changes for members of a group that is the target of a privilege assignment. It will apply prerequisites and conditions on a case-by-case basis. It will augment and withdraw, as appropriate, permissions from individuals based on their membership in such groups.
Information about Privilege assignments and privileges held by individuals and other recipients of privileges must be fully auditable.

Privilege assignments and changes to assignments must be logged.
A history must be maintained about changes to the assignments and about subsequent changes to the privileges held by the recipient.
Signet must support the ability to reconstruct the privileges held by a person or other recipient of privileges at any point in time in Signet‘s past.

Signet must support automated email notifications, site-configurable, for

New assignments.
Revoked assignments.
Assignments waiting too long to meet prerequisites.

Signet should perform the reconciliation of Assignments for the following external data changes:

Date change (post-midnight process): activate assignments and metadata whose effective date has been reached. System-revoke active assignments whose expiration date has past.
Organization disappears/becomes inactive: assignments are left intact and may still have meaning as transitional or historical references, or ongoing valid permissions over historical data. The UI should make active/inactive distinctions clear, especially when choosing an organizational scope for a new assignment.
Note that Signet will take no action when an organization that is used as an assignment scope moves (gets a new parent). An subsystem definer must make an independent decision about whether some or all existing assignments should be revoked.

5. Viewing privileges

This section concerns end-user interactions with the Signet system and information. All end-user oriented displays are about Assignments, not about specific Permissions.

UI Requirements:

A user that has or had privileges must be able to see

all privileges they have, including who granted them and any qualifications or conditions that apply.
privileges that they had, when they had them and why they no longer have them.
privileges one holds implicitly by virtue of being a member of a group.
privileges one has by proxy.
who can act as proxy for you.

A user that has assigned privileges to others must be able to see

privileges that they currently have assigned.
privileges that they historically have assigned.
privileges that they recently assigned.

An authorized user must be able to see privileges that are

associated only with a specific organization.
associated with a specific organizational level (an organization and sub-organizations within).
only specific kinds of privileges (filter by subsystem)
recently changed.

Signet should provide for the export of privilege information by the end user in a format amenable to use by a spreadsheet or other software outside of Signet.

6. Provisioning and use of privileges

Requirements:

The main output of Signet is information about a person (or more generally, a privilege holder) and all privileges they currently hold. These will be expressed through permissions.
Information about assignments that authorize privileges is not part of privileges output.
Signet granting privileges (e.g., can grant but cannot use) is internal to Signet and not part of a person‘s exported permissions.
Privilege data must be available as an XML document.

The Privilege document conveys the sum of all permissions as person has, independent of assignments that authorized them.
The Privilege document should distinguish between permissions assigned directly vs those one has by virtue of being in a group vs those one has by means of a proxy assignment. This allows a consumer of privilege information to support separate "acting as" and "acting for" scenarios if desired.
Signet should make a person‘s Privilege XML document accessible to users on the web. Note that this is not a solution for programmatic access to these documents since the http protocol does not provide robust transactional semantics.
Signet should make a person‘s Privilege XML document accessible to programs through a standard, robust service interface, e.g., Web Services, e.g., SOAP.

Other outputs (more analysis required)

Assignment data should be available as an XML document to allow monitoring of pending assignments external so Signet (a start at workflow connections).
SAML assertions that can be used in the Shibboleth infrastructure.

Signet will require a strategy for signaling changes to privileges per privilege holder.

Note that there is no current requirement for an authorization interface directly into Signet.

7. Technical requirements

General requirements:

The Signet system must meet, or be engineered to meet, reasonable standards of:

Performance -- this applies both to programmatic calls as well as overall UI behavior for the end user.
Availability -- there should be nothing inherent in the Signet design that requires extended or routine downtime to deliver Signet functionality. This is independent of site-specific maintenance windows, database or server availability criteria.
Scalability -- Signet should have no inherent scalability issues with multiple users. It should be thread safe in all operations and allow concurrent access between UI users and tools (e.g., metadata loading or bulk assignment processes). Operational scalability strategies, such as load-balancing, are site-specific considerations.
Fault tolerance -- Operationally this is also site-specific (server restarts, recovery from errors, etc). From a data perspective, this means the use of appropriate transactional semantics to guarantee the referential integrity of the data, and inline strategies to deal with obsolete or changing data that must be represented in the UI. Functionally a site can opt in or out of a number of components and features. The system should have a strategy to cleanly bypass such components in its processes and in the UI.

Signet should collect and make available metrics

Current metrics as part of a current service profile -- e.g., transaction throughout, load (e.g., concurrent users), memory utilization, etc.
Accumulated metrics for cyclical and trend analysis -- e.g., number of transactions, peak usage, etc.

Database

An rdbms supporting standard SQL schema and transactions.
Signet phase 1 will be based on jdbc access.

Code base

Must be multi-platform across a wide and unknown set of server environments, including unix, linux and windows.
Signet will use Java.

UI code

Client side -- standard http/html interactions augmented by cascading style sheets and javascript.
Server side -- Java servlets and jsp.
Web/servlet engine is a site-specific choice.

The following items are site specific and not addressed as requirements:

Specific RDBMS selection
File/directory storage
Local scripting tools
Scheduling software (for integration and lifecycle tasks)

UI customization:

Only the end-user UIs are required to be customizable.
Initial requirement is to directly support the "branding" of a common UI. "Direct support" means configuration options that provide for the discrete substitution of UI elements through property declarations and delineated style sheets rather than through editing and customization of Signet code itself. This requirement only covers the level of support Signet will have for ease and transparency of customization across releases of the product. Greater site-specific customization through code or jsp modification is not precluded, but comes with its own risks.

Extending Signet functionality

The following facilities in Signet can be extended through the addition of adapter classes and style sheets. They represent functionality that must be added to Signet by the system administrator before they can be referred to by Privilege definers.

Trees
Subjects
Limit types and interface styles
Access to non-Grouper group sources
Rules

8. Unresolved

Feature requests that have not yet been explored and/or a parking lot for phase 2 features.

Privacy requirements for privilege information
Group assignment conditions, date only?
Connections to workflow to approve assignments
Ability to create template assignments
Cloning the privileges of one person to apply to another
Cross links to Grouper
Integration with Shibboleth based authorization

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。