> How much of the KeyVault api should we implement? I’ve started creating > actual tests for the Key operations and will be prioritizing the list in > order that I’ll be adding them.
I don't know how complex the API is, but it is quite straightforward to implement APIs in jclouds once you have a couple methods right, so I'd say we'd try to implement all methods, if possible. I'll be happy to help here. > > I’ll try and do a PR per set (if you don’t mind Andrea). PRs always welcome! > > I’ll try and catch you guys on IRC tomorrow morning pacific time. I've been quite offline recently but I hope to start having more time, so feel free to ping me whenever you find me there. > > -j > > Sent from my iThingy > >> On Oct 17, 2017, at 15:39, Jim Spring <jmspr...@gmail.com> wrote: >> >> Andrea - >> >> Take a look at the PR I did against your feature/vault-api branch. I’m >> extending the tests now. >> >> I’ll do a PR once I get all the key tests implemented. >> >> Would it make sense to find some time to chat? Or are you ok with me moving >> forward on extending things? >> >> -jim >> >> >>> On October 17, 2017 at 1:52:20 AM, Andrea Turli (andrea.tu...@gmail.com) >>> wrote: >>> >>> Thanks Jim! >>> >>> An additional property makes sense for liveTests as well. >>> Direct use of Azure AD GraphApi looks a bit hard to me, so let's make >>> jclouds accept an extra parameter that will allow at least to specify an >>> already existing objectID. >>> wdyt? >>> >>> On Tue, Oct 17, 2017 at 10:33 AM, Ignasi Barrera <n...@apache.org> wrote: >>> >>> > 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 >>> >
