My requirement is to have Multi-tenant application. I am trying to select the correct AD directory structure. I am under the understanding that a tenant is an AD directory. I need to be able to have group, role, and policy security options as well as user self sign-up. I have started on the journey of using Azure B2C directories but this does not seem to be the correct solution because roles do not seem available. Lastly, I also need the ability to manage authorizations to all tenants which I would like to build an Admin app to do so; I plan to use Microsoft Graph API for that but I am not sure if that will work either. Can someone help me to answer these questions. I have been searching as well as testing many scenarios.
You can assign user roles and group roles through AAD. https://learn.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles
You can also manage permissions through roles based access control. You do not need to use b2c to manage user permissions unless you are connecting your outside company to Microsoft AAD, rather than building a custom app within Azure. https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal
The tenant includes your resources that you want managed under that tenant. It is not exactly synonymous with an AAD because it can include more than just your AAD. You can use it solely to manage your AAD if you wish, though (and even include subscriptions in other tenants that are linked to your AAD tenant).
Graph API is useful for managing more complex user data. Whether you need this depends on what you are aiming to accomplish.
Related
I'm adding an external identity provider, Azure multi-tenant, as a login option. I have local accounts right now and they know nothing about Azure AD users.
I want to create an Azure Enterprise App that other tenants can use to set up SSO using OpenID Connect. Also I want the app to support User Provisioning by setting up a SCIM API.
I can't really find any documents on how to handle linking Azure AD users with the existing accounts in my IDP. I've seen examples where users can login using their local account, authenticate with Azure, and then their local account is updated to have the Azure AD User ID. This approach still seems pretty manual. Another thought was to have a step in the login journey, where if no local account has the Azure AD User ID then find a local account with the same email. I don't like this approach either since the emails might not always match. Is there an approach where an admin can automatically link all accounts with a sync or upload?
SYSTEMS
First it's worth clarifying roles:
Role
Details
Authorization Server (AS)
Your UIs and APIs receive tokens from this. It is where accounts and linked accounts are stored. It is where you use SCIM to update account records. It is where you apply account linking logic.
Identity Provider (IDP)
There can be multiple of these. When your apps call the AS it manages connections to them, and exchanges IDP tokens for AS tokens that are returned to apps. It is not usual to use SCIM against an IDP.
You are using IdentityServer as the AS so your UIs and APIs will continue to use IdentityServer tokens and remain simple. Meanwhile Azure AD will become an alternative IDP. So on the data side of things your architecture is in a good place.
AUTHENTICATION ACTIONS
I would aim to solve your problems via custom authentication actions, and to design this in a vendor agnostic way. Not all providers support these concepts, but IdentityServer has some pretty good extensibility features, so hopefully it has what you need.
A bit of code, configuration and technical investigations in IdentityServer feel like the correct direction, with no complexity added to your applications. I will describe techniques in terms of Curity (where I work), but the same principles can apply to any system.
USERNAME AUTHENTICATOR
A great way to deal with user specific differences is to make the initial screen prompt only for an email. See this example for how that looks. Later, when authentication has completed, you could set a cookie so that this screen is not shown on subsequent logins.
Then, before asking for credentials, apply some scripted logic, eg to look up existing account attributes, and decide how the user should authenticate. You might decide to route unknown users to Azure AD or do something based on business partner email suffixes.
DATA UPDATES
Something simple that might work in advance of adding Azure AD support is to assign all users a Tenant ID, and perhaps existing users get a Tenant ID of 1. Only those users are allowed to sign in with Identity Server - all others have to use Azure AD.
SCRIPTED LOGIC AND ACCOUNT LINKING
For a worked example of how this looks, see this Account Linking with Facebook tutorial. In this example the objective is to update the main account with a new linked account. This account linking doc may give you some additional ideas for your scenario. It should be possible to run custom logic before triggering authentication or once your have the Azure IDP attributes.
INVOLVE THE USER IF NEEDED
It may also be useful to present a custom screen to ask the user if they have an existing account when they first login via Azure AD. If not then an Azure AD login can create the primary account in IdentityServer data in addition to a linked account.
USERS AND PARTNERS
How users onboard is interesting, and discussed in this detailed article. I always start by getting a feel for the type of assets involved:
Type
Description
Personal Assets
You allow any user to sign up and they only have access to their own assets
Corporate Assets
Users are provisioned by an administrator, eg a banker is granted access to financial data according to business rules
In your case it feels like users are from the second category, so to enable a user to fully sign up you need data from the partner, either fed in manually or by getting them to call your API, before you can assign the user the correct tenant ID. This might eventually result in TenantID=23, but there is nothing to stop you initially allowing users to onboard and placing them in a default TenantID=0 bucket.
Ultimately this all comes down to data, claims and API authorization. Eg APIs could return certain data to TenantID=0 users but only return privileged data to users whose tenant ID has been asserted by an administrator. Not sure if these thoughts of mine match your scenario but hopefully they provide a useful hint or two.
SUMMARY
Reliable account linking is tricky, but it should be solvable via the building blocks of the Authorization Server, using the above techniques. The end result should be deterministic user data, with no duplicate users.
In our organization, we have been inviting guest users to our AAD Tenant to successfully share resources with our B2B partners. However, we have a fear that there may be some business users that have been oversharing with individuals (e.g. xxx#gmail.com accounts or Business accounts we don't approve of).
We would like to better monitor these scenarios, and I've been able to determine a user's source via the Azure Portal:
Here, we can easily see that this particular user is coming from an External Azure Active Directory.
Is there a Microsoft Graph API or Azure AD API where I can get this information, so we can write some automation around this? Also, is there a way to determine which tenant this user is homed in? I have played around with the Users endpoint a bit, but don't see this information...maybe there is a different endpoint or permissions scope that I need?
Thanks for any assistance!
You cannot get tenant information of a guest user, but we can handle users by domain the user belongs to. you can allow or block invitations to B2B users from specific organizations .Please refer to this document.
I am doing login from Azure AD.Client is SPA(angular using MSAL). If user is not Authenticated, it redirect to Microsoft Login Screen (using MSAL). On successful login, it return an access token.
My roles will be stored in a database. I need to add the roles of that user as part of claim in access token. I am not finding the way to do it.
I do not want to make another call from SPA to API to get the DB roles.
Please suggest some good approach.
Any links explaining the approach will also be very helpful.
I am still in design phase but not able to find the best approach.
In one microsoft site, i found that we can fetch the roles from DB but details were not there.
most of the places, it is written that we need to provide roles in Azure AD users menifest file.
In regular Azure AD, the "roles" claim is exclusively sourced from app role assignments for the signed-in user (or groups the user is a member of), to the app roles for the app the user is signing in to.
There's no feature currently in Azure AD which will connect to an arbitrary database, make a database query in the appropriate form, and include the results in the roles claim in the resulting ID Token.
I can think of three options to achieve your scenario:
After sign-in, call an API to retrieve the roles. Though you mention this is not desirable, it's probably the simplest approach, so it's worth listing. As a result of the user's sign-to you app, you app will usually obtain an access token to an API. If you set up your API to be secured with Azure AD (directly, or through Azure API Management), your SPA could simply get the necessary access token as part of sign-in, and at that point it's trivial to make a REST call to retrieve the role details for the user (and possibly other information useful to rendering your app).
Synchronize (or copy) your role information from your database to Azure AD. For each role, create an app role in the Azure AD app registration. For each user-role association, either create an app role assignment to directly assign the user (user -> app role), or assign a group to the app role and add the user to the group (user -> group -> app role. Keeping this in sync is probably not trivial, so if your scenario allow to move the role information to Azure AD app role assignment, you can forget the database entirely (making Azure AD the authoritative location). Of course, this might not work for your specific case.
Use Azure AD B2C and a custom sign-in policy. You could create an Azure AD B2C tenant, set up a custom sign-in policy to use your (regular) Azure AD tenant as the identity provider, and configure the policy to enhance the claims by calling a REST API to retrieve your roles. In this approach, you still need to have a REST API which can provide the role information, so rather than doing the setup and migrating your app, you may prefer simply calling the API from your SPA (option 1, in this list).
I'm building a service where each user has a calendar, I want to sync users 365 calendar events into their calendar, the tricky part seems to be, that this should be done repeatable by background job on the server, to keep them in sync.
I feel like I've read a bible of documentation from Microsoft, but still gotten nowhere. I eventually stumbled upon this article https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds which allows a server to query the graph api, on behalf of users. This is exactly what I want.
Having created a Azure account, and Active Directory service, I found that only users within the tenant can use this, which makes it rather useless, requiring to add users manually from azure panel.
AADSTS50020: User account 'm#****.com' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application 'c0193dea-5145-430a-9c90-325f1229a1fc' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
So I'm back at square one, how can I achieve what I described?
I'm not looking for a code implementation, merely a description of how to navigate the monstrosity of Microsoft.
Thank you
Update: Accordingly to Marc link. I tried to flick the multi tenant option, and change the endpoint to use common instead of tenant id. Sadly i'm still getting the same error.
You cannot sign-in to AAD with a non-AAD account using the v1 Endpoint. If you want to use a consumer Microsoft Account (#outlook.com, #hotmail.com, #live.com) then you need to use the Converged Auth model provided by the v2 Endpoint.
I have a walkthrough for the v2 Endpoint that you might find helpful: Microsoft v2 Endpoint Primer. It is similar to the v1 Endpoint but you'll need to register via https://apps.dev.microsoft.com rather than the Azure Portal. Also, v2 apps use Scopes instead of Resources and are multi-tenant out of the box.
This is a broad a question for Stack Overflow. That said, you're incorrect about Azure AD. It is absolutely not limited to a single-tenant. You do however need to register it as a multi-tenant application:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
In my application, a User is assigned multiple Roles, and a Role is assigned(granted) multiple Permissions.
So in my code, I never check against a Role, but always against a fine grained Permission.
Here is described why I think Permissions based access is better than Role based:
https://softwareengineering.stackexchange.com/a/299732
Within Azure AD, I can assign roles to a user.
But I see no way of creating Permissions and associate them to Roles, so I guess this part must stay in my app ?
Then how should I link the Azure Application Roles to my app's Permissions ?
My assumption is I need to build an UI for doing this, using the Graph API to retrieve the list of roles defined in Azure for the application.
If that is the case, then I don't see much benefits using the built-in roles function in Azure vs keeping the role definition in my app...
Am I missing something ?
The key point of using Azure AD claims is to keep users information in the Active Directory rather than in the application.
In you case, you need to create permissions mapped to roles in your application.
Then theses roles can be mapped to Azure AD AppRoles or Groups.
I suggest you not to map directly users to roles.
If you deals with Group, you don't need to add/remove users to/from applications: Roles and permissions are inherited from groups users belong to.
Mapping directly to Groups
For the moment, it would be my preferred scenario. Users are assigned to groups and your customs roles are mapped to these groups.
When you create a new user, you just need to add it in some groups and there is no action required in your application (same things when you delete the user).
If you are not afraid of preview (and have an Azure AD Premium license), Azure Ad provides a way to dynamically assign users to group.
Just keep in mind that for the moment nested group memberships aren't currently supported.
So if a Group A is in Group B and Group B has some permissions in your application, Users from Group A will not have permission inherited from Group B.
Mapping Groups to application roles
This option seems to be an overkill because it requires one more step: Map Azure Ad Group to Azure Application Roles and Map theses roles to your custom roles.
You need to implement all this logic using the AAD Graph API and your UI will be more complex.
Only reason to use this option in your scenario is if you have a large directory with lots of groups and applications : If a user is in more than 200 groups so the Jwt token returned by the Azure AD will not contain the groups and you will have to query one more time the Azure AD to get the user groups (see).
In this scenario, it could make sense to map groups to application roles because when a user authenticates to an application, Azure Ad will always provides you the roles of the users (or the roles of the group that the user belong to)
you can find interesting code sample here:
active-directory-dotnet-graphapi-console.
At this point in time, Azure Active Directory application roles are meant primarily for the scenario where each user can only have one role and thise roles are mapped to a simple authorization model.
While it is technically possible to support multiple roles per user, that can only be managed via the Graph API and would require you to build a UI for your user admin / users to manage.
As you've noted, your scenario is more complex than this with multiple roles per user and multiple (potentially customizeable and overlapping) set of permissions.
Given these two points, your approach of implementing all of the authorization yourself is a sound one.
Check out this article which outlines in more details the authorization scenarios Azure AD is best suited for:
https://azure.microsoft.com/en-us/documentation/articles/guidance-multitenant-identity-app-roles/