-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable evaluator response strategies for the phases of the auth pipeline #112
Comments
To comply with OAS (both swagger and 3.0), the identity requirements must include enforcing multiple identity methods to satisfy. Inspired by OAS3 spec, the authorino API could be something like this: spec:
indentity: [ Identity Requirement Object ], // Only one of the identity requirement objects need to be satisfied to identify a request.
identitySchemes: Map[string, Security Scheme Object] Having
Identity Requirement Object Examples spec:
indentity:
- my_api_key": {}
my_oidc: {}
- my_other_api_key: {} Identity Requirement Objects that contain multiple schemes require that all schemes MUST be satisfied for a request to be identified Having
|
Thanks for the suggestion, @eguzki. There are few aspects of your suggestion that I'd like to comment about (if I even got them right):
1. Object linking, reusability and extension In Authorino we don't use this pattern of having a base definition that can be extended when referred somewhere else in the CR. I know it's used in OAI specs, but I'd rather keep the way it is in Authorino for now. When we get to point where reusing definitions becomes a critical requirement, we'll probably be adding more specific CRDs and wiring things up through object refs instead. Moreover, I'm afraid of people overusing those "identity scheme" definitions and later ending up with more schemes declared than actually used in "identity requirement". Again, I know this pattern is used a lot in OAI specs, but no so much of the typical UX expected when dealing with K8s CRs, IMO. Only counterexample I can think of are of That said, maybe you were thinking that no "identity scheme" would become "garbage" inside a CR. If it's there, then it is being used. It is more about which schemes are optional and which ones are required... more on that further down in "3. Use cases" 2. Scope (of this issue) In general, I'd say your suggestion goes beyond what was originally expected with this issue, which was making two things that already exist, and that are currently hard-linked to each other in Authorino, configurable. The arrays of evaluators ( The only thing is that the mapping of the different types of arrays that correspond to each phase of the pipeline and their respective strategy is now always I was not at all hoping this to support any OAS-specific requirement. We're not going against it, of course, but there are things that we want to cover here that are unrelated to OAS (e.g. required/optional evaluators in phases other than identity verification), and at least one thing that you mentioned that is out of scope of this issue IMO (i.e. object linking, reusability and extension). 3. Use cases and implementation The implementation proposed in the description of the issue should suffice to cover the use cases "at least one evaluator is required", "all evaluators are required" an "all evaluators are optional (but still try them all just in case – i.e. no cancelling of context)". I admit that, until now, I hadn't thought about the use case "some (more than one) are required, some are optional". I guess for this other (yet uncovered) use case, a possible different implementation that not only satisfies it, but also makes it a superset of all other use cases, and yet avoids the whole linking/reusing/extending of object bits that I think are out of scope of this issue, is a simple flag At a glance, it's simple and intuitive, I think. In terms of changes required in the code to achieve it, on the other hand, this solution would be a lot harder than what I had in mind originally, because of the cancelling of the Go contexts of concurrent evaluators running in the same phase. Before triggering the phase, Authorino would have to scan the flags of all evaluators of the phase, to then monitor if all required ones have finished. (This "scan" is virtually equivalent to your proposed, more explicit, list of required ones.) If at least one among the required has failed, the pipeline can be aborted. However, if all required evaluators have finished successfully, but there are still some optional ones running, can the context be cancelled and the pipeline moved to the next phase? We'd need to think about that. Cancelling is one thing; letting the thread go all the way through and just ignore the result when it fails is a whole other thing. Anyway, it's not as straightforward as just allowing the user to choose among the existing strategies which one to apply to which phase. |
Authorino implements 3 so-called "strategies" for the 3 first phases of auth pipeline (wristband phase excluded). These strategies are:
at-least-one
);any
);all
).These strategies currently map one-to-one with the first 3 phases of Authorino's auth pipeline, respectively: identity phase, metadata phase and authorization phase. I.e.,
at-least-one
);any
);all
).This issue is a request to make how the 3 strategies map to the phases configurable, with the default strategies still falling back to the ones currently enforced.
Example for a possible implementation
The example above would be for a case where all the default strategies are overridden as follows:
Special considerations
The cases for configurable strategies in the metadata and in the authorization phases are less probably needed than the one for the identity phase, due to the existing options to represent conditionals in Authorino authorization policies (both, in OPA policies and in JSON pattern-matching policies). The configurability of the strategies would nonetheless provide another way to describe the authorization logic, at the very least improving readability in some cases.
Another thing to take into account is what happens when, in the metadata phase, the chose strategy fails (e.g.
atLeastOne
orall
enforced, but none of the sources respond)? Should Authorino reject the request as DENIED? Would this virtually be promoting the metadata sources to potential external authorizers?The text was updated successfully, but these errors were encountered: