Negotiate Access to Resource

Introduction

A user wants to access a resource; this may be a service, a piece of hardware, or a catalogue. Some resources may be available to public users, but most will require user authentication and permissions.

Flow of Events

A user attempts to access a resource through a web browser or command line. If the resource can be accessed through public permissions, the user is admitted access. If the resource requires specific permissions, astrogrid checks to see whether the user has logged on. If the user has not logged on, a message advises the user to log on. If the user has logged on, his or her permission set is checked against the resource’s required permissions. If the permissions match, the user is granted access to the resource. If the user’s permissions do not match, a message advises the user that he or she does not have permission to access this resource.

Sequence Diagram

-- ElizabethAuden - 15 Jun 2002

An alternative mode:

• User does not store a permission set.
• Resource asks resource permissions for authorization data (as per diagram above)
• Permissions store replies to resource.
• Resource checks permissions and either does the job or sends the rejection to User.

This decouples the user from the resource-permissions entity, which is likely to make the use case easier to implement.

Another alternative:

• Keep the idea of the users' permissions set.
• User gets the permissions set from the resource permissions entity before the use-case starts; possibly when logging on to the grid.
• Resource can check the permissions itself; it doesn't need to go out to the resource permissions entity to check.

-- GuyRixon - 18 Aug 2002