Skip to first unread message
Jörg Sesterhenn
Oct 26, 2016, 3:37:24 AM10/26/16
to SonarQube
Hello,
as suggested by Julien Lancelot in https://jira.sonarsource.com/browse/SONAR-5430 I'd like to bring up this topic, to see if there might be a general interest in a new SSO Feature in SonarLint.
There is now a feature in Sonarqube that allows to generate a token for authentication. The way I see it this is a mere workaround to not have to update my password as often as I should - which is a bad thing.
Starting from Sonarqube 6.2 it is possible to authenticate to Sonarqube Server via RUT (https://jira.sonarsource.com/browse/SONAR-5430).
This enables us to put a proxy in front of Sonarqube that handles Kerberos login with a ticket that is granted at Windows Login. This frees the developers from the constant hassle to authenticate against every piece of build infrastructure.
My proposal: If SonarLint would be able to hand over the Kerberos Ticket to Sonarqube then developers wouldn't have to worry about authentication after Windows Login.
What do you think: Would you use that feature? Are there alternative solutions? (How) do you use them?
Kind regards,
Jörg
as suggested by Julien Lancelot in https://jira.sonarsource.com/browse/SONAR-5430 I'd like to bring up this topic, to see if there might be a general interest in a new SSO Feature in SonarLint.
There is now a feature in Sonarqube that allows to generate a token for authentication. The way I see it this is a mere workaround to not have to update my password as often as I should - which is a bad thing.
Starting from Sonarqube 6.2 it is possible to authenticate to Sonarqube Server via RUT (https://jira.sonarsource.com/browse/SONAR-5430).
This enables us to put a proxy in front of Sonarqube that handles Kerberos login with a ticket that is granted at Windows Login. This frees the developers from the constant hassle to authenticate against every piece of build infrastructure.
My proposal: If SonarLint would be able to hand over the Kerberos Ticket to Sonarqube then developers wouldn't have to worry about authentication after Windows Login.
What do you think: Would you use that feature? Are there alternative solutions? (How) do you use them?
Kind regards,
Jörg
Mike Barry
Oct 26, 2016, 1:28:47 PM10/26/16
to SonarQube
I'd love this idea. I wouldn't need to educate my users how to manage tokens.
Mike
Marcel
Oct 26, 2016, 2:45:33 PM10/26/16
to SonarQube
+1
ma...@majcica.com
Oct 27, 2016, 3:01:18 AM10/27/16
to SonarQube
Since SSO was kicked out in version 6.0 I was looking at this feature. It will be very welcome.
Jörg Sesterhenn
Oct 27, 2016, 3:17:38 AM10/27/16
to SonarQube
Could someone (who has the required rights) create an issue in the sonarsource Jira so that we can vote on it?
TIA
Jörg
TIA
Jörg
Julien HENRY
Oct 27, 2016, 4:12:51 AM10/27/16
to SonarQube
Hi guys,
I prefer to not create a ticket since I'm 99% sure (never say never :) ) we will not implement that. Going this way we would need to support all SSO protocol (even home made?) in SonarLint. If you take example of oauth / GitHub authentication, this is by nature web based so not applicable in an IDE AFAIK. That's why this concept of user token was introduced. Using its web browser (and SSO) any user can go to it's preference page and generate a token per application.
If you are using SonarLint for IntelliJ, there is even a nice button to directly let user to open the token generation page:
So if you think this would help to educate your users, here I'm ready to create a ticket to do the same in SonarLint for Eclipse.
++
Julien
Jörg Sesterhenn
Oct 27, 2016, 7:01:07 AM10/27/16
to SonarQube
Hi Julien,
this button will definetly improve the workaround we are currently using, so please go ahead and implement it!
Tokens are still only a workaround:
- they invite to never update the token making it less secure
- they still require users to reenter/regenerate the token whenever the saved token goes astray, or a new IDE is setup.
I see why you would decide to drop SSO as a client feature because there are just to many implementations around.
That beeing said - you could make authentication pluggable. You could provide an extensionpoint that others could use to implement whatever SSO solution they fancy...
In our setup that would probably be a little plugin that would use waffle to get the ticket and hand it on.
How are the chances of that happening?
regards,
Jörg
this button will definetly improve the workaround we are currently using, so please go ahead and implement it!
Tokens are still only a workaround:
- they invite to never update the token making it less secure
- they still require users to reenter/regenerate the token whenever the saved token goes astray, or a new IDE is setup.
I see why you would decide to drop SSO as a client feature because there are just to many implementations around.
That beeing said - you could make authentication pluggable. You could provide an extensionpoint that others could use to implement whatever SSO solution they fancy...
In our setup that would probably be a little plugin that would use waffle to get the ticket and hand it on.
How are the chances of that happening?
regards,
Jörg
Julien HENRY
Oct 27, 2016, 7:31:06 AM10/27/16
to SonarQube
Le jeudi 27 octobre 2016 13:01:07 UTC+2, Jörg Sesterhenn a écrit :
Hi Julien,
this button will definetly improve the workaround we are currently using, so please go ahead and implement it!
That beeing said - you could make authentication pluggable. You could provide an extensionpoint that others could use to implement whatever SSO solution they fancy...
In our setup that would probably be a little plugin that would use waffle to get the ticket and hand it on.
Sorry I'm not experimented with Kerberos. Once you have the ticket, how would you pass it to perform authenticated HTTP request? Is your proxy expecting to find the ticket in the "Authorization" header? Or should it be set as another header?
How are the chances of that happening?
Depends on the way you pass your ticket (see previous question). If ticket is a replacement for SQ username/password or token (ie passed as a Basic authentication credential) that could be quite easy to do (transparent for sonarlint-core / sonar-ws libraries). If we need to do modifications in the whole stack to support SSO, that's unlikely to happen.
Jörg Sesterhenn
Oct 27, 2016, 9:36:01 AM10/27/16
to SonarQube
Am Donnerstag, 27. Oktober 2016 13:31:06 UTC+2 schrieb Julien HENRY:
Le jeudi 27 octobre 2016 13:01:07 UTC+2, Jörg Sesterhenn a écrit :Hi Julien,
this button will definetly improve the workaround we are currently using, so please go ahead and implement it!
Just voted for it.
That beeing said - you could make authentication pluggable. You could provide an extensionpoint that others could use to implement whatever SSO solution they fancy...
In our setup that would probably be a little plugin that would use waffle to get the ticket and hand it on.Sorry I'm not experimented with Kerberos. Once you have the ticket, how would you pass it to perform authenticated HTTP request? Is your proxy expecting to find the ticket in the "Authorization" header? Or should it be set as another header?
Currently we have implemented a Kerberos SSO client against TeamCity-Rest API. Here we use a simple RequestFilter to add an "Authorization" Header based on the Kerberos Token. The Headervalue looks like
"Negotiate <base64encoded-kerberostoken>".
How are the chances of that happening?Depends on the way you pass your ticket (see previous question). If ticket is a replacement for SQ username/password or token (ie passed as a Basic authentication credential) that could be quite easy to do (transparent for sonarlint-core / sonar-ws libraries). If we need to do modifications in the whole stack to support SSO, that's unlikely to happen.
Since this apears indeed to be "quite easy" - would you create an issue for this as well please?
Julien Lancelot
Oct 27, 2016, 11:13:22 AM10/27/16
to Jörg Sesterhenn, SonarQube
On Thu, 27 Oct 2016 at 15:36 Jörg Sesterhenn <joerg.se...@gmail.com> wrote:
Am Donnerstag, 27. Oktober 2016 13:31:06 UTC+2 schrieb Julien HENRY:Le jeudi 27 octobre 2016 13:01:07 UTC+2, Jörg Sesterhenn a écrit :Hi Julien,
this button will definetly improve the workaround we are currently using, so please go ahead and implement it!Just voted for it.That beeing said - you could make authentication pluggable. You could provide an extensionpoint that others could use to implement whatever SSO solution they fancy...
In our setup that would probably be a little plugin that would use waffle to get the ticket and hand it on.Sorry I'm not experimented with Kerberos. Once you have the ticket, how would you pass it to perform authenticated HTTP request? Is your proxy expecting to find the ticket in the "Authorization" header? Or should it be set as another header?
Currently we have implemented a Kerberos SSO client against TeamCity-Rest API. Here we use a simple RequestFilter to add an "Authorization" Header based on the Kerberos Token. The Headervalue looks like
"Negotiate <base64encoded-kerberostoken>".
How are the chances of that happening?Depends on the way you pass your ticket (see previous question). If ticket is a replacement for SQ username/password or token (ie passed as a Basic authentication credential) that could be quite easy to do (transparent for sonarlint-core / sonar-ws libraries). If we need to do modifications in the whole stack to support SSO, that's unlikely to happen.
Since this apears indeed to be "quite easy" - would you create an issue for this as well please?
I don't really see the "quite easy" part as I don't see how the SonarQube server will do the authentication ?
Because AFAIK there's no Kerberos Authentication Plugin available.
regards,
Jörg
Am Donnerstag, 27. Oktober 2016 10:12:51 UTC+2 schrieb Julien HENRY:Hi guys,I prefer to not create a ticket since I'm 99% sure (never say never :) ) we will not implement that. Going this way we would need to support all SSO protocol (even home made?) in SonarLint. If you take example of oauth / GitHub authentication, this is by nature web based so not applicable in an IDE AFAIK. That's why this concept of user token was introduced. Using its web browser (and SSO) any user can go to it's preference page and generate a token per application.If you are using SonarLint for IntelliJ, there is even a nice button to directly let user to open the token generation page:
So if you think this would help to educate your users, here I'm ready to create a ticket to do the same in SonarLint for Eclipse.
++
Julien
Le jeudi 27 octobre 2016 09:17:38 UTC+2, Jörg Sesterhenn a écrit :Could someone (who has the required rights) create an issue in the sonarsource Jira so that we can vote on it?
TIA
Jörg
Am Mittwoch, 26. Oktober 2016 09:37:24 UTC+2 schrieb Jörg Sesterhenn:Hello,
as suggested by Julien Lancelot in https://jira.sonarsource.com/browse/SONAR-5430 I'd like to bring up this topic, to see if there might be a general interest in a new SSO Feature in SonarLint.
There is now a feature in Sonarqube that allows to generate a token for authentication. The way I see it this is a mere workaround to not have to update my password as often as I should - which is a bad thing.
Starting from Sonarqube 6.2 it is possible to authenticate to Sonarqube Server via RUT (https://jira.sonarsource.com/browse/SONAR-5430).
This enables us to put a proxy in front of Sonarqube that handles Kerberos login with a ticket that is granted at Windows Login. This frees the developers from the constant hassle to authenticate against every piece of build infrastructure.
My proposal: If SonarLint would be able to hand over the Kerberos Ticket to Sonarqube then developers wouldn't have to worry about authentication after Windows Login.
What do you think: Would you use that feature? Are there alternative solutions? (How) do you use them?
Kind regards,
Jörg
--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/7620c812-e4e3-4ee9-8fde-c1790b4c7804%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Julien LANCELOT | SonarSource
Jörg Sesterhenn
Oct 27, 2016, 2:41:51 PM10/27/16
to SonarQube
That is where the Sonarqube RUT plugin (https://jira.sonarsource.com/browse/SONAR-5430) comes in:
1. We hand over the kerberos token from SonarLint (as Http-header) to a Kerberos-Valve (http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve) in our Http-proxy.
2. The proxy then hands on the authentication as Http-header (RUT) to the Sonarqubeserver.
See, it is totally easy ;-)
Jörg Sesterhenn
Nov 2, 2016, 4:17:13 AM11/2/16
to SonarQube
Hello Julien Henry and Julien Lancelot,
I wonder if I was able to describe our usecase properly. If you need any additional information I'd be happy to provide it.
I'd love to hear if there is any chance that you might support our (and that of others - see responses above) usecase by making SonarLint extendable or configurable in a way that we can add our own authorization headers?
I wonder if I was able to describe our usecase properly. If you need any additional information I'd be happy to provide it.
I'd love to hear if there is any chance that you might support our (and that of others - see responses above) usecase by making SonarLint extendable or configurable in a way that we can add our own authorization headers?
Am Donnerstag, 27. Oktober 2016 13:31:06 UTC+2 schrieb Julien HENRY:
How are the chances of that happening?Depends on the way you pass your ticket (see previous question). If ticket is a replacement for SQ username/password or token (ie passed as a Basic authentication credential) that could be quite easy to do (transparent for sonarlint-core / sonar-ws libraries). If we need to do modifications in the whole stack to support SSO, that's unlikely to happen.
As stated in my previous answer the first is the case. So this might just be a tiny modification to SonarLint.
[...]
Julien HENRY
Nov 14, 2016, 3:42:29 AM11/14/16
to SonarQube
Hi Jörg,
If this is a simple change in SonarLint for Eclipse (ie introducing an extension point to override default authentication by something else) I would definitely accept good quality contribution :)
But there is little chance we implement it by ourself.
++
Julien
Reply all
Reply to author
Forward
0 new messages