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.
Related
I have deployed the Spinnaker services and set its authentication by using google oauth2.0 services.
Now I wanna access the gate api by writing custom nodejs javascripts.
So the question is I donnot know how to let my request/http scripts access the gate apis without interactive google auth actions, like using something like setting a token in the request's header?.
I have read the docs about IAP part, but I really do not quite understand what I need to setup in Spinnaker and how can I write my request scripts.
Any help would be very appreciated.
Thanks in advance.
since you have already integrated OAuth in Spinnaker, verify if your Gate services open. Spinnaker Gate would open on port 8084 by default. The Spinnaker Gate url would be something like this https://:8084/swagger-ui.html#/ or use "http>://" if you are on http.
It would ask you to login. Try opening it and if it opens your Gate is working fine. you can try out any Spinnaker API too from this swagger page. It should work without any re-login as you are already logged in.
now, to run APIs from code (or any script) you need to have an access token passed in the header. follow any standard oauth 2 document to see the procedure. you can take cues from here. https://www.jhanley.com/google-oauth-2-0-testing-with-curl/
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.
I am considering integrating IBM's Tivoli Access Manager with Jenkins for user authentication. TAM uses something called a WebSeal to allow users to login and then forwards the creds for that user in the HTTP header to the desired service. I am new to Jenkins and was wondering what would be the easiest approach to do this. I noticed that the existing OpenId plugin extends the FederatedLoginService currently present in Jenkins. Could something similar be done to integrate TAM? If not, where would I extend Jenkins to allow the extraction of the creds form the header provided by WebSeal?
Thanks in advance.
To make #daniel-beck’s suggestion into a concrete answer: the Reverse Proxy Auth plugin is the way this sort of integration is normally done in the absence of a dedicated SSO plugin, though I do not know specifically whether WebSEAL sends headers suitable for consumption by this plugin. From what I can glean by searching, you would get HTTP_IV_USER and HTTP_IV_GROUPS.
Goal:
I want do write an application that can trigger Jenkins jobs and itself also authenticates users against the Crowd server. The users must be in a separate crowd group to be authorized to act on Jenkins.
Setup:
I am using the Crowd2 plugin to authenticate Jenkins users against an Atlassian Crowd 2.1 server.
My thoughts:
Now, Jenkins has two types of remote execution:
Jenkins REST API (uses a per-user Token for authentication)
A build can be triggered through this call using a "TOKEN" in a way like this:
JENKINS_URL/job/JOBNAME/build?token=TOKEN
Jenkins CLI (uses an SSH key for authentication)
A build can be triggered through an command line tool using the SSH private key to authenticate the user.
The token-approach (REST API)...
... requires my application to know the API token.
How could I bypass the API token limitation?
Storing the API token within Crowd?
The Crowd2 Jenkins plugin could store the Jenkins API token as an crowd attribute (user-defined properties which can be stored within the crowd user directory), is one way. Even though I think this could be a security flaw, as the attribute might be retrieved from all other applications registered at Crowd (which would enable them to execute Jenkins jobs on the users behalf).
Q: Good approach and secure enough? In my opinion, this is not secure enough.
Authenticating with my applications crowd token against Jenkins?
I've also tried generating a crowd-token through Crowd's API and then requesting the Jenkins REST API with that token as Cookie in the hope that the Jenkins crowd2 plugin validates the passed Crowd token against Crowd. But it does not work (when using the crowd token from my browser, by examining the page information in Firefox, it works, of course).
I am not sure if this approach (if the crowd2 plugin would check the passed token) has security flaws in it and if the crowd-token mechanism is designed to work in that way. I am sure though, that it might negatively affect Jenkins' performance as every API request has to check if the token is valid.
Q: Good approach and possible?
The CLI-approach...
...requires my application to know a SSH private key registered at Jenkins.
It would be good approach, if Jenkins would support adding SSH Keys. My application could generate a SSH key pair (with random) password and automatically store the public key on the users behalf within Jenkins.
I think this is the right way, even though it requires to extend Jenkins and maybe the authentication plugins.
Q: Is this approach possible and secure enough?
Q: Are there other approaches?
I think Jenkins should implement an OAuth endpoint for authorization (in case of the crowd plugin, it then has to delegate the authorization to Crowd) or completely detach user management from its core. Am I wrong?
Please help me improving this question, if neccessary. I can imagine that I've mixed two problems and didn't described by goal clear enough.
Note: Edited this question ~1 hr after creation (see my 1st comment).
I need to run my Selenium Webdriver JUnit tests separately, but also all at once. I've been looking for a solution for something that basically cuts down to one single issue: I'm testing an application which uses SSO.
That means, I have to manually sign in when I run a test. This is on the other hand even desired, because you don't want to store critical passwords in any files. This is not even harmfull when you run a single test. But when you're in need to run them all, and you have about 100 tests, you would have to sign in 100 times. No way Jose!
I have found out that one possible solution could be Java proxy server. I find codes that show how to create and handle one, but not the SSO part in it. Can anyone help me? Or will the password be stored somewhere either ways?
You need to find out more about your SSO implementation. I suggest using your browser's developer tools our a debugging proxy such as Fiddler or Charles to capture the HTTP traffic between your browser and the servers during SSO authentication, then implementing these requests in a Java web client. SSO authentication often results in setting a cookie. If you capture this cookie after the authentication phase, then you can reuse this cookie in every Selenium test.
The authentication will require credentials, which you could put into a properties file. You could exclude this properties file from source control, and ask all developers to use their own credentials when running tests.