Add support for uploadpkcs12

[bilby91]

Hello,

I've been using this provider for close to two years now and it has been awesome! We have a pretty complex ADB2C setup and being able to automate everything with terraform has been very important.

I'm looking into implementing SAML IDP integrations now and we need the ability to use the uploadpkcs12 endpoint instead of the uploadSecret one (https://learn.microsoft.com/en-us/graph/api/trustframeworkkeyset-uploadpkcs12?view=graph-rest-beta&tabs=http).

I'm happy to take a stub on this, not sure how the API wants to be exposed though.

[bilby91]

I'm also realizing that there is another uploadCertificate API that might be good to include as well.

[bilby91]

@pjfebbraro I'm having a hard time figuring out an API that makes sense for the three possible permutations when uploading.

When the user uploads a key, it can be one of these:

• uploadSecret
• uploadCertificate
• uploadPkcs12

The uploadSecret is the most straight forward because the payload mimics the trustFrameworkKey structure. On the other hand, uploadCertificate only expects a JSON field key with a base64 encoded certificate. Then, uploadPkcs12 expects a base64 encoded pfx file in a JSON field key and an optional password field.

One option could be to have a keyType for the possible options secret, certificate and pkcs12 that would only be used at creation time. A new field password would need to be added as well for the pkcs12 use case.

What do you think about this approach ?

[pjfebbraro]

Hi @bilby91 , Thanks, I am happy to hear this has been useful to you! Yes I think uploading a certificate can be added. I think the key type idea would work, similar to this (https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal_certificate). I could get this implemented within the next few weeks, but if you would like try it you can submit a PR.

[bilby91]

@pjfebbraro I have a functional WIP. I've found a few gotchas (with the API and data types) that make me wonder if having the key_type is the best approach.

I'll capture my findings later today and share them with you so we can figure out best path for implementation.

[bilby91]

@pjfebbraro A few things that I found:

• When creating a new keyset using uploadCertificate or uploadPkcs12, nbf and exp are computed, they seem to be derived from the certificates. This leads to terraform thinking there is a change after the creation.

• use is empty when uploading certificates

• The uploadPkcs12 endpoint doesn't allow me to upload a pkcs12 with an empty password. This is supported in the Azure Portal and is what I've been using so far.

I'm thinking if it's better to split the resources in three indpendent ones. What do you think ?

[pjfebbraro]

I think it would be easier to keep it as on resource, since it's the same logical entity but just with some different fields populated. There is a bit more validation but still less work than creating 2 new resources. I have it mostly implemented in this branch (features/policy-key-certs). There are two working tests for uploading certificates in policy key resources.