I have a Gerrit instance that was setup to authenticate users over LDAP. A second team came along and can only be authenticated over a second LDAP server. IT intends on keeping the two servers separate, and as far as I can tell it is not possible to authenticate against multiple LDAP servers in Gerrit.
We have a Gitlab server internally that is able to authenticate against both groups of users, possibly by magic. I have created an Application in Gitlab as an OAuth provider so that Gerrit can authenticate against it.
Everything appeared to work- everybody is able to login successfully. However, it is a bit annoying because with each login from Gerrit, the user needs to click "Authorize". What doesn't work, however, is that the Gerrit Trigger in Jenkins could no longer post the build results to Gerrit due to a 500 error.
My questions:
- What's the best way to solve this issue?
- Is there a way to support local accounts in Gerrit, when it is configured for OAuth?
- Is there a way to skip the "Authorize" page when logging in?
Please let me know if there are important details that I left out which can help with the answer.
Related
The use case is a sudo for a dual-role user who wants to switch user accounts to perform Jenkins administrative tasks when no GitHub account is authorized as a local Jenkins admin and GitHub OAuth Plugin manages authentication (overshadowing Jenkins built-in authentication form).
More info
A power user with two roles (Jenkins admin and DevOps) wants to perform some administrative task (like adding an access token to Jenkins keyring), but none of the linked GitHub accounts (that can be authenticated by Jenkins using its GitHub OAuth Plugin) is authorized as Jenkins admin (using Matrix Authorization Strategy). Is the admin account effectively locked out, because Jenkins GitHub OAuth Plugin does not let us log in with local Jenkins admin rights? If so, then shouldn't this situation be prevented by the GitHub OAuth Plugin, ensuring that at least one GitHub user has retained Jenkins admin role?
Side note: out of all alternatives such as (over)shadowing, hiding, or obscuring, the first sounded the most exciting, but feel free to fix the term if necessary.
I managed to turn off security, i.e. escalate to admin... using Jenkins own interface. But wait, there's more: I was led there by... Jenkins' security tip.
Just go to:
https://<JENKINS_URL>/configureSecurity/
(then change Security Realm to "None" and Authorization to "Anyone can do anything").
Key take-away: never run Jenkins without proper air-gapping.
We would like users to use their username/password along with another form of Multifactor Authentication, such as Google Auth (or Authy), to log into Jenkins.
We did not find any plugins that support this.
We are using AWS, so one of the things we looked at was putting an ALB in front of Jenkins and then putting, but this may interfere with getting POST requests from github to trigger builds.
Any ideas/plugins/suggestions on how to enable MFA on Jenkins?
Thanks!
I believe it is recommended to use SSO (something like SAML: https://wiki.jenkins.io/display/JENKINS/SAML+Plugin) and then as part of the SSO you can implement MFA. The problem with doing MFA directly with Jenkins is that Jenkins has pretty rudimentary user management.
I'm a newbie in the LDAP + Liferay + OpenAM world, so I wonder if someone could point me in the right direction in a problem I have. In a real life environment, there are 2 LDAP servers, a OpenAM server and a Liferay application. What the customer needs is to authenticate users in Liferay against OpenAM, and OpenAM should use the LDAP servers. Problem is, the user exists only in one of the LDAP servers (it will be moved from one to the other in one point of the future). What the customer wants is:
Users must be able to authenticate independently of what LDAP contains the user.
The obtained token must be valid for both LDAP servers, as it will be used in a different service (I have no control over it) against only one of them to validate authentication.
As I said, I'm new to this world so, if the answer is too complex (I'm afraid it will be for me), maybe you could point me to books or docs that could resolve this scenario.
Thanks
You should configure LifeRay to use OpenAM for all authentications and you can configure OpenAM to use both LDAP servers (use different realms).
Details for OpenAM configuration will be in the OpenAM documentation.
As the previous answer states you should route all your authentication requests to the OpenAM server and let it validate the credentials against the right LDAP server. Using two different realms (one for each LDAP server) won't work in your case since that will require LifeRay to know where to find the user before hand. Also, sessions are linked to a specific realm.
There are multiple solutions to your problem. Here are just a couple:
Option 1
If you have control over the authentication flow. That is, if your application uses a custom UI and communicates with OpenAM via REST, you could create two different authentication module instances under a single realm (let's say two instances of the DataStore authentication module) each one pointing to a different LDAP server.
Let's call this module instances DataStore1 and DataStore2. Your application can collect the user credentials (username and password) and submit them to DataStore1. If authentication succeeds the user is already logged in. If it fails, the application can try with DataStore2.
Of course this is not ideal since you'll be making two authentication requests per login instead of just one.
Option 2
A better option (though more complicated to implement) would be creating a custom authentication module. This module can try authenticating the user against LDAP Server 1 and then try with LDAP Server 2 if the first authentication failed. Notice that with this option you don't need custom logic on the application side since it will only send a single authentication request to the OpenAM server. In fact, you can protect your application with an OpenAM Policy Agent.
Another advantage of this approach over Option 1 is that you can migrate your users behind the scenes assuming that the end goal is to migrate users from LDAP Server 1 to LDAP Server 2. If the first authentication succeeds your custom code could read the user entry from LDAP Server 1 and copy it over to LDAP Server 2.
Hope this helps you solve the problem.
I have a setup with 4 LDAP servers, and I'd like to use the same credentials to authenticate and administrate all of them.
What I had in mind was to use one of the servers to host the credentials, and then setup a referral in the other servers to the server hosting the credentials.
I've done some tests and I didn't managed to authenticate on one of the servers using the "referred" credentials. I believe this is normal but I'd like to be sure I didn't miss anything.
Lastly, if referral do not work, is syncrepl a good candidate to achieve what I'm trying to do ?
Thanks for your help.
Michael
When an application receives an LDAP referral and follows it, it opens a new connection which needs to be authenticated. In other words, if you need to authenticate against all directories, you need to have the credentials in all directories. Replication is the way to make sure the data is identical on all directories.
I had installed Jenkins in Ubuntu machine and making build successfully. I want to have authentication with help of Google apps. I feel it would be better, I searched the plugin respective to this, but i can't find it. whether this can be attained by means of plugin or otherways? Please do let me know the ways to do. Thanks in advance
Now that Google deprecated support for OpenID, you can use Google Login Plugin which works well with Google Apps.
In Jenkins by default user authentication is not enabled but we can establish the user authentication from the Global Security section. We have to create users for team members and it maintains all user in its own database. But we can also configure Jenkins with Google OAuth. So, if you are leveraging Google services and already have users on it. The users can login to Jenkins and perform their task.
To implement Google OAuth we'll recommend jenkinsci/google-login-plugin (https://github.com/jenkinsci/google-login-plugin) this is a Jenkins plugin which lets you login to Jenkins with your Google account. Also allows you to restrict access to accounts in a given Google Apps domain.
I am assuming that we have already installed Jenkins server and have admin right to make changes in it. The whole configuration is divided into three easy steps.
1. Get Google OAuth Credentials
To use this plugin, you must obtain OAuth 2.0 credentials from the Google Developers Console (https://console.developers.google.com). These don't need to belong to a special account, or even one associated with the domain you want to restrict logins to.
Instructions to create the Client ID and Secret:
Login to the Google Developers Console
Create a new project, in the pop-up window specify your project
name it can be any name which is more meaning full to you, eg:
Jenkins OAuth. In this project we will generate authantication
credentials to enable OAuth API.
On the left sidebar under APIs & Services (API Manager) ->
Credentials, Create credentials, OAuth client ID (It will genrate API
credentials and these credentails are required to configure in
Jenkins in last step).
As we are going to integrate this in Jenkins and it is a web
service, the application type should be "Web Application"
Register Jenkins URI from where we allowed to access the Google
APIs. We have to provide Jenkins server detail. You can replace your
JENKINS_ROOT_URL = http:jenkins.mydomain.com with your own Jenkins URI. This will be the landing page of your Jenkins server.
Once you hit this page it will be redirected to google for the
authentication.
The authorized redirect URIs is required to redirect you after
successful login. It is the combination of your Jenkins landing page
and a suffix string to validate you are a logged in user. As we want
to land user to Jenkins dashboard, so it has the same URI which we
mentioned in the previous step and don’t forget to include
securityRealm/finishLogin at the end. So the authorized redirect
URLs should result like this
${JENKINS_ROOT_URL}/securityRealm/finishLogin.
eg: http://jenkins.mydoamin.com/securityRealm/finishLogin
Copy and save Client ID and Client Secret, these credential
will be used to enable Google APIs in Jenkins (Security Realm
Configuration).
2. Install Google Login Plugin
In Jenkins there is no mechanism to configure OAuth but there are many plugins are available and we are using Google Login plugin. We can easily install this plugin from Manage Jenkins –> Manage Plugins –> Available and search for “Google Login”. Select the plugin. There is no need to restart to install this plugin. This plugin allows for the register Google OAuth and performs authentication.
3. Configure Jenkins
In this step, we will setup Google security credentials in installed plugin. Navigate to Manage Jenkins –> Configure Global Security and select Login with Google under Security Realm paste credentials (Client ID and secret) generated in the first step. In the last field do not forget to enter your domain name it allows you to restrict access to given domain name.
Immediately after saving changes Jenkins will allow access to all users in your domain. Now, try to login into your Jenkins it will redirect you to Google Authentication page. If everything is set up properly you will be logged in but just in case you’re still facing any problem go back and check each step. The logged in user can do anything and if you want to restrict users you can implement Role Strategy Plugin (https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin) security.
You can achieve Single Sign On with Google Apps using the OpenID Plugin. It's very easy to set up, you basically install the plugin, select "Google Apps SSO (with OpenID)" and enter your domain. Note that users will have to have a google apps account to login after that.
Tip: you might consider using it in combination with the Role Strategy Plugin
I used a command line browser called elinks to sign in to their html mail server http://m.gmail.com.
Use shift in Elinks to copy and paste.
http://minimallinux.blogspot.com/2012/07/centos-6rhel-install-elinks-text-browser.html
I switched a text message script from one jenkins box to another and had to do this to get Google to let me use that IP.