Wagon : allow send Authorization header on redirect

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Wagon : allow send Authorization header on redirect

Ionel GARDAIS
Hi list,

Is there a way to allow maven to send Authorization header on redirect like curl's --location-trusted ?

From what I understand,
[ https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 | https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 ]
restricts authentication to the target host.

However, if an SSO redirect occurs when connecting to the maven repository, auth is lost as the host is likely to have a different hostname.

Is ' maven.wagon.http.ssl.location-trusted ' something that could be implemented to bypass AuthScope ?
Or alternatively, how to authenticate maven with a multi-round auth ?
(My use case is a Nexus OSS repo with RUT enabled, behind oauth2-proxy)

Thanks,
Ionel

--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Reply | Threaded
Open this post in threaded view
|

Re: Wagon : allow send Authorization header on redirect

michaelo
Am 2020-11-28 um 22:01 schrieb Ionel GARDAIS:

> Hi list,
>
> Is there a way to allow maven to send Authorization header on redirect like curl's --location-trusted ?
>
>>From what I understand,
> [ https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 | https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 ]
> restricts authentication to the target host.
>
> However, if an SSO redirect occurs when connecting to the maven repository, auth is lost as the host is likely to have a different hostname.
>
> Is ' maven.wagon.http.ssl.location-trusted ' something that could be implemented to bypass AuthScope ?
> Or alternatively, how to authenticate maven with a multi-round auth ?
> (My use case is a Nexus OSS repo with RUT enabled, behind oauth2-proxy)

Read my extensive analysis on that topic here:
https://issues.apache.org/jira/browse/WAGON-590

I never liked that stupid redirect hell many systems perform these days,
including OIDC with Authorization Code Flow.

A question aside, how do you plan to pass the flow with stock Wagon w/o
having a browser, are you using ROPC Grant?

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [*EXT*] Re: Wagon : allow send Authorization header on redirect

Ionel GARDAIS
I agree with you : redirect hell is hard to cope with when the target tool does not provide a way to authenticate use with a side-auth. (Usually it takes the form of a token send as auth. Unfortunately this is only available with Nexus Pro along SAML auth, not the OSS one)


SSO is handled by Keycloak.
The client is configured with a ‘HTTP Basic auth flow’, that makes Keycloak use basic auth instead of a form for authentication.
oauth2-proxy redirects the request to SSO if the right cookie is not already set.

Flow would be :
- Maven connect to repository, sending the Authorization header
- auth cookie is not set so oauth proxy redirect the client to the SSO
- as with curl’s —location-trusted, Authorization header would be sent to the SSO
- the SSO accepts the auth, set the cookie and redirect the client back to the repository
- the request is catched again by oauth proxy, but due to the cookie presence, it can confirm SSO auth and set the user header so Nexus Remote User Token auth is happy and artifact downloaded.

Io


> Le 28 nov. 2020 à 22:11, Michael Osipov <[hidden email]> a écrit :
>
> Am 2020-11-28 um 22:01 schrieb Ionel GARDAIS:
>> Hi list,
>> Is there a way to allow maven to send Authorization header on redirect like curl's --location-trusted ?
>>> From what I understand,
>> [ https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 | https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 ]
>> restricts authentication to the target host.
>> However, if an SSO redirect occurs when connecting to the maven repository, auth is lost as the host is likely to have a different hostname.
>> Is ' maven.wagon.http.ssl.location-trusted ' something that could be implemented to bypass AuthScope ?
>> Or alternatively, how to authenticate maven with a multi-round auth ?
>> (My use case is a Nexus OSS repo with RUT enabled, behind oauth2-proxy)
>
> Read my extensive analysis on that topic here: https://issues.apache.org/jira/browse/WAGON-590
>
> I never liked that stupid redirect hell many systems perform these days, including OIDC with Authorization Code Flow.
>
> A question aside, how do you plan to pass the flow with stock Wagon w/o having a browser, are you using ROPC Grant?
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 30
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [*EXT*] Re: Wagon : allow send Authorization header on redirect

Ionel GARDAIS
In reply to this post by michaelo
I did miss WAGON-590 when looking around for solution.
Ideally :
- by default, AuthScope is targeted as in master
- a new param 'maven.wagon.http.ssl.location-trusted' set AuthScope to AuthScope.ANY

Thus, secured by default for common users but can be bypassed when needed.

Regards,
Ionel


--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager

----- Mail original -----
De: "Michael Osipov" <[hidden email]>
À: [hidden email]
Envoyé: Samedi 28 Novembre 2020 22:11:00
Objet: [*EXT*] Re: Wagon : allow send Authorization header on redirect

Am 2020-11-28 um 22:01 schrieb Ionel GARDAIS:

