andycheek (Customer) asked a question.
Has anyone any experience of collecting AAD groups & memberships AND linking the groups as entitlements for different applications?
AD is a much simpler beast as we are able to have separate application-specific ADCs to collect the groups as entitlements (and therefore automatically linked to the relevant application) and the group membership resolved to the actual account collected by a separate global ADC. The AAD collector model does not appear to support this as we have been told that membership resolution to data from a separate collector is not supported. The implication is that we have to collect ALL our AAD accounts and relevant application groups in the one collector - hence the question. How do we then manage those groups as application entitlements?
Not sure if this is something that would work... Can you use a multi app collector to collect the groups per applications and have those different applications use the "Directory For Account" option to rely on the main account they would have in your AAD? That way you still have all groups on a single AAD account but split as per the multi-app collector setup..
Tim, interesting idea but how would that work? Specifically 1) how could you identify which groups were associated with which application and 2) how would the accounts be associated to a single (and separate) directory? Our only experience of multiapp collectors is where the accounts AND entitlements are distinct to the relevant applications - in this scenario, same as for AD, we would want the accounts to go into a central directory which would then be referred to in the applications.
I suppose you could add a value on a new or existing attribute on the group to identify which groups belongs to what application.
If you use the option for directory for accounts on application (general settings), you can define a master directory from which the accounts that will be used to assign the application groups to. Visa versa if you request something for your application and IGL sees you have no account in the master directory it will create an account on your master directory.
I have never used these options together, so would need some testing, but on paper it looks feasible.
Tim, see my previous answer to Boris - we were told and have proved (unless there is some magic hidden setting in the REST WS collector that nobody is telling us about) that group memberships are only resolved to accounts collected in the SAME collector. Which means one of the following unhelpful scenarios:
It just all feels unnecessarily overcomplicated AND restrictive at the same time.
That said - I cannot believe we are the only people who would want to do this.
Andy, you compared AD to AAD.
"AD is a much simpler beast as we are able to have separate application-specific ADCs to collect the groups as entitlements"
Is there a reason you can't use the same approach with AAD?
Boris, Our understanding (seemingly borne out by our subsequent testing) is that you have to have the accounts in the same collector as the groups/group memberships to resolve them. This is NOT like the AD collector which allows you to resolve membership to an account collected by a different collector.