Governing access to OpenQuake operations and artefacts

Registered by Muharem Hrnjadovic

Authorization involves verifying that an authenticated subject has permission to perform certain operations or access specific resources. We need to govern access to all OpenQuake operations and resources.

Whiteboard

= Authorisation =

Authorization involves verifying that an authenticated subject has
permission to perform certain operations or access specific resources.
Authentication, therefore, must precede authorization [1].

Requirements:
    - we need to govern access to all OpenQuake operations and resources i.e.
      access to
        - OpenQuake artefacts like source models and calculation results
          (artefact permissions)
        - OpenQuake operations like running certain calculators
          (operational permissions)

    - we need to have permission defaults for OpenQuake resources per
      organisation. These cover
        - what artefacts the user is allowed to access in what way
          (artefact permissions)
        - what operations the user is allowed to invoke (operational
          permissions)

    - newly created users should have their artefact permission
      defaults initialised from the organisation's defaults

    - newly created users should have their operational
      permissions initialised from the organisation's defaults

    - the access permissions for a newly created OpenQuake artefact
      should be initialised from the user's artefact permission defaults

    - OpenQuake administrators need to be able to change the permissions
      of any OpenQuake artefact

    - OpenQuake administrators need to be able to change the operational
      permissions of any user

    - users should be able to change their own artefact permission
      defaults

    - users should be able to change the permissions of any artefact
      they own

    - we need to have an audit log that captures every OpenQuake
      resource access/utilisation

    - we need to have an audit log that captures every OpenQuake
      administrator action

    - we need to have an audit log that captures all OpenQuake artefact
      permission changes

    - The OpenQuake audit log must be protected from tampering

    - OpenQuake administrators need to be able to view the OpenQuake
      audit log

    - access permissions for OpenQuake artefacts shall be enforced on
      file system level as well

== User stories ==

This applies to all OpenQuake clients whether command line driven or GUI.

As the administrator for a given OpenQuake installation I want to be
able to:
  1 - define OpenQuake artefact permission defaults for an organisation
  2 - define OpenQuake operational permission defaults for an
      organisation
  3 - define OpenQuake artefact permission defaults for a user
  4 - set a user's operational permissions
  5 - set the permissions of an OpenQuake artefact irrespective of
      ownership
  6 - view the OpenQuake audit log

As an ordinary OpenQuake user I want to be able to
  7 - change my OpenQuake artefact permission defaults
  8 - set the permissions of any OpenQuake artefact I own

= Notes =

    - I understand we need to lock down access to OpenQuake resources on the
      file system level due to users login into machines via ssh and using the
      command line client.
      One way to go about this is to have a matching operating system user and
      group for each OpenQuake user and organisation respectively.

= Questions =

    - do we need fully-fledged access control lists (ACL, [2])?
      According to dmonelli this is not required.

= References =

[1] http://en.wikipedia.org/wiki/Authentication
[2] http://en.wikipedia.org/wiki/Access_control_list

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.