|
|
|
|
|
-
Name: Authorise
- Alternate Name: Authorisation, AuthZ
|
|
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.
|
| 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 |
|
-
e-Framework Service Genre Version: v1.1
|
| 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
|
JISC
|
|
|
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.
|
|
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.
|
|
|
|
|
|
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
|
|
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.
|
|
|
|
None
|
|
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.
|
|
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.
|
|
|
|
|
|
None
|
The
words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in [RFC 2119].
The Service Genre description uses
e-Framework Service Genre description elements as of 2006-12-09,
updated to include draft e-Framework service classifications. Other
terms, e.g., client, provider, and resource, are used as defined in the
e-Framework. |
|
|
|