Propose a workaround of missing multiple security realm feature

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

Propose a workaround of missing multiple security realm feature

tycrelic
Jenkins currently does not support multiple security realm.
However, it should be a reasonable use case that allow both AD / LDAP logins for individuals (e.g. developers) and logins local Jenkins' own user database for administrative roles (e.g. user maintenance team) and emergency situations (e.g. AD server out of work) in a sizable organization.

I have searched the issue list and found the following related / similar issues, and no :
JENKINS-3404 mix LDAP and local Hudson users
JENKINS-15063 support for multiple security realms with failover
JENKINS-29162 Jenkins internal user in order to be able to log-in under an authentication failure with LDAP AD, ...

Since I have not seen any existing solution such as Jenkins API enhancement or new plugin to support multiple security realms, I want to kick start the discussion by proposing my workaround idea.

The idea is simple: create a new security realm (composite) which delegates methods calls to some chosen security realms (components).
Here is the prototype: Composite security realm plugin

For the prototype, the following assumptions are made:
1. It only supports password-based component security realms.
2. The user name collision among different security realms is avoided by using the order in the configuration as the precedence.
3. To avoid account locking because of same user name with different passwords in different component security realms, the method SecurityRealm.loadUserByUsername(String username) should work properly instead of throwing exception.

Please share your points of view regarding to the workaround, whether it is feasible or has fatal issues.
If you have implemented a more mature private plugin for support of multiple security realm and are willing to make it open source, you may also post the link of the source code here for discussion.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7c1b5996-d1af-439a-890d-341514a1ebab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Propose a workaround of missing multiple security realm feature

Oleg Nenashev
Hi,

The approach looks good to me while it is kept in a plugin. It may cause some security implications (e.g. credentials will be sent to multiple servers), but I see no problem with it while it is documented explicitly.

I didn't dig into the code much, it can be reviewed later by code reviewers.
Once the implementation is ready, IMHO it could be hosted within the Jenkins org: https://wiki.jenkins.io/display/JENKINS/Hosting+Plugins

Best regards,
Oleg Nenashev


суббота, 18 ноября 2017 г., 16:18:01 UTC+1 пользователь [hidden email] написал:
Jenkins currently does not support multiple security realm.
However, it should be a reasonable use case that allow both AD / LDAP logins for individuals (e.g. developers) and logins local Jenkins' own user database for administrative roles (e.g. user maintenance team) and emergency situations (e.g. AD server out of work) in a sizable organization.

I have searched the issue list and found the following related / similar issues, and no :
<a href="https://issues.jenkins-ci.org/browse/JENKINS-3404" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-3404\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHKnPDh89RVi5AiQB5Rm1vTh8l6xg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-3404\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHKnPDh89RVi5AiQB5Rm1vTh8l6xg&#39;;return true;">JENKINS-3404 mix LDAP and local Hudson users
<a href="https://issues.jenkins-ci.org/browse/JENKINS-15063" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-15063\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWABT6WVLW9idwwhu3W1MeXSQFYg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-15063\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWABT6WVLW9idwwhu3W1MeXSQFYg&#39;;return true;">JENKINS-15063 support for multiple security realms with failover
<a href="https://issues.jenkins-ci.org/browse/JENKINS-29162" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-29162\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5J3Wi9CrheGueYB0S4UgtLK8X-g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-29162\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5J3Wi9CrheGueYB0S4UgtLK8X-g&#39;;return true;">JENKINS-29162 Jenkins internal user in order to be able to log-in under an authentication failure with LDAP AD, ...

Since I have not seen any existing solution such as Jenkins API enhancement or new plugin to support multiple security realms, I want to kick start the discussion by proposing my workaround idea.

The idea is simple: create a new security realm (composite) which delegates methods calls to some chosen security realms (components).
Here is the prototype: <a href="https://github.com/tycrelic/composite-security-realm-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftycrelic%2Fcomposite-security-realm-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEb9gN3r2Zel6FiDdpUhToOw_adKg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Ftycrelic%2Fcomposite-security-realm-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEb9gN3r2Zel6FiDdpUhToOw_adKg&#39;;return true;">Composite security realm plugin

For the prototype, the following assumptions are made:
1. It only supports password-based component security realms.
2. The user name collision among different security realms is avoided by using the order in the configuration as the precedence.
3. To avoid account locking because of same user name with different passwords in different component security realms, the method SecurityRealm.loadUserByUsername(String username) should work properly instead of throwing exception.

Please share your points of view regarding to the workaround, whether it is feasible or has fatal issues.
If you have implemented a more mature private plugin for support of multiple security realm and are willing to make it open source, you may also post the link of the source code here for discussion.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/84914c7a-6168-4cf7-90a2-7cc06ee798d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Propose a workaround of missing multiple security realm feature

stephenconnolly
In reply to this post by tycrelic


