I have an existing IdentityServer4 installation that is used to federate users between things like Google & Microsoft into a single login identity. In my situation, there are no local user credentials/passwords. Just the identity with an associated external provider. I'm trying to migrate to using Azure B2C and am hitting some roadblocks.
I've found that if I use the same ClientId and ClientSecret that IdentityServer is configured with, then I get the same IDs for users when signing in via an external identity provider. Which is great because I need them to be the same in order to try and migrate accounts over by reading them from the existing MSSQL database, and importing into Azure B2C using MS Graph.
I need to allow both Microsoft work accounts, as well as personal ones. So I need to use custom policies to allow for a multi-tenant configuration, since the built in provider doesn't support this.
However as soon as I flip my implementation over from the built in user flows and provider, to using custom policies, I don't get the expected issuerAssignedId anymore. Originally, the IDs looked something like AAAAAAAAAAAAAAAAAAAAAHGFdaj94jfdsgjifdh4ngd (made up, but you get the idea). Now with the custom policies, the issuerAssignedId being recorded in the B2C user looks like a GUID. So not just a different value, but a total different format. Am I missing something here? What would happen if someone has an fully operational AzureB2C install with built in functionality, and later identified a need to move to custom policies. How would users ever be able to look into their existing accounts with an external identity provider?
My TechnicalProfile for the multi-tenant sign is is essentially copy/pasted from their documentation, so I'm not sure what the deal is here?
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.
I have been able to set up Azure AD Authentication with Auth0. According to my research, Azure AD is similar to AWS Cognito and Firebase. So can we use Azure AD to handle flows like User Creation, Password Reset, Expire Password etc. from a NodeJS Admin Backend?
Azure Ad is microsoft's identity platform. while yes in some ways is similar to aws cognito, it is a bit different as well. it's not designed specifically for developers, it's designed as an identity platform for your organization.
to answer your second question, it really depends on what you are expecting it to do. For example, there is an api, called graph api, which lets you interact and do almost everything you want to azure ad through that api. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-graph-api create users, groups etcetc. but if you are looking for user signup using their own emails and that sort of thing, the closest thing you should be looking at is Azure Ad B2C.
Azure B2c Takes care of some of the more common scenarios like signups and such
https://azure.microsoft.com/en-us/services/active-directory/external-identities/b2c/
I'm currently trying to configure Azure Ad for user provisioning in a Salesforce Sandbox. I'm using a personal dev org and a trial Azure account to make this work.
I've been able to map attributes and it works for most of them, except one. ManagerID.
I'm trying to replicate the Azure AD manager information into Salesforce's managerID field using an attribute reference. However it doesn't seem to work.
Has anyone here been completing this kind of setup previously and would be able to point me to the correct Attribute expression to be mapped/referenced on the Azure AD side?
The default mapping is from Salesforce->ManagerId to AAD->Manager, where AAD-> Manager is a reference to User.
The field in Salesforce used for matching is the FederationIdentifier, which corresponds to AAD-> User.userPrincipalName
The logic would be that if I'm doing a reference to the AAD User, I would expect AAD to fetch that manager's UPN in AAD and pass it back to the SCIM interface to be able to match it on the Salesforce side (since it's mapped to the FederationIdentifier).
I'm also trying to force the reference of "Manager" on the AAD side to pick the User.UserPrincipalName but it seems to always bring it back to User.
Anyhow, I'm a bit fishing here and wondering if there is someone with whom I can share the settings in such way that I can compare how it's been done in a successful implementation.
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
My current setup is a fairly simple one. I am running Identity Server 3 which is used to provide oauth access tokens which can be used against and a number of our web api endpoints. The identity server has custom user service which authenticates requests against a custom user table in our sql database.
We have a new 3rd party software provider, this provider requires that our users (staff in our call centre) logon to their application via a proprietary login, not against our existing user accounts. We have built an api for this 3rd party which they required for their integration, as with the rest of our api's this is secured using oauth bearer tokens via identity server.
Our staff are all locally logged on to an active directory domain. Is it possible to configure identity server to issues auth tokens for a user who is already authenticated against active directory? I like to achieve this without prompting the user for their credentials again.
I've read around and at this point I'm very lost as to the correct approach, some form of federation seems appropriate, but I couldn’t find a reasonable introduction / walkthrough to help me get started.
What is an appropriate approach and are they any relatively easy to consume primers on the subject?
Yes, you should be able to make it work. The samples contain a windows auth provider. Using this, your identity server would authenticate people in without prompting for a password. Once authenticated, it would then issue tokens same as any other auth. You may need to a bit of experimenting to get it working, but from what you've said it should work in your situation.