-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't call /directoryObjects for applications or service principals #713
Don't call /directoryObjects for applications or service principals #713
Conversation
…ssions Since we no longer use the @odata.id returned by the API, it's not necessary to retrieve owner principals via the /directoryObjects endpoint. This can sometimes require additional permissions, which we did not document, and which is undesirable in any case.
I do not know yet why, but this doesn't work for me. I receive the same:
Testing with the following declaration: terraform {
required_providers {
azuread = {
source = "registry.terraform.io/hashicorp/azuread"
}
}
}
# Has the following permissions: Application.ReadWrite.OwnedBy, User.Read
provider "azuread" {
client_id = "id"
client_secret = "secret"
tenant_id = "id"
}
resource "azuread_application" "app_taras-playground" {
display_name = "taras-playground"
owners = [
"4ad0e09f-a951-4946-90a2-dacddea52079", # object-id of the SPN from above
"3c422d16-cebe-4f1f-a282-2163a8ca3dcf" # my object-id
]
prevent_duplicate_names = true
web {
redirect_uris = ["https://taras-playground/"]
}
}
resource "azuread_service_principal" "spn_taras-playground" {
application_id = azuread_application.app_taras-playground.application_id
app_role_assignment_required = true
owners = [
"4ad0e09f-a951-4946-90a2-dacddea52079", # object-id of the SPN from above
"3c422d16-cebe-4f1f-a282-2163a8ca3dcf" # my object-id
]
}
resource "azuread_service_principal_password" "taras-playground" {
service_principal_id = azuread_service_principal.spn_taras-playground.id
} |
Correct me if I am wrong, when we perform create application and pass |
@tsologub There are two ways the provider assigns owners - when creating it will include up to 20 owners in the POST to /applications to create the app, and when updating (or when there are >20 owners to assign at creation) it will POST to the /applications/GUID/owners endpoint. When you get the 401 error, does Terraform prefix the error output with "Could not create application", or "Could not add owners to application"? That will indicate which of the two calls are failing. The docs state that Application.ReadWrite.All is required to create applications too, but this isn't always the case. So IMO it's not clear whether that same role is needed to append owners or not, since many operations on applications do work with Application.ReadWrite.OwnedBy. The effective permissions are also very different when authenticating as a user versus as a service principal - I'm assuming you're doing the latter as we're talking about app roles? |
In my case, I have two owners included. So the
Yes, I am authenticating with the service principal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
This functionality has been released in v2.15.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
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. |
No longer retrieve owner principals when managing applications or service principals. Since we no longer use the
@odata.id
returned by the API, it's not necessary to retrieve owner principals via the/directoryObjects
endpoint. This can sometimes require additional permissions, which we did not document, and which is undesirable in any case.Additionally, document additional potentially required permissions for groups as we can't get around this when managing groups, due to necessarily needing to distinguish between different types of owner principals.
Fixes: #703
Test results