[Question]: Can i specify AUTHCONTEXT on organizational level and deploy to different tenants in underlying repos?

[SimonBFrandsen]

Question

Hi, I have created an S2S AUTHCONTEXT on organizational level (ClientID and CliedSecret for entra registration), and want to use that same entra registration to deploy from all repositories in the organization to different customers. Is it possible to do that, and only specify customer environments (tenant-id and environment names) in each PTE repository? I would like to manage the secret on top-level, so that I do not need to update the secret in 100 different repositories when the secret expires.

[freddydk]

No, the tenant ID is part of the AUTHCONTEXT, and that is by design.

Security wise, having one AAD App having access to deploy to multiple environments is a bad design. I get it that it is easier DevOps wise, but I would not do or recommend that.

It is OK to have one AUTHCONTEXT secret to provide access to multiple environments in the same tenant, which is one of the reasons behind the design.

Our recommendation for Per Tenant Extensions is that these are created in an organization owned by the customer with the partner as a collaborator - in this case, one AUTHCONTEXT secret in that organization would have access to all environments owned by the customer. That secret could be available to all AL-Go repos in the organization as this is the customers ownership.

If you have the per tenant extensions in your organization, I would create one AUTHCONTEXT secret per customer (on the organizational level) - and you name them customer_AUTHCONTEXT (although secret names can only have very limited character set in their names - some mangling might be needed).

That secret should be made available, ONLY to the repositories, which contains code for that customer. Environments in this repository are environments for that customer. You would also need a setting called "AUTHCONTEXTSecretName": "customer_AUTHCONTEXT" in the repositories, which has access to the customer_AUTHCONTEXT - then environments would use that. That setting unfortunately cannot be made on an organizational level.

When client secrets expire, it is fairly easy to use create a script, which uses the AZ CLI (az ad app credential reset) to cycle the secret in the AAD App and then use the GH CLI (gh secret set) to update the secret in the organization. This process can be automated and executed daily, weekly or monthly depending on security restrictions.