> Hi list,
>
> Is there a way to allow maven to send Authorization header on redirect like curl's --location-trusted ?
>
>>From what I understand,
> [ https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 | https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 ]
> restricts authentication to the target host.
>
> However, if an SSO redirect occurs when connecting to the maven repository, auth is lost as the host is likely to have a different hostname.
>
> Is ' maven.wagon.http.ssl.location-trusted ' something that could be implemented to bypass AuthScope ?
> Or alternatively, how to authenticate maven with a multi-round auth ?
> (My use case is a Nexus OSS repo with RUT enabled, behind oauth2-proxy)

Read my extensive analysis on that topic here:
https://issues.apache.org/jira/browse/WAGON-590

I never liked that stupid redirect hell many systems perform these days,
including OIDC with Authorization Code Flow.

A question aside, how do you plan to pass the flow with stock Wagon w/o
having a browser, are you using ROPC Grant?

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [*EXT*] Re: Wagon : allow send Authorization header on redirect

michaelo
In reply to this post by Ionel GARDAIS
Am 2020-11-28 um 22:51 schrieb Ionel GARDAIS:
> I agree with you : redirect hell is hard to cope with when the target tool does not provide a way to authenticate use with a side-auth. (Usually it takes the form of a token send as auth. Unfortunately this is only available with Nexus Pro along SAML auth, not the OSS one)
>
>
> SSO is handled by Keycloak.

OK, I snoped a bit into Keycloak. Seems to be a decent OpenID Connect
provider. My experience is limited to Ping Identity at work.

> The client is configured with a ‘HTTP Basic auth flow’, that makes Keycloak use basic auth instead of a form for authentication.
> oauth2-proxy redirects the request to SSO if the right cookie is not already set.
>
> Flow would be :
> - Maven connect to repository, sending the Authorization header

Can you elaborate this step? How is Maven supposed to send a header when
the target server never challenges the client?

> - auth cookie is not set so oauth proxy redirect the client to the SSO
> - as with curl’s —location-trusted, Authorization header would be sent to the SSO

So, Keycloak does challenge the client with Basic?

> - the SSO accepts the auth, set the cookie and redirect the client back to the repository
> - the request is catched again by oauth proxy, but due to the cookie presence, it can confirm SSO auth and set the user header so Nexus Remote User Token auth is happy and artifact downloaded.

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)?

M

>> Le 28 nov. 2020 à 22:11, Michael Osipov <[hidden email]> a écrit :
>>
>> Am 2020-11-28 um 22:01 schrieb Ionel GARDAIS:
>>> Hi list,
>>> Is there a way to allow maven to send Authorization header on redirect like curl's --location-trusted ?
>>>>  From what I understand,
>>> [ https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 | https://github.com/apache/maven-wagon/blob/c956aac9007303ce9e1746c834d58dff097ce3d6/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L613 ]
>>> restricts authentication to the target host.
>>> However, if an SSO redirect occurs when connecting to the maven repository, auth is lost as the host is likely to have a different hostname.
>>> Is ' maven.wagon.http.ssl.location-trusted ' something that could be implemented to bypass AuthScope ?
>>> Or alternatively, how to authenticate maven with a multi-round auth ?
>>> (My use case is a Nexus OSS repo with RUT enabled, behind oauth2-proxy)
>>
>> Read my extensive analysis on that topic here: https://issues.apache.org/jira/browse/WAGON-590
>>
>> I never liked that stupid redirect hell many systems perform these days, including OIDC with Authorization Code Flow.
>>
>> A question aside, how do you plan to pass the flow with stock Wagon w/o having a browser, are you using ROPC Grant?
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> --
> 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
> Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 30
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [*EXT*] Re: Wagon : allow send Authorization header on redirect

michaelo
In reply to this post by Ionel GARDAIS
Am 2020-11-29 um 11:38 schrieb Ionel GARDAIS:
> I did miss WAGON-590 when looking around for solution.
> Ideally :
> - by default, AuthScope is targeted as in master
> - a new param 'maven.wagon.http.ssl.location-trusted' set AuthScope to AuthScope.ANY

OK, definitively something I won't reject in the first place. I will
look into curl's source code and think about this as part of WAGON-590.

There are mechanisms which do not suffer from this issue like SPNEGO and
mutual TLS.

Let's continue this discussion in WAGON-590.

M

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [*EXT*] Re: Wagon : allow send Authorization header on redirect

Ionel GARDAIS
In reply to this post by michaelo
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: **RSPAM** Re: [*EXT*] Re: Wagon : allow send Authorization header on redirect

Ionel GARDAIS
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" <[hidden email]>
À: "users" <[hidden email]>
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: [hidden email]
For additional commands, e-mail: [hidden email]
--
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: [hidden email]
For additional commands, e-mail: [hidden email]