Governing access to OpenQuake operations and artefacts
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.
Blueprint information
- Status:
- Not started
- Approver:
- John Tarter
- Priority:
- Low
- Drafter:
- Muharem Hrnjadovic
- Direction:
- Needs approval
- Assignee:
- Muharem Hrnjadovic
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
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
- 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
- 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://
[2] http://
Work Items
Dependency tree

* Blueprints in grey have been implemented.