[JENKINS-15063] support for multiple security realms with failover

[timja]

It should be possible to configure multiple security realms at once with a specified order or preference.

Examples of usage:
failover between multiple ldap instances
failover from ldap to basic auth

---

Originally reported by liamjbennett, imported from: support for multiple security realms with failover

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

sam_he:

I have similar requirement, e.g.:
There are 2 user groups using 1 jenkins instance. one of the our group use the MS AD to perform authen, while the other group will use LDAP server.

[timja]

blurblah:

I'm using active directory plugin for security realm.
But I couldn't login and do anything about jenkins management when some problems occurred on our AD server.

So multiple security realms should be supported I think.

[timja]

alex_ouzounis:

I would also be interested in this. Any activity ?

[timja]

davidstrauss:

I've put $500 toward adding this on FreedomSponsors.org:
https://freedomsponsors.org/issue/546/support-for-multiple-security-realms-with-failover?show_sponsor=true&c=s

[timja]

integer:

I'm not specialist on Atlassian products, but probably Crowd may do this, have you looked on it?

[timja]

staylorx:

I would like to see this also. It would be especially useful for testing role security and permissions with custom groups, test users, and machine accounts. I've recently placed a Jenkins farm with LDAP and it's authoritative for users, but the firm's use of groups is really quite simplistic.

What might be nice is a number next to each choice signifying the order it checks and then a flag determining the "base case" default, e.g.:

Order | Provider | Condition
0 | Active Directory | x
0 | Delegate to servlet container | x
2 | Jenkins’ own user database | NECESSARY
1 | LDAP | SUFFICIENT

So the first provider it would check would be LDAP and that's sufficient to provide identity. If that fails it falls to the next which is the Jenkins' database and since that's necessary it must end there. The "x" on ADDS and container just means it doesn't matter what is selected there.

I'm only using numbers because I think it would be easier to implement than drag and drop in order. And the numbers would be unique (save zero) so there are no ties between providers.

Thanks!

[timja]

jglick:

Not possible without new core APIs and rework of existing security realm plugins to use them.

[timja]

jhoblitt:

Would it be feasible to have a special security realm plugin that functions somewhat like pam, in the sense that it could be configured to call a number of other security modules? I realize this would require modified versions of the existing security realm plugins but perhaps it would be a way forward without an (incompatible|any) core change.

[timja]

jglick:

Would it be feasible to have a special security realm plugin that functions somewhat like pam, in the sense that it could be configured to call a number of other security modules?

As noted above, not without a new API, which would best live in core, and calls to it from existing security realm plugins.

[timja]

elconas:

This is a serious problem, when using some automation tool for Setup of Jenkins (e.g. Puppet module). As long as multiple auth sources are not supported, secure jenkins can never be automated with Puppet / Chef / Ansible code.

[timja]

nitaco:

It's really a serious problem. As elconas said.

[timja]

dingo:

Indeed, this is serious problem for us as well. New API for this would be welcomed.

[timja]

fransurbo:

Doing LDAP right, this is not a problem - run your LDAP slaves (more than two!) behind a load balancer (more than two!).

[timja]

praqmatim:

You know, from what I can see this use case has been open for around ten years. See: https://issues.jenkins-ci.org/browse/JENKINS-3404.

It seems to have been partially implemented by the Active directory plugin by providing a fallback user if connection is broken.  Nothing has happened on ldap plugin about this issue.

I love open source and am a big Jenkins fan. But this is the type of thing that is hard to defend when talking to business/operations about the benefits of open source. 

It is not like this is some type of crazy wish. All Atlassian applications, like this Jira I am making this comment on, has support for multiple user directories. A built in internal user directory and support for adding others.

 

[timja]

danielbeck:

I love open source and am a big Jenkins fan. But this is the type of thing that is hard to defend when talking to business/operations about the benefits of open source.

I think this is a nice example of the benefits of open source (at least in open communities like Jenkins'): You don't need to fight through multiple tiers of support (usually after buying a license) until your request reaches a product manager who may or may not consider it important enough to actually do, and even if you're lucky, you still need to wait for work to be prioritized. You can just do it yourself, or, if lacking the necessary skills, pay someone to do this specific thing.

I'd be happy to review (and eventually merge) a well thought out implementation of this. I'm sure I can also get a few other maintainers to assist with reviews and provide feedback. If this needs extensive rework in core, I recommend starting with a JEP to make sure the design is sound.

[timja]

jglick:

This would need nontrivial changes in core in case existing SecurityRealm implementations sometimes assume they can checkcast the result of Jenkins.securityRealm, which I recall being the case. If not, in principle this could be done as a plugin defining a proxy implementation.

[timja]

sharon_kwok:

It is seriously needed for automation. Hope that Jenkins could support.

[timja]

nemligtim:

danielbeck No reason to get your hackles up. Can I write code in Java? Yes. Do I know enough about the architecture of Jenkins to do this properly. No. Not without a lot of investment in time, which I do not have. Will my employer fund a plugin for this? No. 

Where does that leave me, an advocate of Jenkins? On here hoping to highlight the need for this functionality. 

[timja]

jglick:

That is all to be expected. I would just ask that people use the Vote feature in JIRA rather than adding comments, unless the comment consists of genuinely novel suggestions. Otherwise popular issues wind up with dozens of “me too” comments.

[timja]

jglick:

which I recall being the case

Examples like this or this are not hard to find. So making the realm proxyable would at a minimum require some logic changes to various popular realm plugins, and perhaps require new core APIs to permit adequate context / state to be “threaded” through various interfaces rather than grabbing it from a global singleton.

[timja]

JIRAUSER139016:

Up-voted. My team has the need to authorize internal users with SAML, and authenticate external users, automation and other services with the internal Jenkins database or LDAP.  I also need to be able to modify the authentication/authorization configuration without the risk of losing access to the instance.  I cannot enable anonymous access because the instance is publicly accessible.

[timja]

peachy_devops:

I upvoted this one. Hopefully, this can be prioritized soon.

[timja]

dshiryaev_plesk:

We use OIDC with Jenkins and we need restricted automation accounts too.

 

[timja]

[Originally duplicated by: JENKINS-38257]