Re: Reporting in maven. help please

2020-11-29 Thread Bernd Eckenfels
Hello,

There are a number of static code analyses which also happen to have a maven 
plugin (with sire reporting integration), for example pmd, findbugs/spotbugs, 
checker framework, checkstyle, (static-Code-analysis) Javancss, taglist, l10n 
status, jdepend and dependency-Check, and a few external tools with maven 
integration like sonarqube, lgtm or Snyk, see also here 
https://maven.apache.org/code-quality-management.html

Most of those plugins are best used when you have a matching CI plugin to 
record long term trends or if they have their own database (like sonarqube).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Aitor Iturriondobeitia 
Gesendet: Sunday, November 29, 2020 6:47:13 PM
An: Maven Users List 
Betreff: Reporting in maven. help please

Hello
i am new using maven and i am reading documentation.
Can you say me which plugins can i use for reporting the code quality?
any example?
thanks


Re: Reporting in maven. help please

2020-11-29 Thread John Patrick
Is this the documentation you said you are reading
https://maven.apache.org/plugins/index.html, as it has a reporting
section for maven maintained plugins.

but to highlight some, take a look at;
checkstyle https://maven.apache.org/plugins/maven-checkstyle-plugin/
pmd/cpd https://maven.apache.org/plugins/maven-pmd-plugin/
spotbugs (was findbugs) https://spotbugs.github.io/spotbugs-maven-plugin/

harder setup as requires installing separate tooling, and most overlap
with checkstyle, pmd and sportbugs in the free version.
sonarqube 
https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-maven/

for your dependencies look at owasp and
https://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html

If you're on github or bitbucket and are an open source project then
they have lots of both apps or integration tooling that can check
dependencies, code coverage. But if it's a closed private repo then it
will cost you something $$$ per month.

John

On Sun, 29 Nov 2020 at 17:47, Aitor Iturriondobeitia
 wrote:
>
> Hello
> i am new using maven and i am reading documentation.
> Can you say me which plugins can i use for reporting the code quality?
> any example?
> thanks

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Reporting in maven. help please

2020-11-29 Thread Aitor Iturriondobeitia
Hello
i am new using maven and i am reading documentation.
Can you say me which plugins can i use for reporting the code quality?
any example?
thanks


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

2020-11-29 Thread 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.


  

  


  
http.protocol.cookie-policy
standard
  

  

  





- Mail original -
De: "Ionel GARDAIS" 
À: "users" 
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



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

2020-11-29 Thread Ionel GARDAIS
> 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



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

2020-11-29 Thread Michael Osipov

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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



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

2020-11-29 Thread Michael Osipov

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  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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



--
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



[ANN] Apache Maven Wagon 3.4.2 released

2020-11-29 Thread Michael Osipov
The Apache Maven team is pleased to announce the release of the Apache 
Maven Wagon, version 3.4.2.


https://maven.apache.org/wagon/


Release Notes - Maven Wagon - Version 3.4.2


** Bug
* [WAGON-597] - AbstractHttpClientWagon.setPersistentPool has no 
effect due to parameter assigned to itself

* [WAGON-602] - [Regression] Preserve trailing slash in encoded URL
** Dependency upgrade
* [WAGON-601] - Use latest JUnit version 4.13.1


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



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

2020-11-29 Thread 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

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" 
À: users@maven.apache.org
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org