How to Automate the Creation and Configuration of an Azure Enterprise Application - azure

Question

I am struggling to create and configure an Azure Enterprise Application.
I have been trying to accomplish this task via PowerShell. I attempted to create an enterprise application by making use of the tags an application registration can have by following this github post, which essentially boils down to adding this tag to the service principal:
$tags = #("WindowsAzureActiveDirectoryIntegratedApp")
From there, I seem to be having problems with adding an identifier uri to the application. Here is the error:
Values of identifierUris property must use a verified domain of the organization or its subdomain
This error does occur to me whether I try this using PowerShell or Terraform.
I think it might be possible to resolve this error by adding the url as a custom domain, but the weird thing is that this url is used by the enterprise application that is setup manually, so I'm a little confused by this error and think the problem might be more than just adding the url as a custom domain.
I would like to note that at this point if I remove the identifierUris the application registration and service principal are both created, but if I were to go to SAML section of the service principal, there does not seem to be a way to manually upload a SAML metadata file (via PowerShell only - it does work in Terraform, interestingly enough).
This brings me to the other issue that I face for configuration: SSO configuration, specifically via SAML. I would like to programmatically upload a SAML metadata file and then modify some of the fields in the SAML section of the service principal from the result of that upload. However, I have been unable to find a way to do this or find an equivalent workaround.
EDIT: Turns out you can upload a token certificate to the service principal via Terraform - for more info on the command see here. You will need to transform your data into an accepted value format (I would recommend .pem if you are coming from a .xml file). I am not 100% sure if this command works yet, as I am left with this message under the SAML Certificates section:
**Token signing certificate**
A certificate has been successfully created. Please reload the page to make it active.
And reload doesn't seem to be working yet...
Issues still left to address:
Identifier uri (previously mentioned)
How to edit the Attributes & Claims fields
EDIT 2:
So I was able to uncover this resource, which offers a step by step guide for automating away SAML-based single sign-on via MS Graph.
Still testing it - and there are some parts that can only be done on Windows (creating a custom certificate) - but this seems very helpful.
Based on my early testing, the only problem I have found with this method so far tis that might not edit the Attributes and Claims section of SAML SSO. However, I believe by creating your own application template this method solves the identifier issue I was running into.

Answer 1

So, the MsGraph tutorial largely covers most of what I needed for my usecase. A few things of difference that I would note:
I used a template application that suited my needs better*.
Attributes and claims are fixed by following the tutorials points on creating and assigning a claims mapping policy. You will not be able to see this through the GUI. Additionally, getting the updated service principal also does not display this configuration**.
If you have difficulty updating your logoutUrl I would see this github post - you can configure it via az rest, PATCH, and this endpoint: "https://graph.microsoft.com/v1.0/applications/$($app_id)".
Tying it all together is a little annoying via PowerShell as it seems that some of the commands take longer to process than others. As a result, I would recommend implementing some sort of retry into your script and even calling Start-Sleep so that future cmdlets recognize resources created by the ones that have already been called.
*Note the process of finding a template that works best for you can be a bit tricky if you do not already have one in mind. I ended up selecting the template that matched the enterprise application I was using when doing this process manually. I am unsure if every enterprise application available has a template that matches it.
**The only way to get a confirmation that a new claims mapping policy worked is to see this message (under the Edit section of Attributes & Claims, which is in the SSO section of the service principal): "This configuration was overwritten by a claims mapping policy created via Graph/PowerShell. Learn More.".