Azure AD Configuration and Login Issues + Angular #1291

6 Answer(s)

• 

  0

  gterdem created 3 years ago

  Senior .NET Developer

  I have reproduced the problem. This indeed seems a behavior change.

  I will try to find out the source of this behavior change since Microsoft is making changes to authentication libraries on their side aswell. Here is the related blog post. If it is related with our side, we'll fix it as soon as possible.

  Save Cancel
• 

  0

  riley.trevillion created 3 years ago

  Hi @gterdem

  Thankyou for looking into this one and confirming the reproducability. Do you have any additional updates on the status / progress of your investigation and a potential way forward (bug fix / workaround / configuration) for resolving this one in the short term?

  We have a release planned in the next 1-2 weeks that was expected to include Azure AD integration for our clients. Depending on the complexity of the issue here and an ETA on a fix, my team may need the time period leading up to the release to figure something else out if Azure AD integration is not possible before the end of the month.

  Thankyou again for your help.

  Save Cancel
• 

  0

  gterdem created 3 years ago

  Senior .NET Developer

  @riley.trevillion <br>

  TLDR: Update OpenIdConnect configuration

  private void ConfigureExternalProviders(ServiceConfigurationContext context, IConfiguration configuration)
  {
      context.Services.AddAuthentication()
          ...
          .AddOpenIdConnect("AzureOpenId", "Azure AD OpenId", options =>        {
              options.Authority = "https://login.microsoftonline.com/" + configuration["AzureAd:TenantId"] +
                                  "/v2.0/";
              options.ClientId = configuration["AzureAd:ClientId"];
              options.ResponseType = OpenIdConnectResponseType.CodeIdToken;
              options.CallbackPath = configuration["AzureAd:CallbackPath"];
              options.ClientSecret = configuration["AzureAd:ClientSecret"];
              options.RequireHttpsMetadata = false;
              options.SaveTokens = true;
              options.GetClaimsFromUserInfoEndpoint = true;
              options.Scope.Add("email");
  
              options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub");
          });
  }
  

  <br>

  Remove static claim mapping

  Don't use JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();.

  Map sub claim manually

  Add options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub"); in your OpenIdConnect configuration

  Ensure AzureAD has email for user

  Since abp uses email claim for auto user registration, email field should not be empty. Otherwise you won't get an error but a page prompting to enter email At the end, sub claim should be mapped and you should have requested and recieved email claim Result:

  Stay tuned for article update.

  Save Cancel

  1
• 

  0

  riley.trevillion created 3 years ago

  Hi @gterdem

  I have been able to log in successfully with Azure AD on both the fresh copy of ABP and our existing solution using the new instructions you have provided. Thankyou!

  There is one fly in the ointment though, unfortunately. If you require users to confirm their email on login (ABP setting), attempting to log in again with the same Azure AD user results in a 'username is already taken' error. If you switch the setting off and users don't need to confirm their emails, the issue doesn't occur.

  Do you have any suggestions on how to resolve this one?

  

  Thankyou again.

  Save Cancel
• 

  0

  alper created 3 years ago

  Support Team Director

  closing the issue since the main defect has been resolved. you can create a new ticket for your new questiion. thank you

  Save Cancel
• 

  0

  riley.trevillion created 3 years ago

  Hi @alper

  I've created a new ticket here - https://support.abp.io/QA/Questions/1363/Azure-AD-'Username-Taken'-on-Subsequent-Logins

  Thankyou

  Save Cancel