Im in evaluating and recommending mode - for the SAAS features of Azure AD. This is the rather cute re-purposing of OAUTH for onboarding tenants (rather than social networking connections). its cute because its an "automation" of a trust framework - for peer-peer or community-of-interest trust structures. However, the impact of onboarding on discretionary Graph permission is what is unclear.
Lets say my Azure AD has application objects representing the authorized consent for 5 other Azure AD instance to talk to their corresponding tenant in a given SAAS app, hosted at validated domain peter.com. logically, there are now 5 virtual sites:https://peter.com/tenant1/default.aspx,https://peter.com/tenant2/default.aspx,https://peter.com/contoso.onmicrosoft.com/default.aspx,https://peter.com/validated.contoso.co.uk/default.aspx, etc. The latter happens to be an Azure AD tenant that leverages its ADFS for authn, and thus has custom UPNs.
My requirement set includes controls over the resulting access to the 5 Graph API endpoints. For industry-specific business reasons, the SAAS app should be only able to read certain user attribute, per Azure AD tenant.From tenant 1, it can read core attribute and First name. From tenant 2 it can also read email ADDress, in leveraging the read operation of the the Graph API.
Does the Azure AD controls enable this, today? (even if I have to user advanced powershell to configure the controls in the graph)?
Or, should I be thinking of writing my own meta-Graph service, that imposes this security model, by containing the proxying the 5 tenant Graph API endpoints?