azuread_access_package_resource_package_association only supports groups

[mariussm]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureAD Provider) Version

2.37.0

Affected Resource(s)

azuread_access_package_resource_package_association

Terraform Configuration Files

locals {
  applications = ["Application 1", "Application 2", "Application 3"]
}

resource "azuread_application" "applications" {
  for_each     = toset(local.applications)
  display_name = each.key
  owners           = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal" "applications" {
  for_each       = azuread_application.applications
  application_id = each.value.application_id
}

# Create an access package for our three applications
resource "azuread_access_package" "all_applications" {
  catalog_id   = azuread_access_package_catalog.blogpost.id
  display_name = "All applications"
  description  = "Provides access to the three applications we created"
}

# Waiting for bugfix: # Associate all applications to our above acess package
resource "azuread_access_package_resource_package_association" "all_applications" {
  for_each                        = azuread_access_package_resource_catalog_association.blogpost_applications
  access_package_id               = azuread_access_package.all_applications.id
  catalog_resource_association_id = each.value.id
}

Expected Behavior

When an application is provided, the default role of 00000000-0000-0000-0000-000000000000 should be used, while "Member" should be used for groups.

Currently only Member and Owner is supported values for access_type, which only works for groups. We need to be able to provide guids, that correlates to the resource roles of the resource, such as app roles for applications.

Actual Behavior

Fails, because it tries to assign the member role, which does not exist for applications

Steps to Reproduce

Simply try to assign an application instead of a group

I have blogged about it, so you can also find some details here: https://goodworkaround.com/2023/04/14/terraforming-your-way-through-azure-ad-entitlement-management/

[manicminer]

@mariussm Thank you for requesting this. I can see that the current design may have made some assumptions, however we can expand the support as needed. Thanks for writing the blog post to help spread knowledge about this feature.

To help with designing the schema for supporting applications as well as groups, would you be able to post some examples of AccessPackageResourceRoleScopes that you have used? Thanks!

[Stinjul]

Hi, I'm not sure if this is the kind of example you wanted but an AccessPackageResourceRoleScope for an approle looks like this:

{
	"accessPackageResourceRole": {
		"originSystem": "AadApplication",
		"originId": "22222222-2222-2222-2222-222222222222",
		"accessPackageResource": {
			"id":  "33333333-3333-3333-3333-333333333333",
			"originId":  "11111111-1111-1111-1111-111111111111",
			"originSystem": "AadApplication",
		},
	},
	"accessPackageResourceScope": {
		"originId": "11111111-1111-1111-1111-111111111111",
		"originSystem": "AadApplication",
	}
}

Where:

• "11111111-1111-1111-1111-111111111111" is the id of a servicePrincipal
• "22222222-2222-2222-2222-222222222222" is the id of an appRole
• "33333333-3333-3333-3333-333333333333" is the id of the accessPackageResource you'd get from using azuread_access_package_resource_catalog_association

You should be able to get the servicePrincipal id and the originSystem from fetching the accessPackageResource internally (which I think you're already doing for the groups?).

So all that would be needed is an attribute to provide the GUID of the approle (or other kinds of resources like Sharepoint Online site roles which look like they work the same way).

As for access_type, you could change it so it is only used it when the originSystem is AadGroup, but that's up to you.

[benjy44]

It seems to be also an issue for SharePointOnline resources The accessPackageResourceRoleScopes looks like this:

{
            "id": "6e5d82c3-f456-472e-b86e-46c7e0c20b0b_6d4f659f-b5f6-4949-93e5-9ea208fe608c",
            "createdBy": "[email protected]",
            "createdDateTime": "2020-01-10T08:21:15.273Z",
            "modifiedBy": "[email protected]",
            "modifiedDateTime": "2020-01-10T08:21:15.273Z",
            "[email protected]": "https://graph.microsoft.com/beta/$metadata#identityGovernance/entitlementManagement/accessPackages('2cf4eb96-0dd0-4d1c-a9ac-48f65f93090e')/accessPackageResourceRoleScopes('6e5d82c3-f456-472e-b86e-46c7e0c20b0b_6d4f659f-b5f6-4949-93e5-9ea208fe608c')/accessPackageResourceRole/$entity",
            "accessPackageResourceRole": {
                "id": "6e5d82c3-f456-472e-b86e-46c7e0c20b0b",
                "displayName": "Some Display Name",
                "description": null,
                "originSystem": "SharePointOnline",
                "originId": "5"
            },
            "[email protected]": "https://graph.microsoft.com/beta/$metadata#identityGovernance/entitlementManagement/accessPackages('2cf4eb96-0dd0-4d1c-a9ac-48f65f93090e')/accessPackageResourceRoleScopes('6e5d82c3-f456-472e-b86e-46c7e0c20b0b_6d4f659f-b5f6-4949-93e5-9ea208fe608c')/accessPackageResourceScope/$entity",
            "accessPackageResourceScope": {
                "id": "6d4f659f-b5f6-4949-93e5-9ea208fe608c",
                "displayName": "Root",
                "description": "Root Scope",
                "originId": "https://company.sharepoint.com/sites/mysite",
                "originSystem": "SharePointOnline",
                "roleOriginId": null,
                "isRootScope": true,
                "url": null
            }
}

We can see the originID is not a regular UUID so it's not possible to import this resource to a azuread_access_package_resource_catalog_association

[wiredsource]

hi guys, We do see something similar yet this is for service principals. But that is when adding the service principal to the "azuread_access_package_resource_catalog_association". So this might be another issue actually. That being said we did validate that the same issue occur on the plain graph api call... Both tf and ms graph returns the error text "CallerNotResourceOwner: The caller is not the resource owner" which is not true.

[tjrobinson]

hi guys, We do see something similar yet this is for service principals. But that is when adding the service principal to the "azuread_access_package_resource_catalog_association". So this might be another issue actually. That being said we did validate that the same issue occur on the plain graph api call... Both tf and ms graph returns the error text "CallerNotResourceOwner: The caller is not the resource owner" which is not true.

We've come across this too, I'm hoping the solution is this - granting the "Group.ReadWrite.All" permission: https://github.com/microsoftgraph/microsoft-graph-docs-contrib/issues/8474

[suprizing]

Confirming that azuread_access_package_resource_package_association still does not support applications. Even tried a workaround where i created an app role called "Member" for the associated app and then tried using access_type = "Member". Still didn't work.

[wiredsource]

hi guys, We do see something similar yet this is for service principals. But that is when adding the service principal to the "azuread_access_package_resource_catalog_association". So this might be another issue actually. That being said we did validate that the same issue occur on the plain graph api call... Both tf and ms graph returns the error text "CallerNotResourceOwner: The caller is not the resource owner" which is not true.

We've come across this too, I'm hoping the solution is this - granting the "Group.ReadWrite.All" permission: microsoftgraph/microsoft-graph-docs-contrib#8474

Now it is not a group we're trying to add but an application service principal. The "Group.ReadWrite.All" will not work. Yet it is actually been added as we also need that feature for other purposes. The permission that should fit is "EntitlementManagement.ReadWrite.All" but it does not help. The error meesage we got also indicate that the ownership is not being read correctly. So we do not think it is a permission issue... This is clearly a bug

[anuj530]

I can confirm this is still an issue. When trying to add a service principal application, I am receiving the following error: │ AccessPackageResourceRoleScopeClient.BaseClient.Post(): unexpected status 404 with OData error: RoleNotFound: The role was not found. We really need to be able to add applications to access packages as it is one of the biggest features of Entra Entitlement management.