I've set up some on-prem Docker-based DevOps agents using a Docker Swarm. However, these agents rely on a PAT to authenticate and connect with our on-prem DevOps 2019 - not a HUGE issue, but PATs have a max lifetime of a year, and I'd rather have this system working longer if possible (on-prem solutions tend to have a lifetime of their own after all).
I know DevOps has an API - alas attempting to find information on how to use it directs me to the DevOps Services (online) versions, which aren't going to work for me (they use things like AAD applications for authentication and that's clearly not going to work on-prem). Annoyingly trying to change the documentation to show what's valid for DevOps 2019 redirects back to documentation for DevOps Services.
Any idea how to generate a PAT using the API on an on-prem DevOps instance, preferably by authenticating via username + password? Or at least where can I find some documentation on this?
If you are trying to use PAT REST API, then you can find it in Azure documents which i am sharing here:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/manage-personal-access-tokens-via-api?view=azure-devops
Hope this will help you out.
Related
There is a graph Web API for accessing Permission Groups in Devops Online. The Azure CLI also provides an interface for this same functionality. The Graph API and Azure CLI are not available for Azure Devops 2020 Server. I am having trouble finding the corresponding interface for Azure Devops Server. Does anyone know if there is an interface and if so can you point in the right direction?
Thanks!
I'm trying to build an app that uses Jira Software Server data. On Jira Sass Oauth is simple enough, but after creating an SSL cert and configuring a localhost jira instance for development, I can't get any proper responses from my own server, for the older Oauth 1.0a flow, and all the documentation seems to reference https://jira.yourdomain.com. Is there some DNS that all self-hosted servers are routed through from Atlassian? I realize this self-hosted product is being slowly depreciated, but this new feature I want to provide for a client will require this connection since they are using this version of the software. Any insight would be useful since Atlassian Docs are so very outdated/not maintained.
No, Jira Software on premise does not route traffic through Atlassian cloud.
There are lots of offline Jira instances.
Here is some documentation about oauth with Jira Server/Datacenter:
https://confluence.atlassian.com/kb/oauth-troubleshooting-guide-719095274.html
I'm configuring a private/onprem Windows build agent (vNext) for VSTS. I need to use a PAT, but this doesn't seem great long term as the longest I can set it for is 1 year - thus in a years time it will break and require updating. Is there a more 'permanent' solution or is this the only option? The documentation suggests PAT only for VSTS.
Thanks in advance!
A colleague found the answer in the FAQ:
https://www.visualstudio.com/en-gb/docs/build/admin/agents/v2-windows
How does the agent authenticate and communicate with the TFS AT?
The agent pool administrator role is needed only when you register an agent. At that time, the agent downloads an OAUth token so that it can listen to the queue. The account that you use in this role has no bearing on future communication between the agent and the TFS AT.
When a build is run, it generates an OAuth token for the scoped identity selected on the general tab of the build definition. That token is short lived and is used to access resources on the application tier.
Most importantly "The account that you use in this role has no bearing on future communication between the agent and the TFS AT."
Based on this article (Deploy an agent on Windows), you need to choose PAT for Team Services (step 9)
You need to use a PAT.
Since most organisations require password changes on all account much more regularly than yearly the likelihood of this being a big issue are next to nill.
Note: the PST is only used to authenticate and get a secret from the server that is the used for coms. Feel free to expire the PAT after you have configured the agent.
I want to call the TFS Rest API
https://www.visualstudio.com/en-us/docs/integrate/get-started/rest/basics#tfs
from an application that isn't on-premise with that instance of TFS (it'll be in Azure to be specific). Is that possible? Anything special needed to configure a cloud service to call on-premise?
Yes, it is possible, you need to make sure your TFS can be accessible from cloud or another server.
There is an article about providing internet access to TFS that can help you.
I know that it is possible to log into Gitlab with external providers such as Github.
However, I was wondering if Gitlab's oauth can be used to authenticate users to my application?
Is there an oauth endpoint that I can use?
It should be possible since the suggestion "Oauth system for third party application" seems completed with GitLab 7.7 (which is to be released)
It would be powerful to have an oauth authentication system with application management like Github.
If this feature appear on Gitlab, developers would be able to create many third party applications like Travis-CI or Scrutinizer who can Interact directly with a "Gitlab Connect" system, same as Github or Bitbucket.
We should manage authorization scope too (profile view / edit, group access, projects access etc...).
GitLab team (Admin, Gitlab) responded · Dec 22, 2014
Completed In GitLab 7.7
See the diff between GitLab 7.6 and 7.7 and:
commit ed932d8
commit f9ece12
February 2016 edit, complementary links:
GitLab as OAuth2 authentication service provider
GitLab as an OAuth2 client
Doorkeeper, what GitLab uses to implement OAuth
Note: with GitLab 13.11 (April 2021)
Register OAuth applications at the group level
Group owners can now register OAuth applications for a group.
Previously, OAuth applications could only be registered by individual users or at the instance level.
Making this functionality available at the group level reduces the administrative burden for instance administrators and removes the dependency on individual users for the configuration of OAuth applications.
Thanks to the amazing work from GitLab contributor Jonas Wälter from Siemens, this feature is now available in 13.11.
See Documentation and Issue.
No, it is not. Currently the only supported scope is api which gives the authentication client full access to everything in the user's name. See https://gitlab.com/gitlab-org/gitlab-ce/issues/22323 to track progress.