I am building an application which will use Azure B2C as the identity system. It will include some local accounts, and some federated accounts for Enterprise SSO logins.
The application will have “application tenants”, representing customer organization/company.
I’d like a user to be able to grant users access to one or more application tenants (in case some users will manage multiple company accounts within the app).
There will also be multiple roles within the app (e.g. read only, full admin).
What is the recommended way to map a B2C User to “app tenants” and roles?
Create AAD group per tenant and role and check membership?
Custom attribute for tenantid(s)?
Or must I map users to tenants & roles in app DB/ outside of B2C?
Is this scenario described in any docs that might point me in the right direction?
Thanks!
Related
I'm trying to setup a user lifecycle flow that will allow me to create an Azure Active Directory user (Member, not Guest) when an employee is created in our HRIS tool (HiBob). There is a pre-existing integration which is enabled and allows us to get basic information (name, location, etc.).
In the HRIS system we also store some more unique data that I would like to be added to the users AAD profile (maybe an emergency contact for example) that we can then use to provision other applications (like Slack).
My issue is trying to create these custom property fields. I have read about Azure B2C as well as directory schema, custom security extensions and using MS Graph. None of these seem to be totally relevant to my situation.
FYI we are fully cloud, so Azure AD Connect is also not an option.
To store custom data in Azure AD objects such as users you can leverage Azure AD Directory Extensions in tandem with Azure AD Provisioning trough SCIM.
I have registered an app in AAD and as a admin I want to provide permission for user to read or access the data of particular group list not all group available in my MS team account. How can be achieve this any idea?
No. Azure AD app doesn't provide such a feature that scopes Microsoft Graph application permissions to specific Microsoft Teams/Groups.
The client credential flow is used to as an authorization grant typically when the client is acting on its own behalf. When you give Group.Read.All or Files.Read.All or other similar application permissions, it means the client has access to all the files/groups across the entire tenant.
You can achieve this by implement the business logic in your code. For example, providing a configuration file which includes the particular groups'/teams' object ids. And then restrict the access for users to only these groups/teams by checking if the object ids (which users are trying to access) are in the configuration file.
I am migrating a "On-Premise WinForms App" to a "Multi-tenant SaaS App" written in ASP.NET CORE. The SaaS application will be used by multiple tenants and the tenants don't see each others data. In our legacy product, user profiles and credentials were stored in each customer's database and the CUSTOMER could add/remove users from the system, as they saw fit.
In a web environment, it looks like an Identity Provider is the suggested route, by separating the user profiles and credentials from the application data itself. However, much of our data is tied to a UserId, so its important to know which USER created a record.
Now, in Azure AD, the setup would put ALL users from ALL CUSTOMERS into 1 Azure AD. I don't particularly have an issue with that, but HOW do I know what CUSTOMER the USER account belongs to?
For example, customer ACME has 2 users: Bob and Bill. My other customer FOOBAR has 2 users: Jean and Jack. If Jean authenticates against Azure AD, I need to know a unique ID for FOOBAR, so I can filter data in the web application. When Azure AD sends back an IDToken from OpenId Connect, the TenantId in the claims is the TenantId of my company, NOT a tenant identifier for the CUSTOMER.
What is the recommended setup if we are going to deploy a multi-tenant SaaS application and use Azure AD for Authentication and still control which users can access the application? Azure Active Directory B2B?
You group users using security groups (one per customer) and Configure group claims so that you get them in the tokens.
When RBAC was introduced in Azure Active directory, roles can be granted to users or collection of users (groups).We followed this blog post and added that functionality for our apps when it first got introduced. But now, we have to go for active directory premium to assign roles to groups and get roles in bearer token.Going with Azure Active directory is not a feasible solution for us as premium is gonna cost us $6 user/ month and we have lot of groups and each group has lot of users. Looking at the costs our IT team is not willing to go for this package. I was just wondering if there an alternative approach for mapping roles to groups. Or this is only doable using premium.
Using Azure Active Directory (Azure AD) with an Azure AD Premium or Azure AD Basic license, you can use groups to assign access to a SaaS application that's integrated with Azure AD( refer here about detail).
So if you want to manage the roles using the group, we need at least the Azure AD Basic license. If you were using the free edition, we can only assign the roles to the users one by one.
Instead using the role manage the access for the application, we can also use the group which also supports for the Azure AD free edition. You can check the code sample about authorization in a web app using Azure AD groups & group claims from here.
I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.