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.
Related
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.
Problem Statement:
I am trying to build a custom management system which would require authentication and authorization both.
The system needs to have capabilities to manage/create/update/delete users, roles, permissions and groups.
My Design Solution
I am planing to implement this in-house from scratch and would provide authentication and authorization as follows.
Authentication : user would provide their credentials and the system would authenticate if the user is valid or not.
Authorization: once the user is authenticated, based on the user groups and the permissions they could access the requested pages on the site.
Question:
Now, my question is that suppose I have this application built successfully and in future my application requires LDAP (active directory) authentication would it be possible to plug in LDAP related features keeping my existing application intact or I would have to re-write the entire or most application using LDAP API's.
I have had a look at at apache shiro and spring security which
provides LDAP functionality and they also provide capabilities to manage/create/update/delete users.
As of now I have not yet decided if I would go with either of them or write my own.
Would appreciate if I could get a detailed reponse about how to go about things.
Note:
I am a complete newbie to LDAP so please excuse me if I have used some wrong terminology with regards to LDAP.
I would recommend NOT implementing this your self, just integrate with existing API.
Disclosure: I work for Stormpath (which provides exactly this) and on Apache Shiro.
Also, if your application needs to be backed by LDAP, most LDAP setups I've seen only support read operations when integrating with applications, so you may want to chat with your LDAP admin and see if your 'manage' user use case is viable.
Security is a serious domain, with lots and lots of hidden complications. I would definitely recommend against implementing this yourself. Since you mention Spring LDAP, I'm guessing you're in a Spring-based project. The obvious choice in such a setup would be the excellent Spring Security project.
I am writing some Java REST APIs which will be invoked from Web Hook configured through JIRA administration console. But, I do not see any way to add authentication header while configuring web hook in JIRA.
Without header, there is security concern in the sense that any one can invoke my Java REST APIs.
Could someone please suggest here how to add custom headers in web hook with possibly some example. I have already gone through Atlassian develper documentations but do not find any solution over there.
Adding a username and password to the Jira Cloud webhook URL e.g.
http://user:password#mycallbackurl.com
is ignored by Jira Cloud unfortunately. It seems that other Atlassian products do provide the ability to set a header / provide username and password for basic authentication.
Also see:
https://jira.atlassian.com/browse/JRA-31953
https://answers.atlassian.com/questions/12270170/where-does-the-webhook-arrive-from.
You basically have two options:
You can add an API key or some kind of secret to the webhook URL. The disadvantage is that the secret could show up in your web server logs.
Don't trust the webhook POST body (JSON) and pull the information from the API.
Adding the Atlassian server IPS to a white list would also make sense:
https://confluence.atlassian.com/cloud/database-and-ip-information-744721662.html#DatabaseandIPinformation-IPAddressrange.
Although it doesn't completely eliminate attack vectors since attacks can also come from another Jira cloud environment.
There is no support to add extra header in JIRA webhook configuration. So, authentication header can not be added in webhook configuration.
To do the authentication, one way is
1) Retrieve User information from incoming JSON
2) Make JIRA REST API call to check user's authenticity
3) Deny or allow further processing based on result
I have an OpenAM Identity management and a website that needs its credentials for loggin in. I want to federate my website with Google. My web site doesn't support any Federation protocol. How can I do this? Is there any module or plugin for each protocol to deploy in my site? should I change my source code ?
You should potentially set up federation between Google and OpenAM, and then use a policy agent or OpenIG to protect your application.
Even though both the agents and OpenIG tries to make the integration as transparent as possible, it may be necessary to modify the application (for example to ensure that the app reads the user name out of an HTTP request header/cookie/etc, and possibly some other modifications to interact with the application's authorization framework).
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).