Simple auth within multi-requests

[cnweaver]

This patch adds a new 'authentication mechanism' for sub-requests within a multi-request, which simply gives them the same authentication as the parent multi-request. This is useful because it allows multi-reuqests without needing to get a token issued, as long as all of the sub-requests are intended to execute with the same authentication and privileges.

Implementation details:

• As noted in the comments, this works by copying the results produced by the authentication procedure, so it skips needing to perform the authentication again.
• This does rely on reaching directly into the rest_framework.request.Request's _request property. There didn't seem to be an obviously better way to attach the necessary information to it, since it has to survive passing through the initialize_request function.

[jnation3406]

So at the risk of sounding dumb, I'm going to ask why we are doing all of this in the first place? If it is because the authentication (SCRAM) process takes too much overhead, then rather then do this kind of hacky stuff, can't we just rely on the rest framework authtoken for authentication instead? It's already listed on the MultiRequest as an authentication_class option. Is there some security issue with allowing the use of authtokens? If we used authtokens then authentication would be speedy and you might not even need MultiRequest in the first place.

[cnweaver]

Getting a token issued requires doing SCRAM auth in the first place, and leaving the token to expire and have to be garbage collected seems ugly for one-shot API requests. Using the explicit scram routes in the hopauth API to get a token would also require the archive API to parse the authorization headers it gets from the user, at least partially, I think, instead of just passing them through.

There is no security issue that I can think of with using the authtokens (the archive API would not need to expose them to the end user, even); they would just be somewhat awkward and inefficient to use in this situation. It's worth noting that using authtokens would require strictly more requests to the hopauth API (and so more latency) than using SCRAM auth (one request to begin the SCRAM exchange, one to complete it and get the token, and then finally a (multi) request to get the desired data using the token, while with HTTP SCRAM auth the completion of the SCRAM handshake also is the request for the desired data.) The multi-request is useful in either case, as it allows paying the latency cost only once to fetch two loosely connected bits of data. It would be possible to do two separate requests with a token, for a total of 4 requests of latency, which would be as bad as two double requests using HTTP SCRAM (although threading the state through two separate HTTP SCRAM handshakes would be tricky).

[jnation3406]

Getting a token issued requires doing SCRAM auth in the first place, and leaving the token to expire and have to be garbage collected seems ugly for one-shot API requests. Using the explicit scram routes in the hopauth API to get a token would also require the archive API to parse the authorization headers it gets from the user, at least partially, I think, instead of just passing them through.

There is no security issue that I can think of with using the authtokens (the archive API would not need to expose them to the end user, even); they would just be somewhat awkward and inefficient to use in this situation. It's worth noting that using authtokens would require strictly more requests to the hopauth API (and so more latency) than using SCRAM auth (one request to begin the SCRAM exchange, one to complete it and get the token, and then finally a (multi) request to get the desired data using the token, while with HTTP SCRAM auth the completion of the SCRAM handshake also is the request for the desired data.) The multi-request is useful in either case, as it allows paying the latency cost only once to fetch two loosely connected bits of data. It would be possible to do two separate requests with a token, for a total of 4 requests of latency, which would be as bad as two double requests using HTTP SCRAM (although threading the state through two separate HTTP SCRAM handshakes would be tricky).

Yeah I guess I was thinking of users authenticating with SCRAM once with scimma-auth to get their token, and then their token persists "forever" (until revoked) and can be used with their archive requests and passed through to scimma-auth rather than using SCRAM at that point. So the token would be used for both authentication and permissions and you could ignore the SCRAM after initially using it to setup your account with scimma-auth. Then you never incur the latency penalty of the SCRAM auth in day-to-day usage. But I agree that as things stand right now (no auth tokens), your way of multi-requests to cut down on latency of extra requests and extra SCRAM auth is good.

[dpetravick]

The changes appear to maintain the level of authentication of the previous version