Activities of "smastro"

Hi,

I've configured OpenID Connect in the appsettings.json, I've my app service registered with Azure Active Directory (AAD from now on) and when I try to sign in using OpenID I'm facing the problem I describe below. I'd like to comment that I'm not necessarily suggesting that there's something wrong in ASP.NET Zero, but it could be the case that due to the sum of different conditions, the integration isn't working as it should.

Could anyone suggest a possible solution to this problem please? I've not been yet able to manage to use Azure AD to sign in even once. Any help would be appreciated!! Thanks.

Description of the problem:

I'm using ver. 6.9.0, template is Angular + ASP.NET Core, openid is as follows:

    "OpenId": {
      "IsEnabled": "true",
      "ClientId": "xxxxx",
      "Authority": "https://login.microsoftonline.com/{tentantID}/v2.0", //<-- v2 endpoint
      //"Authority": "https://login.microsoftonline.com/{tentantID}",      //<-- v1 endpoint
      "LoginUrl": "https://login.microsoftonline.com/{tentantID}/oauth2/v2.0/authorize", //<-- v2 endpoint
      //"LoginUrl": "https://login.microsoftonline.com/{tentantID}/oauth2/authorize", //<-- v1 endpoint
      "ValidateIssuer": "false"
    }

(You'll see why I have 2 Authority and LoginUrl values in a second)

[Problem #1]

1. When I use AAD's v1.0 endpoint I get an excpetion thrown in the browser by Angular's OIDC library, complaining about a "Wrong Issuer" (even though "validateIssuer" is set to false in appsettings.json.

I've narrowed down the problem to Angular's angular-oauth2-oidc.js file which is trying to compare the "authority" endpoint against the issuer reported by the OpenID Connect response. For some reason Azure is returning a issuer which doesn't match the "authority" endpoint who served the response. It returns this https://sts.windows.net/{tenantID}/ that clearly doesn't match this https://login.microsoftonline.com/{tentantID}

Now, this issue or incompatibliity between Angular and Azure seems to be somewhat known, since I've found this issue here which would address the problem, unfortunately the solution implemented by @ismailcagdas here has not been adopted by Angular (the file angular-oauth2-oidc.js in my system doesn't have that the skipIssuerCheck implemented).

[Problem #2]

2. When I use AAD's v2.0 endpoint, I get a totally different problem. This time around, the issuer seems to match the endpoint's URI in the ID_token returned by the endpoint, but apparently ASP.NET Zero is expecting some claims that are not sent in the response.

• The logs show this:

System.InvalidOperationException: Sequence contains no matching element
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source, Func`2 predicate)
   at Abp.AspNetZeroCore.Web.Authentication.External.OpenIdConnect.OpenIdConnectAuthProviderApi.GetUserInfo(String token)
   at {MyApp}.Web.Controllers.TokenAuthController.GetExternalUserInfo(ExternalAuthenticateModel model) in {PathToRepo}\aspnet-core\src\{MyApp}.Web.Core\Controllers\TokenAuthController.cs:line 455

• I don't have acces to that code since Abp.AspNetZeroCore.Web it's not shared, but it seems it's expecting some claims that Azure isn't sending.

• A quick inspection at the 2 JWT (from v1 and v2) shows there are a number of different claims that are gone, in particular, claims that expose user info such as "name", "upn", "unique_name" and many others.

• Inspecting MS docs, I've found here that they are no longer sending user info unless you add more scopes into the request: i.e., sending scope=openid won't expose user data unless you also pass email and/or profile as part of the scope (scope=openid email profile).

  Historically, the most basic OpenID Connect sign-in flow with Microsoft identity platform would provide a lot of information about the user in the resulting id_token. The claims in an id_token can include the user's name, preferred username, email address, object ID, and more. The information that the openid scope affords your app access to is now restricted. The openid scope will only allow your app to sign in the user and receive an app-specific identifier for the user. If you want to get personal data about the user in your app, your app needs to request additional permissions from the user. Two new scopes, email and profile, will allow you to request additional permissions.

• I tried editing getOpenIdConnectConfig function @ \angular\src\account\login\login.service.ts changing the scope to include those mentioned above. Azure's response's JWT indeed then added more claims with user data, however I'm still getting the same exception from ASP.NET Zero (System.InvalidOperationException: Sequence contains no matching element).

• My guess is that ASP.NET Zero expects to use a claim that is no longer sent?

Here's a comparison of JWT's payload section in v1 and v2 (with additional scopes added email and profile), see how some claims are clearly missing, notably unique_name, upn, onprem_sid, ipaddr, and so on... Chances are the code in Abp.AspNetZeroCore.Web is indeed using some of those...

v1.0 Endpoint

{
  "aud": "xxx",
  "iss": "https://sts.windows.net/xxx/",
  "iat": 1556648537,
  "nbf": 1556648537,
  "exp": 1556652437,
  "aio": "AVQAq/8LAAAAzBDj8fFwe5p6kX2H3iQuUjcUekgRffW3vuhyQRN+OQy/mE3/375D+Br2JjBS3PI3dq4n9cE5skVWPmvrsPcKhCXptXCvPrbe/QFddA1ITTI=",
  "amr": [
    "pwd",
    "mfa"
  ],
  "family_name": "xxx",
  "given_name": "xxx",
  "ipaddr": "xxx",
  "name": "xxx",
  "nonce": "jeM5nmDS4zVlgXxG7Qs9TfJavI9OQKeXt1qKsbqD",
  "oid": "xxx",
  "onprem_sid": "xxx",
  "sub": "xxx",
  "tid": "xxx",
  "unique_name": "xxx",
  "upn": "xxx",
  "uti": "xq4QV7nQF0iDJMNr3x8dAA",
  "ver": "1.0"
}

v2.0 Endpoint

{
  "aud": "xxx",
  "iss": "https://login.microsoftonline.com/xxx/v2.0",
  "iat": 1556763507,
  "nbf": 1556763507,
  "exp": 1556767407,
  "aio": "AWQAm/8LAAAA+byyv8Tt3NU1c15gP5GHPSXvkw3ocbo5wS7VBZ4aPiA8esCXtyZyo8LCWpcEhSq54ChVXG5Mi/lef9A2SoCS71JDYkkLcN+0M17ETe5YKzJOFvfJwBSFwWXyhBJ6rpvx",
  "email": "xxx",
  "name": "",
  "nonce": "AQt91n5tSBS1Kl74efN85l90Zga8FRfLVw84TSSu",
  "oid": "xxx",
  "preferred_username": "xxx",
  "sub": "xxx",
  "tid": "xxx",
  "uti": "cSlHfCfDg0Kg3bvx2iM8AA",
  "ver": "2.0"
}

Thanks!

Thanks!

Sorry, but not entirely a duplicate, since nobody else seems to be complaining about Unit Tests .

We acknowledge we can prevent the application from crashing by running it once with MultiTenancyEnabled = true and then turning it off, however, that doesn't help fixing all UnitTests which would still fail.

The workaround suggested above works but all Unit Tests still fail when you set MultiTenancyEnabled = false.

I added a few more details on #6857

The workaround works, but just to avoid the crash on initial the intial run. All Unit Tests still fail when you set MultiTenancyEnabled = false.

I added a few more details on #6857

Hello, we are experiencing a few problems we believe are the consequence of a bug somewhere in the code. Please find details of the issues below.

Should I report this as a bug in GitHub? Any help would be appreciated. Thanks in advance!

Please see below:

1. Upon first generating a new solution (MVC Core + Angular, on version 6.9.0.0) we disabled MultiTenancy

public const bool MultiTenancyEnabled = false;

and we then ran the applicaiton, we get the following error:

Note: The only change we made was altering the connection string to use LocalDB for testing purposes. Other than that, it's unaltered code.

2. We noticed almost all Unit Tests fail, and the Stack Trace show the same piece of code is executed (and fails).