Add authoritative approles and assignments

[gtmtech]

This PR is technically missing some tests and some TLC, but I am not continuing work on it, due to moving jobs - however doing the PR now in case parts of it can be incorporated by the hashicorp team.

Essentially it:

• adds a sp_app_role block to the service_principal resource, so that it is possible to set service-principal approles as well as application approles
• adds an approle_assignments resource to authoritatively describe all approle assignments, rather than just be able to add approle assignments individually - we found this was necessary to prove to compliance/audit and regulation that RBAC was managed in a single place, and that terraform didnt allow other tools to also manage assignments.
• adds a service_principal blcok to the application resource, so that it is possible to partially configure the saml configuration as part of the approle setup - the difficulty with setting up a gallery app such as AWS is the workflow first needs to instantiate a gallery application (application object), then it needs to add a saml setting on the corresponding service-principal object, then it needs to go back to the application and configure the saml settings there, then it needs to finalise the service-principal object . This back&forth is not a supported model in terraform with the existing monolithic resources, so I got round it by adding a snippet of configuration on the application resource instead.

In my view, terraform-provider-azuread would do well to split out the resource configuration aspects of both application and service-principal resources into individual resources, much like aws's S3 resource has done in v4 of their provider. There are too many configurations which don't support just managing the entire application or service-principal monolithically.

• As part of this PR, I had to change the order in which the application configured things, because it didn't work with gallery applications - and the application code is too opinionated on trying to configure a lot more attributes than should be configured with no way of switching them off. For example, the application always wants to set the api attribute, but once a gallery application has been instantiated, changing the api results in all kind of errors on the service-principal side which cannot be reconciled - instead for gallery applications, the api needs never to change. The same is true of approles on the application side too - they should be made to not set, if setting the sp_app_roles instead.

Although it works for me, it probably needs a review and a little tidy up a bit. I'm hopeful its of use.

[manicminer]

@gtmtech Thanks for your work on this and for sending back to the project - even if not complete it's still a valuable contribution that demonstrates a workflow that worked in your situation, and builds towards an eventual solution to the myriad of dependency issues we're currently facing between applications and service principals.

Best of luck in your new role!

[github-actions[bot]]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.