Potential Auth models

[rhysrevans3]

My understanding of the transaction api's authroisation code is:

• The authorizer collects information about the user and adds it to the request state.
• The client then calls its authorize method which check the incoming payload against the generated authorisation state.

This pull request adds a pydantic model for the return of the authorizer. If the East and West authorizer middleware returns the same model it would allow us to use the same authorize method in the client.

Any objections to having a model for the return of the authorizer? Or to the structure or content of the model?

[sturoscy-personal]

Apologies if I'm missing something, isn't this already taken care of by the RequesterData and Auth models? https://github.com/ESGF/esgf-playground-utils/blob/main/esgf_playground_utils/models/kafka.py#L90-L100

[sturoscy-personal]

Perhaps a better question to ask is where would these models be used in the transaction api?

[rhysrevans3]

@sturoscy-personal Sorry I maybe misinterpreting the code or explaining poorly and please correct me if I'm wrong.

My understanding is the authorizer middleware takes the user's token and queries either Globus or EGI and retrieves the users full permission (not specific to the current request) group information is then extracted and add to the current request, which is passed to the relevant client endpoint. The endpoint then calls the authorize method which checks (using the information from the authorizer middleware) if the user has the relevant node and project permissions to perform the requested action.

Apologies if I'm missing something, isn't this already taken care of by the RequesterData and Auth models? https://github.com/ESGF/esgf-playground-utils/blob/main/esgf_playground_utils/models/kafka.py#L90-L100

You're right this does include the same information as is in the RequesterData/Auth models (so should probably use that model instead of rewriting it). But in addition to the requester data it also includes a full description of the user's permissions which we won't include in the Kafka payload.

Perhaps a better question to ask is where would these models be used in the transaction api?

This model would be output by the authorizer middleware part of the transaction API and then "consumed" by the authorize method (which would produce the Auth metadata?) still in the transaction API. So maybe a better place for this model would be within the transaction API repo as it wont be used anywhere else?