feat: add ulims authz policy

[MattPrit]

Summary: Adds authZ policy for use in ULIMS services. Essentially, this moves the existing ULIMS policy into the central repository, with the addition of service account support and a new rule for filtering a list of instruments

Added rules:

• allow - top-level check that the user has been verified
• session_restrictions - returns the sessions that the user has access to, in the format [{"beamline": "i03", "proposal_number": 1, "visit_number": 1}, ...]
• filter_sessions - given an input instrument_sessions of (proposal number, session number) pairs, return those pairs corresponding to session that the user has access to
• filter_instruments - given an in put instruments, a list of instrument names, return those that the user has access to (i.e is an admin of)

Note: There is a section of policy that I have copied from tiled.rego

Note: Some of the rules depend on token.claims.beamline, I suspect that more generally we would like token.claims.instruments, but I have used beamline for consistency with tiled.rego

[ZohebShaikh]

I like the docs that you have put for the policy, We should add a regal lint for this if possible in a separate PR.

Note: Some of the rules depend on token.claims.beamline, I suspect that more generally we would like token.claims.instruments, but I have used beamline for consistency with tiled.rego

I agree we should make the change from beamline to instrument. The faster we do this the better as it will have lesser impact. This needs to be changed from the bundler as well

[MattPrit]

I agree we should make the change from beamline to instrument. The faster we do this the better as it will have lesser impact...

What about multi-valued claims (i.e. multiple instrument access)? Should I move to token.claims.instrument and assume a single value for now?

[ZohebShaikh]

What about multi-valued claims (i.e. multiple instrument access)? Should I move to token.claims.instrument and assume a single value for now?

I'm little reluctant to add instruments because I feel like the UDC client should be 1 per beamline and I have not come across a use case where 1 beamline needs access to 2 or more beamlines data.
So I think we should leave it to a single value for now

[ZohebShaikh]

Apologies I was on holiday then on sick leave and this might have slipped through the cracks. Looks Good
Only thing to do before merge is to squash/ rewrite commit history