docs/spec/roles.md

docs/spec/roles.md

@@ -1,6 +1,9 @@
 ROLES and QUOTAS in NLDS
 ========================
 
+ROLES
+-----
+
 Users of NLDS can have three ROLES:
 
 1. USER
@@ -17,4 +20,18 @@ For the NLDS, the roles allow the user these capabilities:
 
 To get the information for a role, the JASMIN Accounts Portal needs to be contacted.  We may need to write a new endpoint.  Ideally we would have a single call that would return the roles that a user has for a group workspace.  However, as the group workspaces are defined as services, we may need to do more than one call.
 Users have been authenticated and authorised for the group they are trying to perform a request for.  This uses OAuth2 Resource Owner Password Flow (which is deprecated but works really well for this case), with a `client-id` and `client-secret` which are contained in the `.nlds` user config file and instantiated on the `nlds init` call that the user does first.
-However, for checking a ROLE, the NLDS will be acting on behalf of the user (who is already authenticated).  We can use the Client Credentials flow with a difference `client id` and `client secret` than that used by the Password Flow.  Varying the `client id` and `client secret` prevents any NLDS user, who has the `client id` and `client secret` in their `.nlds` config file from accessing the ROLES endpoint.
+However, for checking a ROLE, the NLDS will be acting on behalf of the user (who is already authenticated).  We can use the Client Credentials flow with a difference `client id` and `client secret` than that used by the Password Flow.  Varying the `client id` and `client secret` prevents any NLDS user, who has the `client id` and `client secret` in their `.nlds` config file from accessing the ROLES endpoint.
+
+In the NLDS code, the checking for whether a user has permission to perform certain actions is done in the `nlds/nlds_processors/catalog.py` in the functions:
+
+* `_user_has_get_file_permission`
+* `_user_has_get_holding_permission`
+* `_user_has_delete_from_holding_permission`
+
+Currently, these functions just rely on the (authenticated) user and group passed in via the message - i.e. from the user request that has trickled through the system.  This is probably fine for the first two (`_user_has_get_file_permission` and `_user_has_get_holding_permission`), as it is just checking that the group in the *Holding* matches that in the message / request.
+
+For the `_user_has_delete_from_holding_permission` we need to determine the user's ROLE, so that DEPUTIES and MANAGERS can delete other USER's data.  This will need to connect to the JASMIN accounts portal to get the user's ROLE.
+
+An added subtlety is that NLDS is designed to be **portable**, so that it can be installed on other systems, rather than just JASMIN.  This was a condition of the EU Horizon ESiWACE funding.  To do this for the other authentication, I implemented a Base Class (`BaseAuthenticator` in `nlds/authenticators/base_authenticator.py`) which is then sub-classed to `JasminAuthenticator` in `nlds/authenticators/jasmin_authenticator.py`.  There are a number of functions that return a `True` or `False` value.  I suggest we add a function to the `BaseAuthenticator`, then overload it in `JasminAuthenticator` to provide a `True` or `False` value, depending on whether the user is a MANAGER or DEPUTY of the group.
+
+Then in the call to `_user_has_delete_from_holding_permission` the `is_admin` parameter can be set from the return value of this function.