Policy support

[chrisburr]

In many parts of DIRAC we need to be able to configure policies about what information can be accessed. For example, in the WMS the JobPolicy class and v option is used to be able to configure if users can access each other's jobs.

My current suggestion for this is to extend the existing security properties to be finer-grained, for example the various WMS access configuration methods could be three separate security properties like JOB_CREATE, JOB_MANAGE and JOB_MONITOR. We then need to handle 4 different cases of granularity with which these properties can be applied:

1. own: Applies to objects owned by the current user
2. group: Applies to objects owned by the current user group
3. vo: Applies to objects owned by the current VO
4. installation: Applies to all objects in the installation

For example, some of the current DIRAC options can be mapped as:

• GlobalJobsInfo in the CS is equivilent to giving all groups JOB_MONITOR(vo)
• JOB_ADMINISTRATOR in the CS is equivilent to JOB_MANAGE(vo) and JOB_MONITOR(vo)
• NormalUser is JOB_CREATE(own), JOB_MANAGE(own) and JOB_MONITOR(own)
• JOB_SHARING is roughly the same as JOB_MANAGE(group) and JOB_MONITOR(group)

This will hopefully lead to a clean implementation of the "Installation Admin VO" with admins having JOB_MANAGE(all) and JOB_MONITOR(all).

This is the groundwork for #23.

[chaen]

Summary of the current thoughts:

• We want a plugable system that a VO can extend
• There would be one plugin per system
• the default plugins reproduce the behavior of DIRAC based on properties
• Safety net: since it is all run time based, it is too complicated to evaluate that every methods actually calls the plugins, so we rely on checking that all routes have a dependency on the policy plugin, and violently exiting if that dependency is not called
• Plugins are based on "action" (Read, write, manage, etc). It is less flexible that going for full function name, but safer when adding new method. We will provide a doc how to make function specific cases.
• Big change with respect to current DIRAC: the bulk operations are binary, i.e. you are either allowed on all, or None. Effectively, that means that if you try killing several jobs, some of which you can and others you can't, none will be killed (different from DIRAC)

[chaen]

TODO:

• Write tests for the policy mechanism (Policy Mechanism #227)
• nicer error message for crash
• Test that every route has the dependency on a policy check (Policy Mechanism #227)
• implement the actual job policy