What would I need to do in terms of setup and configuration if I want to build an API that I plan to deploy and host on a virtual machine in azure. That Web Api would make calls to our on premise TFS instance to perform continuous integration processes such as creating, getting, and kicking off builds and releases? Do I need a token, some special permission, etc..
You can use TFS REST API and use Personal Access Token (PAT) to authorize. When defining PAT you can decide scope based on the request that you are going to make.
Also you may try build and release integration for DevTest labs: https://marketplace.visualstudio.com/items?itemName=ms-azuredevtestlabs.tasks
Related
Consider a developer portal where a developer can create an OAuth2 application Acme Pay. The dev gets a client_id, client_secret, access_token, and a refresh_token, along with a redirect_uri field that can be configured.
The state of the app will be in a test/sandbox environment and the dev can play around within the constraints of the sandbox environment.
As a next step, once the developer has implemented the app locally and wants to push it to prod, I am ideating a flow where the dev would be able to simply toggle the app's environment to a live environment in the developer portal where they get a new token pair for the same app, along with environment-specific access privileges and rate-limits.
I'm a PM trying to understand if such an implementation is possible with OAuth2.
My motivation here is to prevent the developer from creating two OAuth apps for testing and production. I noticed a similar flow in Stripe. Although in my case, the developer will be able to create multiple OAuth apps under one account, hence I feel it is better for each app to have two environments co-existing parallelly at the app level to provide a better developer experience.
The OAuth client configuration is created separately for each stage of your deployment pipeline. Sometimes in portals the wording is Create Application but these are just security related configuration settings.
Separate config per stage of the pipeline enables settings to be versioned reliably over time and tested first. Also the change ownership is often controlled by different people and done at different times. Typically though the deployment is automated in a parameterized and reliable manner.
The actual application code should only ever be built into binaries once though. It is then pushed down a pipeline where binaries are combined with the stage specific configuration.
I am looking to build a custom front end application to facilitate release management. I want to integrate with Azure Dev Ops using the client libraries.
Is there a non-interactive way of authenticating other than a PAT that will expire? I don't want to use delegated access because I will control the permissions from the app.
Is there a non-interactive way of authenticating other than a PAT that will expire?
AFAIK, I am afraid there is no such a non-interactive way of authenticating except PAT.
There is a similar issue on github:
All the authentication method for accessing Azure Devops service is
interactive except one(which still needs interaction through user
specific device like mobile).
There is no good way to do auth towards the devops api for a
non-interactive service. They all require user interaction or a fake
And you could vote and comment the user voice Support for non-interactive service access via service principals..
As workaround, you could use a PAT, and extend its period to one year.
Hope this helps.
user service account or similar.
We have TFS 2013 setup on our own server in house. We have about 8 windows users from AD that currently use it.
I need to interact with TFS via API from a console app that will run on a different server. I have it all working fine when running as my own Windows account. How can I set up a user in TFS that will be used only for API interaction? I searched around and it seems I can't add a non-Windows user to TFS for this. Is it possible to use a service account or something? What is the best practice for this?
Thanks.
No, there is not any API related service account. You could take a look at this thread: Service Accounts for Team Foundation Server
Which include a table shows all the service accounts that you might use in a deployment of TFS such as TFSService, TFSBuild...
As a workaround, you could create a public domain account in TFS used for API related. However it's not able to restrict the account only used for API interaction. Since for which permissions are needed for an end user/domain user to call into the TFS API, this is based on the action that you request through TFS API. For example if your TFS API is used for checking in files, API account need code related permission, used for triggering a build, then the API account need build related permission. More information of permission, please refer to: Permission reference for Team Foundation Server
I'm evaluating WSO2 Identity Server and WSO2 API Manager.
I registered an API and an application on API Manager. I can call the resources successfully.
I could also add an user into Identity Server and log into that using oAuth authentication.
But, it's not too clear how I can use those two systems together. I would like to use API Manager to expose my API's to some applications. And, I would like to use Identity Server to log the final user. Is that possible? How can I "plug" those two systems?
I am not sure if that's the best way to do that, so, please, advice me.
Thanks
According to my understanding of your use case is you need to expose the API's securely. So you need to used WSO2 Identity Server and WSO2 API Manger. In addition to that you need the best approach for above use case.
With above two product we have below two option.
Configuring WSO2 Identity Server as the Key Manager in WSO2 API
Manager (This link gives a different version combination of both products)
Here we need to add key manger feature to the WSO2 IS.
Configuring the Pre-Packaged Identity Server 5.0.0 with API Manager
1.9.0
In here 1st option have manual configurations. But,2nd option minimized the manual configuration.
The purpose of using the Identity Server is not too clear. Is it to separate the authentication/authorization from the API Manager instance?
By default API Manager is shipped with a Key Management Server component that is responsible for all security and key related operations.This can be configured to authenticate users against a defined user store or multiple user stores. Authorization is based on oAuth 2.0. However, in a production deployment, we recommend that this component is deployed as a separate server instance so that it runs as an external Key Management Server.
This is done by simply using another copy of the API Manager distribution and configuring it as a Key Manager server node.
Hope this helps.
Regards,
Gillian
My understanding is,
if you wanted to use WSO2 API manager (AM) as an API gateway, you don't need a separate IS as AM included an IS engine with security mechanism included such as key manager.
If you need single sign on across all AM components, and you do NOT have other identity provider (IdP), you need a aeparate IS
However, if you do have a separate IdP, you don't need to install an IS server to implement SSO for AM, although the documentation from IS may suggest you do so. For example, a successful SSO implementation has been done with PingFederate/PingIdentity. See How to integrate WSO2 API Manager (AM) 1.10.0 with PingFederate SAML 2.0?
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).