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).
Related
I have a use case where I need to provide a small CLI application that can be installed on headless servers of customers and transact data over REST APIs. I'm trying to search for a solution which allows the user who is generating tokens for the headless servers and the servers individually as well. I've looked at Auth0 which provides a simple way of doing this. However, the only catch is that the customer will have to generate device tokens corresponding to every server that they have. This will fail if the servers have to autoscale.
Are there more ways to achieve this while not compromising on security with the following identifications possible?
The user generating the token should be identifiable.
The device individually should be identifiable as well.
At any point, if I want I should be able to revoke authorisation from a particular device/server.
At any point, I should be able to revoke authorisation for all devices/servers registered by a particular user.
I asked it here a while back but got no response: https://security.stackexchange.com/questions/262580/authenticating-headless-autoscaling-clients
I have the following question:
We implement some different LMS and we are wondering if and how could be possible to have a SCORM (hosted into an LMS) asking the user to authenitcate to an external authentication system (other than the one of the LMS itself where the SCORM learning object is available) as first action when launched the SCORM; if this authentication fail, the user must be not enable to take that learing; in other words we are wondering to understand if it is possible to implement a sort of two factors authentication method where factor-1 is the login to the LMS, factor-2 is the “login” requested by the specific scorm; this factor-2 managed by the external authentication system could be, for istance, an OTP code or an electronical identity card, or any other similar strong authentication factors with the scope to enable or not that user to take that SCORM content.
Thanks a lot
Daniele
There's no mechanism in SCORM for authentication. A SCO (a learning object or activity) generally assumes it is authenticated by default.
There are two solutions depending on what part you have control over:
The LMS could handle the external authentication flow and only deliver the SCO when that authentication succeeds.
The SCO could handle the external authentication (and persist this state e.g. in a cookie or local storage) and delay initialization with the RTE until the authentication has succeeded.
Note that SCOs are executed entirely in the browser so any authentication logic will have to run in the browser and be able to communicate with the external authentication system and a sufficiently technical user would be able to access the source code.
I'd like to add the ability to create JIRA issues from within a Unity game (C#), such as for submitting player feedback and bugs. I see various authentication approaches, from "basic" auth (just a raw UN and PW) to an Auth Token approach, to possibly some OAuth-based approach which I don't yet understand.
I've set up JIRA integration in web projects over the years, and it was fairly simple. I never had concerns over authentication, since the credentials to access JIRA were always stored within the web server's configuration. But with a deployed application (such as a game created in Unity), I don't understand if there's any secure/correct way to provide credentials to the application. It seems that it would be trivial for anyone to either inspect the code, or the memory of the running application, and extra the authorization credentials.
Is there a secure way for a desktop application (not connected to a central server) to authenticate against an API like JIRA's?
I have some difficulties with automating log in process in the web application. It's an angular app, I'm writing tests in protractor. The app uses Azure AD, so I need to pass e-mail, password and the verification code from mobile app. I know there're some very useful libraries to generate the code. The problem is I don't have the access to Azure admin panel so I'm not able to get the secret key that is necessary to use those libraries. Is it possible to somehow skip or mock the MFA? I'd be grateful for any advices how to solve this.
Assuming you want to run these tests on the CI, you could hard code a test user credential in your web application that returns true when used in a specific environment. Lets say you want user xyz#abc.com to login and then perform other tasks, add code in your web application so that when xyz#abc.com sends a request with dummy secret key, log the user in. Then you'd have to mock all the rest of the APIs that your application uses.
You can also remove the auth when you are testing it in a test CI environment. This would be a good solution but tricky. You would have to remove auth entirely for all APIs and that would require design pattern change etc.
But get the access and do it the right way.
I would actually recommend NOT skipping MFA on E2E tests in your CI.
By setting up a bypass in your code related to your environments you are taking the risk of having this "test account" in the production environment and being it found by someone. And believe me, it will happen sooner or later ;).
Today multiple third-party tools exist allowing you to parse SMS-based MFA or TOTP codes (like the Azure app). For example, the GetMyMFA platform provides you with an API allowing you to receive and inject in your CI your MFA codes.
If you have the time and resources, I would recommend looking for a tool that allows you to get MFA codes from an API and have your automated E2E tests inject that code in your CI.
Cheers
I'm using keycloak to let my users authenticate with my application. And i am trying to migrate some functionality to a few plugins, e.g. a wordpress plugin. For these plugins i want to use a generic solution so I found the following authentication process from Microsoft (https://learn.microsoft.com/en-us/office/dev/add-ins/develop/auth-external-add-ins#middleman-services) and Adobe ( https://adobexdplatform.com/plugin-docs/tutorials/how-to-integrate-with-OAuth/).
I managed to hack my way around the process to get this working with keycloak. But at this moment I'm a bit concerned about the security risk that go with this process.
The process in steps
the (plugin) client asks to backend server to generate a code to identify the user.
the (plugin) client start polling the backend for an authentication code (no response yet, since the user is not logged in yet).
the plugin opens a browser window or tab with the keycloak loginpage. Everything is the same as the normal process, but this time we add an redirect uri with the code generated in step one, which identifies the user.
once the user is logged in the user gets redirected in the browser to an endpoint where the code from step one is linked to the access token retrieved in this step.
the polling from step 2 now returns the access token to the (plugin) client.
The reason I need to poll for the access token is because I want to make a generic login process for all client.
In short, I want to know what the security risks are, given the steps above. Also I can not seem to find any information of keycloak that they want to implement such feature. Does anyone know if they want to implement this, since many other plugins do offer tis feature to authenticate outside the plugin with a popup window and retrieving the accesstoken by "polling" the server.
Thanks for the help.