Getting url-path and realm from AuthenticationRequest

[renegrob]

Currently I would have to create a special subclass of the Credential in order to pass more context trough the AuthenticationRequest(like in io/quarkus/oidc/OidcTokenCredential). If under a sub-path users need to be authenticated against a different domain (e.g. for a multi-tenant application), it is necessary to patch the whole authentication framework. It would be great it there were a possibility to provide a (or multiple) AuthenticationContextAugmentor or the like which allows add additional context to the AuthenticationRequest. That way oidc could provide its own AuthenticationContextAugmentor which enriches the AuthenticationRequest with the tenant information and it could be used for many other cases where more context is required. A AuthenticationContextAugmentorcould decide weather a certain context needs to be enriched or not based on its type.

AuthenticationRequest could e.g. look like this

public interface AuthenticationRequest {
        <T> T getContextAttribute(String name);
        Map<String, Object> getContextAttributes();
}

And an AuthenticationContextAugmentor would be a bean implementing the following interface:

public interface AuthenticationContextAugmentor {
        /**
        @return a map containing the attributes to add to the context or an empty map if there's noting to add
        */
        Map<String, Object> additionalContextAttributes(AuthenticationRequest authenticationRequest, RoutingContext context)
}

Attributes that are specific to an authentication mechanism can be added by the mechanism itself (e.g. realm for BASIC auth).
The AuthenticationContextAugmentors could be called from QuarkusIdentityProviderManagerImpl but it would need to know the current RoutingContext. (I guess CDI injection doesn't work there since the call is reactive.)

Probably Map<String, Uni<Object>>would be better, so that if the attribute is not consumed, no work is done.

@sberyozkin @stuartwdouglas WDYT?

PS: As I really need the path in UsernamePasswordAuthenticationRequest, should I make a pull request in Quarkus to use a derrived class and add it to a subclass of UsernamePasswordAuthenticationRequest or PasswordCredential? Or should I work on a patched version until we worked out a better solution?

[sberyozkin]

Hi @renegrob thanks; I think it would be good somehow to make RoutingContext directly available to IdentityProvider implementations. As you know the current workarund in OIDC is to pass it via the TokenCrededential classes. Instead it should really be available as a parameter - but Quarkus Security (this project) itself is not tied to Vertx,
@stuartwdouglas What do you think ? Perhaps the simple solution is to get it from the static security association map ?

[stuartwdouglas]

I think the generic context attributes idea makes sense.

[renegrob]

I would suggest then

public interface AuthenticationRequest {
        <T> T getAttribute(String name);
        setAttribute(String name, Object value);
        Map<String, Object> getAttributes();
}

I think it should be the AuthenticationMechanism's responsibility (or the AuthenticationRequestAugmentor's) to read data from the RoutingContext and populate attributes like "tenant" or "loginDomain". Shall I do a PR for the attributes? It's a very common pattern especially for this kind of decoupling. (For the Quarkus code I will open an issue in Quarkus once this is available.)

[sberyozkin]

Hi @renegrob @stuartwdouglas, sure, while the generic mechanism works, I'd not mind every concrete Credential type pass RoutingContext around as well :-) for the authentication mechanisms to pass it; that works in quarkus-oidc - in this case each identity provider can make its own check of the HTTP properties; this would not be the perfect solution but can complement the generic approach proposed by @renegrob.
@renegrob can you please open a PR as you propose here since Stuart likes the idea (he created this project) ?