An addition : I give a try to the build of WAGON-590.
It works like a charm, I don't even need preemptive auth.
However, I need to set the cookie-policy to 'standard' instead of
'compatibility' for the oauth2-proxy cookie to be retained during the Keycloak
round.
<configuration>
<httpConfiguration>
<all>
<params>
<!--
<property>
<name>http.authentication.preemptive</name>
<value>%b,true</value>
</property>
-->
<property>
<name>http.protocol.cookie-policy</name>
<value>standard</value>
</property>
</params>
</all>
</httpConfiguration>
</configuration>
----- Mail original -----
De: "Ionel GARDAIS" <[email protected]>
À: "users" <[email protected]>
Envoyé: Dimanche 29 Novembre 2020 14:34:57
Objet: **RSPAM** Re: [*EXT*] Re: Wagon : allow send Authorization header on
redirect
> Can you elaborate this step? How is Maven supposed to send a header when
> the target server never challenges the client?
Using
https://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication
> So, Keycloak does challenge the client with Basic?
Yes, when configured to do so.
Default authentication for browser is based on form authentication.
You can set it up to prompt for WebAuthn if wanted.
It can also use Kerberos, or delegate to another OIDC provider.
> I assume the token cookie is scoped for your entire enterprise domain?
> How do you pass the sub claim to Nexus? With RUT (claim-to-header
> transformation)?
No, the cookie is correctly scoped for the initial host and path.
1/ User asks for https://dev.example.com/nexus
2/ This request is handled by oauth2-proxy which is configured as the 'client'
of Keycloak and with Nexus as its upstream server.
3/ oauth2-proxy, because a cookie is not set, considers the user as not
authenticated, thus redirect the user to Keycloak (say https://sso.example.com).
4/ The Keycloak auth process starts and as the oauth2-proxy client is
configured for Basic auth (on Keycloak point-of-view), Keycloak issues a Basic
challenge.
Exchanges occur between user and Keycloak : if the user finally made it,
Keycloak sets a cookie for its SSO part (Host: sso.example.com) and redirect
the user to its original target.
5/ oauth2-proxy then gets the request with the SSO cookie, stating that
everything is correct and sets a cookie for itself (that is Host:
dev.example.com, Path: /nexus), speeding up next incoming requests.
oauth2-proxy retrieves user's informations from Keycloak and sets configured
headers with these informations. Say X-Auth-Preferred-Username is set to the
user's username.
6/ Then oauth2-proxy sends the request with the X-Auth-Preferred-Username
header to its configured upstream server : Nexus.
7/ Finally, as Nexus is configured to use RUT (i.e trust a configured header as
containing a pre-authenticated user's username) and because the header is set,
user is granted access to Nexus.
I hope I made it clearer.
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
