I have recently installed Jenkins SAML plug-in to log into Jenkins using
ADFS. We can successfully login with our ADFS users and have our
permissions managed using Project Matrix. However, we do use a local
service admin to perform administrative tasks such updates hitting the
cli endpoint as: http://localhost:8080/cli
<title>Error 401 Invalid password/token for user: admin</title>
<body><h2>HTTP ERROR 401 Invalid password/token for user: admin</h2>
I clearly understand that this is the result of SAML plugin overriding
the auth in favour of SAML discarding the use of local service users.
From my research over the net, I'm not the first experiencing this
issue. I'm aware of
https://github.com/wenjunxiao/mixing-security-realm-plugin but this is
not an official and vetted Jenkins plugin and therefore is out of the table.
Since the version 2.5 of the AD plugin, you can define a user to fall
back in case there is a communication issue between Jenkins and the AD
server. On this way, this admin user can be used to continue
administering Jenkins in case of communication issues, where usually you
were following the link Disable security. The password of this user is
automatically synced with the Jenkins Internal Database by this feature.
In order to configure this new feature you should enable Use Jenkins
Internal Database in the AD configuration under Manage Jenkins →
Configure Global Security and specify a SINGLE user by its username.
Are any future plans to have the same capability with SAML/ADFS plugin
or anything else down the line planned in Jenkins Core to overcome this
Are any future plans to have the same capability with SAML/ADFS plugin or anything else down the line planned in Jenkins Core to overcome this scenario?
No, I do not have plans to add any kind of fallback user to the SAML plugin, this, in my opinion, is to add a non-related SAML logics to manage API users. You can workaround it with a real user in the SAML IdP and an API Token, In case that these fallback users make any sense, T¡this feature should be implemented in a plugin for those kind os users, in that way is something you can combine with any Authentication plugin, and we do not have to reinvent the wheel on each authentication plugin. Unfortunately, Jenkins does not support more than one Security Realm active at the same time. Another option can be to extend the API token feature to support local users but this is part of the core IIRC.