Thanks Jim! I think it makes sense for the live tests to get the value configured as a property.
If someone wants to directly use the KeyVault API, I think it makes sense to have the objectId as a required parameter (as it is now). I don't see an immediate need to auto-discover it or to have it configured per-context in advance, so I'd say a property just for the tests is fine. I. On 16 October 2017 at 20:44, Jim Spring <jmspr...@gmail.com> wrote: > Andrea - > > A PR is present plumbing in the ObjectID. I’ll be looking at fleshing out > the tests more today. > > -jim > > > On October 16, 2017 at 9:48:39 AM, Jim Spring (jmspr...@gmail.com) wrote: > > Andrea, Ignasi - > > I’ve managed to figure out the authentication issue Andrea was running into > with his KeyVault implementation keeping the live tests from working. I > don’t think a PR is needed, but I am cleaning up the code to just double > check. > > Basically, the issue is as follows: > > 1. KeyVault relies upon Azure AD for access control (this is the Object ID > passed in) > 2. A service principal (or other Azure AD object) typically has two IDs > associated with it: > - The name or AppID > - An ObjectID > > For Azure tests, currently, one must specify the Service Principal Name/App > ID as well as the secret. For the creation of the KeyVault in the test, > one needs the “ObjectID” of the Service Principal used to login. > > There are two ways to fix this: > > 1. Implement the Azure AD Graph API in order to look the information up > (note, the SP may not have access to do so) > 2. Add another parameter to be specified for Vault Live tests, say > something like 'test.azurecompute-arm.identity.objectid’ > > Thoughts? > > I’m going through my code changes now and will reach out for anything > required there to Andrea. > > -jim
