Why does Identity Governance service uses a mix of v1.0 and beta msgraph endpoints?

[tabroughton]

Within the Identity Governance service the msgraph client is using a mixture of beta and v1.0 endpoints but this poses some potential issues.

1) some features within EntraID currently in use are not available in the beta api 2) the API spec for beta and v1.0 are often quite different to interoperability could be an issue 3) Microsoft state not to use the beta api for anything in production which creates risk that we (and many other) organisations will struggle to accept

When the service was first being developed It would appear from the original commit, (Add support to manage access packages in identitygovernance), beta api was used because it returned more information about access packages.

        // Use beta version because it replies more info than v1.0
    accessPackageClient := &msgraph.AccessPackageClient{
        BaseClient: msgraph.NewClient(msgraph.VersionBeta, o.TenantID),
    }

Apart from the risks of using beta in production environment one of the drivers for looking into this was that we couldn't find the features we are using in EntraID in the TF Provider. For example:

The access package policy assignments in the beta are constrained to DurationInDays BUT we need access packages to be only assigned for hours.

In v1.0 this is doable using the expiration<expirationPattern> attribute and it is this that is currently supported by microsoft (proven by using the EntraID UI and checking the read msgraph endpoints).

We are not alone with this issue - there are a couple of feature requests for this in the azuread backlog:

• 1119

• 1148

Almost all other services within this provider are using the default v1.0 msgraph endpoints. Could we discuss the options/implications for addressing this or whether it is feasible at all to accommodate v1.0 for all of Identity Governance?

[manicminer]

Hi @tabroughton, for a bit of background, we are currently migrating from the Hamilton SDK to a new Pandora-based SDK that will be maintained by HashiCorp. The new SDK is much more modular and makes it easier to select v1.0 or beta APIs depending on the context.

I worked on migrating Identity Governance to the new SDK earlier this week. Whilst I cannot say for sure which operations I needed to continue using beta APIs, I've moved some operations to the stable API where the transition was straightforward. As you say, there are implementation differences which gets fairly complex to navigate. We can certainly look to move more operations/resources in Identity Governance (perhaps all of them) to the v1.0 API, and PRs would certainly be welcomed once the SDK migration has landed.

We do seek to use v1.0 APIs wherever possible, however in our experience it's often necessary to lean on a beta API, either due to feature gaps, or limitations or demonstrable bugs in a given v1.0 API. As to the veracity of Microsoft's guidance on not using beta APIs "in production", due to the above we have to take that with a degree of salt and there is no better example of this guidance being flouted than in the Azure Portal, which regularly makes use of beta APIs in MS Graph 🙂

[tabroughton]

Thanks for your response @manicminer

PRs would certainly be welcomed once the SDK migration has landed.

Is there any suggested time frame for a release of the SDK?

there is no better example of this guidance being flouted than in the Azure Portal, which regularly makes use of beta APIs in MS Graph

Good point, yes after a bit more inspection, it would appear that perhaps even in this case their Access Packages UI seems to be using a mixture of their v1.0 and beta APIs.

[manicminer]

The new SDK is largely complete, as well as the provider migration over to the new SDK. I am working through a long tail of acceptance test runs and bugfixes, so it's difficult to say exactly, but expect something very soon 😁