Contributions > Service Genres > Authorise Login
  Minimize
 
 
  Print  Minimize
Name
 
  • Name: Authorise
  • Alternate Name: Authorisation, AuthZ
Rationale
 

The Service Genre describes authorisation, the process of establishing what a principal is permitted to do. Authorisation determines access rights to system objects based on identity.

Version
 
  • e-Framework Service Genre Version: v1.1
Description
 

Authorisation is the process of establishing what a principal is permitted to do. Authorisation typically occurs after Authentication so that the principal can be identified. Authorisation may also use a principal’s attributes, information about what the principal is intending to do (the target), and environment information to make authorisation decisions.

Terms:

  • Principal – individual (end-user), service, server, group or organisation that may wish to authenticate.
  • Subject – the principal.
  • Authentication – the process of verifying the identity of a principal based on authentication credentials.
  • Identifier – a unique object (generally string) used to represent a principal. The Identifier typically represents an authenticated principal.
  • Principal Attribute – a single piece of information or property of the principal that has been provided by authentication or by association with their identifier.
  • Target – the application, system, resource or object for which we are establishing what the principal can do. The target may be a specific action or set of actions on an application, system or resource.
  • Provisioning – the process of adding principals to an identity store, establishing initial credentials, and determining their entitlements (authorisation).
  • Relying Party – a service, system, resource, application or entity that relies on the authentication.
  • Permissions – the set of actions that a principal is permitted to do. This may be in the context of a specific target or may include which actions on which targets.
Functionality
 

Authorisation can support two separate processes.

The first process is determining the principal’s permissions, the set of actions or requests that a principal is able to perform. This typically occurs immediately after authentication. The permissions may be used by the principal to determine further actions, to notify them of what they have access to, or to allow them to establish further actions or obligations to allow further access. The permissions may be used by the application to present to the principal what they are able to do, and to prevent actions and requests that are not permitted for the principal.

The second process is determining that a principal is authorised to perform a certain action on a target or set of actions on targets. The response will inform the principal or application if the target action may proceed.

Authorisation can occur at any point in an application or choreography of services. It may occur once on initial access, prior to certain privileged actions, or prior to every service.

Usage Scenarios
 

 

Applicability
 

 

Requests & Behaviours
 

Any Service Expression that conforms to the Authorisation Service Genre:

  • SHOULD accept a principal’s identifier
  • MAY accept a principal’s attributes
  • MAY accept target information
  • MAY accept environment information
  • SHOULD return one of the following:
    • the principal’s permissions for the target or for a set of targets (first process outlined in functionality); OR
    • whether or not the principal may perform the target action (second process outlined in functionality)
  • MAY return reasons why authorisation has been denied
  • MAY return how to obtain further permissions or authorisation
Use & Interactions
 

The following is the typical process of authorisation for the first process outlined in functionality:

  • Principal is identified. This MAY occur by an authentication process or service.
  • Principal’s attributes, target information and environment information MAY be collected. Principal’s attributes may be the result authentication or may be stored in an identity directory. Target information may include an identifier for the target and attributes about the target. Environment information may include the time of day, physical location or other information regarding the principal and target.
  • Authorisation service is sent principal and other information and returns the principal’s permissions.
  • Permissions MAY be cached for evaluation on later actions on targets.
  • Requested actions on targets are compared with permissions to allow or deny the request.

The following is the typical process of authorisation for the second process outlined in functionality:

  • Principal is identified. This MAY occur by an authentication process or service.
  • Principal’s attributes and environment information MAY be collected. Target information MUST be collected and MAY include actions requested. Principal’s attributes may be the result authentication or may be stored in an identity directory. Target information may include an identifier for the target and attributes about the target. Environment information may include the time of day, physical location or other information regarding the principal and target.
  • Authorisation service is sent principal and other information and returns whether the principal is allowed to perform to target action or not.
  • If authorised target action is allowed to proceed.
  • If not authorised target action is aborted. The principal MAY be informed of the failed action and MAY be informed of reasons for the failure.

Authorisation SHOULD occur after Authentication so that the principal can be identified. Principal attribute may be obtained from the authentication process or from a directory.

Structure
 

 

Applicable Standards
 

None

Design Decisions and Tradeoffs
 

This Authorise Service Genre was designed in the absence of Service Expressions with the following technologies in mind: XACML, MAMS Autograph, Unix file permissions, database permissions.

Implementation Guidance and Dependencies
 

Authorisation may be supported by one or more stores of permissions for an application or system, or permissions may be stored with each service, resource, or object. Identity directories are typically used to store identities, attributes, roles and group information which may be accessible to an Authorise service but is typically used by an Authenticate service to evaluate principal attributes. Such stores and directories may be maintained by provisioning systems responsible for the creation, update and deletion of identities and permissions.

Authorisation may provide, be dependent on or support an audit trail of principals, permissions given and other information.

Known Uses
 

 

Related Service Usage Models (SUMs)
 
Related CORE SUMs
 

None

Classification
 
Domain(s) [ ] Learning & Teaching [ ] Research
[ ] Libraries
[ ] Administration
[ ] IT Services
[X] Common
Maturity [ ] Immature [X] Mature
Development Scale [ ] Isolated [X] Ubiquitous
Status [X] Approved [ ] Placeholder
[ ] Unapproved
[ ] Superseded
[ ] Withdrawn
Confidence Level [ ] High [X] Medium [ ] Low
Version History
 
Version Date Author Description Organisation / Project
v1.0 2007-02-28 Lyle Winton  Initial Draft DEST
v1.1 2007-03-07 Phil Nicholls Approved by eFIG e-Framework
Intellectual Property
 

© Copyright, e-Framework Partners 2007

Attribute this work as:
Authorise Genre, The e-Framework Partners, 2007. Derived from...

Attribution History:

  1. Derived from Authorise Genre Submission authored and submitted by Lyle Winton on behalf of DEST (e-Framework Partner), 2007

Last updated 14 October 2008

 
 
Related SUMs Minimize
 
  Minimize
Unless otherwise noted material from the e-Framework website can be downloaded for your own use under a Creative Commons Attribution-ShareAlike 2.5 Australia License
CreativeCommons-by-sa.png
 
Friday, December 05, 2008
Copyright e-Framework Partners 2006 - 2008

Terms and Conditions

Privacy Statement