Propose a workaround of missing multiple security realm feature

293 views
Skip to first unread message

tycr...@gmail.com

unread,
Nov 18, 2017, 10:18:01 AM11/18/17
to Jenkins Developers
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.

Oleg Nenashev

unread,
Nov 20, 2017, 2:21:50 AM11/20/17
to Jenkins Developers
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 пользователь tycr...@gmail.com написал:

Stephen Connolly

unread,
Nov 20, 2017, 4:24:17 AM11/20/17
to jenkin...@googlegroups.com
On 18 November 2017 at 14:57, <tycr...@gmail.com> 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 jenkinsci-dev+unsubscribe@googlegroups.com.
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.

Daniel Beck

unread,
Nov 20, 2017, 9:10:05 AM11/20/17
to jenkin...@googlegroups.com

> On 20. Nov 2017, at 10:24, Stephen Connolly <stephen.al...@gmail.com> 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.

Stephen Connolly

unread,
Nov 20, 2017, 9:19:50 AM11/20/17
to jenkin...@googlegroups.com
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 jenkinsci-de...@googlegroups.com.
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

Jesse Glick

unread,
Nov 20, 2017, 10:25:14 AM11/20/17
to Jenkins Dev
On Sat, Nov 18, 2017 at 9:57 AM, <tycr...@gmail.com> 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.

Robert Sandell

unread,
Nov 21, 2017, 5:50:33 AM11/21/17
to jenkin...@googlegroups.com
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 jenkinsci-dev+unsubscribe@googlegroups.com.
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.
Reply all
Reply to author
Forward
0 new messages