You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 9, 2024. It is now read-only.
We need to have Azure AD B2C for volunteers not associated with Red Cross and its domain
Could we have claims on every user saying which national society (Tenant) they have access to.
This is not the Azure AD tenant ID - but something that enables us to check for authorisation if a particular user in a bounded context has access to the national society it claims to have.
Would it be an idea to have Identity Server infront of all this and augment the tokens with more information and let UserManagement interact with this and provide the mapping between users and what national societies they have access to.
We've had a long discussion about this topic today at the Red Cross, considering several options (AAD /w B2B collaboration, AAD B2C, HumanitarianId) for IdP system. The decision was to go with AAD B2C. @epromprovisioned a new B2C instance - cbsb2c.onmicrosoft.com - and we will look into configuration offline. TenantId is f52c8c8f-3d42-4af0-8983-3805e85a1ad6.
You can add custom attributes and add them to claims to be returned to your app, so there is no need to add 'man-in-the-middle' for that part.
We need to have Azure AD B2C for volunteers not associated with Red Cross and its domain
Could we have claims on every user saying which national society (Tenant) they have access to.
This is not the Azure AD tenant ID - but something that enables us to check for authorisation if a particular user in a bounded context has access to the national society it claims to have.
Would it be an idea to have Identity Server infront of all this and augment the tokens with more information and let UserManagement interact with this and provide the mapping between users and what national societies they have access to.
See also #31, #328, #510
The text was updated successfully, but these errors were encountered: