Session authentication for REST endpoints

[chrisburr]

As #4650 requires the addition of authenticated REST API endpoints in DIRAC that don't use certificate authentication, I think it would be a good idea to decide how we want to manage the session credentials. This can then be the basis for which services can start to be exposed over HTTPS in a RESTful way.

I think there are two options which are most suitable, both of which would be sent as a HTTP header (Authorization: Bearer <token>):

1. Session token: A random number is generated and stored in a database. Every connection then has to query the database to find which user and group this sessions corresponds to.
2. JSON Web Tokens (JWT/RFC 7519): The user identifier, group and any other metadata is stored as a token which is then signed using a secret on the server. The validity of this signature, and hence the session data, can be validated without needing to store any state on the server side.

I think using JWT would be beneficial for the following:

1. Scalability: Services can validate credentials without adding any load to a database or a centralised authentication service.
2. Reliability: If the database is ever unavailable users can still create new sessions and continue to use pre-existing sessions.

The main downside of JWT is that revoking compromised tokens can be tricky. This probably isn't a big deal as we currently can't revoke credentials very easily but there are methods by which it could be done. The simplest would probably be to add an "epoch" field to each user in the CS which is then included in all tokens which are issued. The "epoch" field can then incremented to revoke all of a user's pre-existing tokens on demand.

Other things that we might want to consider:

• How does this work with instances running for multiple VOs? Should the VO be included in the token?
• Should this support limiting the scope of tokens at a finer-grained level than the current groups (e.g. including a list of services a given token is/isn't allowed to access)?

Are there any other considerations or reasonable alternatives that people can think of?

[TaykYoku]

@chrisburr, I completely agree that need to use JWT tokens. I am currently preparing some changes for PR related to the use of JWT tokens instead of sessions stored in cookies.

I think the access token, excluding standard things, should contain the following things:

• DIRAC setup,
• DIRAC user group,
• user ID (which will then be mapped to the DIRAC user username in CS, as well as DN in the case of using a certificate),
• token expiration time

IMHO:

How does this work with instances running for multiple VOs? Should the VO be included in the token?

Since the group belongs to VO, having a group in the token, we uniquely define VO. But see no problem adding this as an extra scope.

Should this support limiting the scope of tokens at a finer-grained level than the current groups (e.g. including a list of services a given token is/isn't allowed to access)?

I think it might make sense to add the ability to accept AuthManager instead of groups (which for access is essentially a list of DIRAC properties) just a list of DIRAC properties. Then, during authentication, a list of properties is requested instead of or together with the group, and after successful authentication, check whether all the properties correspond to the DIRAC user and add them to the proxy as extension or token as scope.
But I'm not sure that this should be addressed in the context of this PR, as it can be implemented with a proxy authentication flow.

[chaen]

+1000 for JWT.

Since the group belongs to VO, having a group in the token, we uniquely define VO. But see no problem adding this as an extra scope.

I don't think it's always the case. Think of diracAdmin for example.

[chaen]

Also I agree with @TaykYoku that we should delay the change of granularity for authorization, if ever.

[fstagni]

@TaykYoku can you confirm (or not) that this task has been already taken into account? In that case, it could be closed.

[TaykYoku]

later we decided:

1. refrain from using tokens signed by DIRAC itself.
2. use as much as possible the standard implementation (OAuth 2.0).

Currently, the organization of the authorization session (here we consider only tokens) is as follows:

1. the user is authorized through DIRAC Aurthorization Server
2. A record of the Refresh Token is stored in a database tied to the time of use! (this is required to protect against reuse)
3. DIRAC Aurthorization Server encrypts the Refresh Token and sends it and the Access Token to the user
4. the user uses the Access Token (when authenticating such a request, you do not need to access the database, all information must be contained in the token, but much depends on the IdP that issued it)
5. when the Access Token expires TornadoClient makes a request to DIRAC Authorization Server to get new tokens (here Refresh Token is decrypted and checked with a record in the database, if this Refresh Token has already been used then the session is canceled, tokens revoking from the IdP. Otherwise the request is redirected to IdP and we return to point 2.

Since we use tokens issued by a third-party IdP, we cannot arbitrarily add our claims to the token. So we have to rely on those claims that support IdP.

[TaykYoku]

The basic explanation of the authorization process is considered in #5548.
The basic logic of authentication of incoming requests for access to DIRAC resources is in BaseRequestHandler #5399.
In general, the whole 8.0 release is about it, so in my opinion, if no one @chrisburr @chaen @atsareg has any questions or opinions about it, then in this case @fstagni can close this issue.

[TaykYoku]

@fstagni, can you please add OAuth2 label here.