In Vault API 3.1.1, is there any way of using some integrated windows authentication mechanism to forward Windows/Active directory credentials to login to Vault?
The reason is that we have a web service using Vault API that in the background, checks in checks out files. At the moment I am forced to use a single user in that webservice, and it seems when the webservice is used by several users at once it blocks, causing timeouts etc.
All users of this app are Active Directory Vault users, so I was wondering whether it is possible to forward their network credentials to Vault.
What is the recommended approach anyway for this scenario?
Vault API: single login sucks
Moderator: SourceGear
At the moment, the Vault server doesn't pay attention to any network credentials, only to the username and password supplied in the Login method. I don't have any recommendations for this scenario, because I've never seen anyone trying to do this before. I'll need some more information.
1. How many Login calls are you making? Are you only making one and passing around the ClientInstance, or are you making several, and giving each ASP.Net session its own ClientInstance?
2. Are the users also Vault users? Could your ASP.Net app prompt them for their Vault credentials and pass that on to the server?
1. How many Login calls are you making? Are you only making one and passing around the ClientInstance, or are you making several, and giving each ASP.Net session its own ClientInstance?
2. Are the users also Vault users? Could your ASP.Net app prompt them for their Vault credentials and pass that on to the server?
I was afraid of that...jeremy_sg wrote:At the moment, the Vault server doesn't pay attention to any network credentials, only to the username and password supplied in the Login method. I don't have any recommendations for this scenario, because I've never seen anyone trying to do this before. I'll need some more information.
Whenever the webservice is called, it logins, check in the file, and logouts. So I guess this counts as "several clientinstance". Can you suggest a good way of sharing clientinstance in a webservice scenario?jeremy_sg wrote: 1. How many Login calls are you making? Are you only making one and passing around the ClientInstance, or are you making several, and giving each ASP.Net session its own ClientInstance?
This was discussed. All users are Vault users. But we don't want to store their password anywhere. So they will have to supply their password everytime they check in. That would be tiring after a while...jeremy_sg wrote: 2. Are the users also Vault users? Could your ASP.Net app prompt them for their Vault credentials and pass that on to the server?
You could try prompting the user for the Vault username/password once, creating a new clientinstance and caching the clientinstance after successfully logging in. That way, the user wouldn't have to reenter their Vault credentials as long as your ASP app is up. You may have to do some tricks to keep the ClientInstance connected, such as periodically refreshing to make sure that the server doesn't time out the connection.
The problem is that this is a webservice, as such quite stateless... Hmm I guess it does need re architecting so that each user has their own ClientInstance, somehow.jeremy_sg wrote:You could try prompting the user for the Vault username/password once, creating a new clientinstance and caching the clientinstance after successfully logging in. That way, the user wouldn't have to reenter their Vault credentials as long as your ASP app is up. You may have to do some tricks to keep the ClientInstance connected, such as periodically refreshing to make sure that the server doesn't time out the connection.
Another possible solution (probably bad idea though) is to have a number of client instances, say four that can be "pooled"... is there a way of knowing whether a clientinstance is "busy"?