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.
Related
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.
Background
I have nuget packages in a private nuget feed on azure devops and I try to consume them from on-prem TFS.
This worked, but only for a few hours
In azure devops, I navigated to Artifacts -> Connect to feed and clicked the link "Download NuGet + Credential Provider". When running CredentialProvider.VSS.exe -U URL_TO_FEED I got a jwt token.
In tfs on-prem, I navigated to the "NuGet restore" step in the build definition. At "Feeds and authentication" I selected "Feeds in my NuGet.config" and at "Credentials for feeds outside this account/collection" I clicked "Manage". In the "Add new Team Foundation Server/Team Services Connection" dialog box I selected "Token Based Authentication" and filled in the values. I put the token I got from CredentialProvider.VSS.exe in the field "Personal Access Token".
The nuget packages were restored so everything seemed good, but the next day it didn't work any longer since the token was only valid for a few hours (I decoded it to verify).
Question
How am I supposed to make this work? It seems strange to use a "Personal Access Token" since it shouldn't be related to me as a person (in case I leave the organization for example). The username for the token generated by CredentialProvider.VSS.exe was VssSessionToken which might indicate that it's not a personal token related to me, but I don't know.
The PAT (Personal Access Token) are pretty much the way to go for Azure Artifacts feeds as they are the generic to provide access to different parts of Azure DevOps.
If you are worried about the fact that they are personal it might be a solution to use a service account to generate the tokens.
If you want a PAT that has a longer lifetime it might be easier to create one yourself (see https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/nuget-exe?view=azure-devops&tabs=new-nav#add-a-feed-to-nuget-2 for instructions)
In short you will create a PAT with the 'Packaging (read)' permission, as to limit the possibility of abuse.
Two things to take into account:
PAT's always have an expiration date so you will need to keep track of that.
PAT's give access to the Azure DevOps Api as the user that created them, so make sure they are not accessible and limit the permissions as much as possible.
We're using Jenkins (and precisely Cloudbees) for couple years. Well, it works.
Not I have new use case when I would like to allow trigger build remotely (w/o user account in Cloudbees).
Looks like it's impossible (standard token trigger mechanism requires an account in Cloudbees).
The only one way that I see it to set-up instant message integration (e.g. Jabber) and trigger builds in chat. It's nice solution that I would like to have, but ... it doesn't work for me. No errors and no messages (I tried different jabber servers).
Because I have only one such weird user I don't want to install special software (like Jabber/IRC server) and wanna use existing (like Gtalk or similar).
Any thoughts will be welcome.
standard token trigger mechanism requires an account in Cloudbees
You can use the Build Token Root plugin to bypass authentication long enough to check the token.
In the long term it would be desirable for Jenkins to let users create non-user principals that would have their own API tokens and SSH keys (but no UI login) and a restricted subset of permissions, so you could freely create a one-off principal for a specific purpose such as triggering builds. The infrastructure for such a feature does not exist today, however.
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.
I'm currently tasked with setting up a TFS server for a client. The TFS will mainly be accessed by local (on-site) users through the internal network... Easy!
But what about the few remote users we have? Should they connect via VPN or is it better to make the TFS server public and have the users connect over SSL and provide username and password to the TFS?
Do you have any suggestions on how these solutions will perform compared to each other?
VPN is the way to go if you want the optimal TFS experience with TFS 2005 or TFS 2008. While TFS mainly uses web service based protocols that can all go over SSL, there are a few small things that will not work unless you have proper network access. For example:
Viewing the Build Log (unless worked around)
Access Team Build drops
Publishing Test Results
As well as a few other little niggles. Going the VPN route will also mean that your TFS installation will vary less from a standard base TFS installation which gives you some peace of mind that you won't run into any problems when it comes to upgrading to a new version, applying service packs etc. (or at least any problems you run into will have been run into by many before :-) ). Going the SSL route you are treading a less worn path - though obviously plenty of people do run it that way including CodePlex and all the commercial companies that provide a hosted TFS installation.
The downside of VPN is that usually you are granting users to an entire section of your network (unless you are running TFS in it's own mini private network or something). If you go down the SSL route then be sure to properly test the new team projects as this is easy to break and you might not realise until you try and create one either inside or outside the network.
For additional information, see Chapter 17 of the TFS Guide.
I'd start with a few questions: does the client have a VPN? And are the remote consumers on this VPN already? How secure does this need to be?
(In our case, we have lots of outside vendors we don't want on our VPN, so our source control is publicly accessible with SSL)
When I did it, I used a VPN. Was easier to setup, and made sure that no-one could even see the machine with out being authenticated via the VPN - this was obviously way better from a security standpoint, which trumped any performance benefit we would have got from using SSL, if there even was one...
My previous experience with TFS was in an environment where we had a team of developers staffed out at client sites all over the city. In many situations we still accessed our TFS instance instead of something at the client site. We used SSL with public access to TFS. It worked very well for us.