时间戳

首页 > 解决方案 > using third-party identity provider with Azure AD and MSAL.js

oauth-2.0 - using third-party identity provider with Azure AD and MSAL.js

问题描述

I have created a Single Page Application with Angular and authentication/authorisation is managed by Azure AD. I have used MSAL.js to initiate the implicit flow.

Everything is working fine, but now my client wants to use her own identity provider (IDP) so that users have a single point of entry for all apps (including mine). This IDP is not mainstream, it is built in-house by the client;

I want to keep using Azure AD to manage authorisations (groups, roles...). I also want my application and its dedicated backend API to be registered in Azure AD, not in the third-party IDP. Azure AD should remain responsible for providing the Access Token to the SPA in order to call the API.

Somehow, I should redirect the user to the third-party IDP login form and upon successful login it will redirect to my SPA, which should then associate the tokenID with an AzureAD account and retrieve the Access Token (I suppose I will have to create an account in Azure AD for users identified in the third-party provider)

However I'm having a hard time figuring out how to achieve this and if it is at all possible ?

What would be the recommended approach for this scenario ? Can I still use MSAL.js or do I have to rely on something else ?

标签： oauth-2.0azure-active-directoryopenid-connectazure-ad-b2cmsal.js

解决方案

ARCHITECTURE

Your goals are completely correct and you should not need to change a single line of code to integrate a new IDP - so you can continue to use MSAL.js.

PREREQUISITES

In order to integrate their own IDP into your system you need to insist on certain prerequisites:

  • The client needs to provide a Standards Compliant Identity Provider
  • Typically the IDP needs to communicate with your Authorization Server (Azure AD) via either Open Id Connect messages or SAML2P messages

A home grown IDP may not meet these prerequisites in which case you need to explain to the client that they need to get standards compliant.

HOW FEDERATION WORKS

  • Your UI will redirect to your AS
  • The AS will redirect to the IDP, when given a trigger
  • The user will authenticate in the IDP
  • The IDP will post a token to your AS to identify the user
  • The AS will issue another token to your UI

Note that there is no coding involved here - there is only standards based integration between vendor systems.

WHAT THE CLIENT WILL GIVE YOU

Client details are often supplied by giving you their metadata document, and these details are then configured in Azure AD as a trust entry:

  • The entity id of the IDP
  • The token signing public key for IDP tokens, so that your AS can validate them
  • A URL to redirect to

WHAT YOU WILL GIVE THE CLIENT

A similar trust entry will need to be configured in the client IDP so that it trusts requests and issues tokens - though no certificate is usually needed here:

  • The entity id of the AS
  • A URL to post tokens to

TRIGGERING THE REDIRECT FROM THE AS TO THE IDP

One option is to forward the entity id to the authorization server in Open Id Connect redirects. Often an 'idp' query parameter is used, something like this:

Client accesses your app with a bookmarked URL:

You add an extra parameter to the Open Id connect redirect to tell it where authentication should happen:

AZURE AD SPECIFICS

Once you understand the high level process there is some technical stuff to configure the connection and you'll need to consult vendor documentation, such as this Microsoft Azure B2B article.

PRACTICE

If you haven't done this before then you need to invest some time to get a connection working and then document the process.

You can use Windows Server and ADFS to simulate a client connection, then integrate it as a SAML2P connection. There is a learning curve though, and you'll need infrastructure such as ADFS certificates.

推荐阅读