Add authorization scope mechanism #288

wilbrdt · 2023-03-20T11:12:24Z

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe.
With the addition of the OpenId Connect authentication into Ralph, we should, as mentionned by the xAPI spec, implement scopes.

Describe the solution you'd like
In a first implementation, we could implement the following scopes:

all/read
all
statements/write
statements/read
statements/read/mine

Discovery, Documentation, Adoption, Migration Strategy
We will probably have to add an Authority mechanism, necessary for the statements/read/mine scope.

The text was updated successfully, but these errors were encountered:

In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field

In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.

In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.

In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.

In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.

…g authority In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.