On 18 November 2017 at 14:57, <[hidden email]> wrote:
Jenkins currently does not support multiple security realm.
However, it should be a reasonable use case that allow both AD / LDAP logins for individuals (e.g. developers) and logins local Jenkins' own user database for administrative roles (e.g. user maintenance team) and emergency situations (e.g. AD server out of work) in a sizable organization.

I have searched the issue list and found the following related / similar issues, and no :
JENKINS-3404 mix LDAP and local Hudson users
JENKINS-15063 support for multiple security realms with failover
JENKINS-29162 Jenkins internal user in order to be able to log-in under an authentication failure with LDAP AD, ...

Since I have not seen any existing solution such as Jenkins API enhancement or new plugin to support multiple security realms, I want to kick start the discussion by proposing my workaround idea.

The idea is simple: create a new security realm (composite) which delegates methods calls to some chosen security realms (components).
Here is the prototype: Composite security realm plugin

For the prototype, the following assumptions are made:
1. It only supports password-based component security realms.
2. The user name collision among different security realms is avoided by using the order in the configuration as the precedence.

In evaluating the chain, if one delegate realm is off-line, no subsequent delegate realms can be considered on-line.

In group membership is going to be tricky (not impossible) as you will need to know which delegate realm the group came from and only match against users from that same realm.

In general the group support is going to be where you have the worst time
 
3. To avoid account locking because of same user name with different passwords in different component security realms, the method SecurityRealm.loadUserByUsername(String username) should work properly instead of throwing exception.

Please share your points of view regarding to the workaround, whether it is feasible or has fatal issues.
If you have implemented a more mature private plugin for support of multiple security realm and are willing to make it open source, you may also post the link of the source code here for discussion.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7c1b5996-d1af-439a-890d-341514a1ebab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxsjw%2BegdcFpa859-_Z0h7DpxOwqWe2zeuAm6MNGT4p3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Propose a workaround of missing multiple security realm feature

Daniel Beck

> On 20. Nov 2017, at 10:24, Stephen Connolly <[hidden email]> wrote:
>
> In group membership is going to be tricky (not impossible) as you will need to know which delegate realm the group came from and only match against users from that same realm.
>
> In general the group support is going to be where you have the worst time
>

Can probably store the source realm for a user as a UserProperty, and tie it to that? Unless the admin enables 'fallback mode' that just checks every realm for a user -- but may result in problems from overlapping user names if not deliberately selected.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F2C7D297-D671-4423-ADCF-BD01096824E8%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Propose a workaround of missing multiple security realm feature

stephenconnolly

On Mon 20 Nov 2017 at 14:10, Daniel Beck <[hidden email]> wrote:

> On 20. Nov 2017, at 10:24, Stephen Connolly <[hidden email]> wrote:
>
> In group membership is going to be tricky (not impossible) as you will need to know which delegate realm the group came from and only match against users from that same realm.
>
> In general the group support is going to be where you have the worst time
>

Can probably store the source realm for a user as a UserProperty, and tie it to that? Unless the admin enables 'fallback mode' that just checks every realm for a user -- but may result in problems from overlapping user names if not deliberately selected.

Nah... worse than that... most of the critical API calls drop down to String. :-(


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F2C7D297-D671-4423-ADCF-BD01096824E8%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxS4Q_e4%3DnSwiSyUDTLJwgKtDcDugPH0p8q6X%3D%2B7CzP6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Propose a workaround of missing multiple security realm feature

Jesse Glick-4
In reply to this post by tycrelic
On Sat, Nov 18, 2017 at 9:57 AM,  <[hidden email]> wrote:
> The idea is simple: create a new security realm (composite) which delegates
> methods calls to some chosen security realms (components).

The idea is indeed simple. Last I looked into it, the obstacle was
code in concrete security realm plugins which called
`Jenkins.getInstance().getSecurityRealm()` and checked if the result
was an instance of the type defined in the same plugin, and behaved
differently according to that check. Maybe that is no longer the case
and there is no problem, but it needs to be verified.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0C4rpQ3PSY66zvY%2BZqnsdqrz53VqygCL_6XA1%2BicZM-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Propose a workaround of missing multiple security realm feature

Robert Sandell-2


2017-11-20 16:25 GMT+01:00 Jesse Glick <[hidden email]>:
On Sat, Nov 18, 2017 at 9:57 AM,  <[hidden email]> wrote:
> The idea is simple: create a new security realm (composite) which delegates
> methods calls to some chosen security realms (components).

The idea is indeed simple. Last I looked into it, the obstacle was
code in concrete security realm plugins which called
`Jenkins.getInstance().getSecurityRealm()` and checked if the result
was an instance of the type defined in the same plugin, and behaved
differently according to that check. Maybe that is no longer the case
and there is no problem, but it needs to be verified.

The LDAP plugin does that :/ 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0C4rpQ3PSY66zvY%2BZqnsdqrz53VqygCL_6XA1%2BicZM-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Robert Sandell
Software Engineer
CloudBees Inc.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2c9nSw46tqo3%3DVkGwapymL8ztGLkYsFkgJk6F%2BMVuKyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.