Activities of "gterdem"

Hello @MarekH,

The sample you shared is not a microservice template. It is a tiered application. You can check microservice docs about abp microservice template.

In this concept, your question is not related with microservices.

We have tried it with using IdentityUser insted of AppUser , But still we are not able to access any repoostories. As mentioned above we have a API Project Name : Microservice , We are trying to access database of tenant to perform CRUD Opration from the same project.

Issue: We are not able to switch or access any reporsitories in that Project

I have created a DEMO Project with the Microservice Project (In which we would like to access tenant database and perform CRUD oprations).

The solution you have provided is a tiered application and has an extra api project named Microservice. So you have 3 different web applications:

• FD.Demo.HttpApi.Host (supplied by template)
• FD.Demo.IdentityServer (supplied by template)
• FD.Microservice (your additional project)

You are not trying to perform CRUD operations in the same projects, they are all diferent projects. You are just using the same solution. That is the big difference you may be missing out.

Again, this is a concept of distributed systems: You may have different applications signing in to same IdentityServer and applications communicate each other via using the token they get from identity server.

It doesn't matter if you put them in same solution or not.

ok, i have published success. it need to change identity config in UI. I think you can add the publish guide in abp document. Thanks.

It will be a wrong information to change identity config in UI. It is Identity Server Management page, not Identity Management.

IdentityServer related data is saved in database, either you provide it in the Identity Server Management UI or IdentityServer DataSeeder.

It seems you forgot to change the db migrator appsettings.json to seed the data in the first place.

This will be implemented for both sides, you can follow from https://github.com/abpframework/abp/issues/9132. It will be fixed in next patch.

This is a misleading error. It should redirect to a User Not Allowed or Locked page since ExternalLoginSignInAsync returns NotAllowed. We'll fix it after deciding how to handle it. It will either be adding a Locked Out Page or throwing a user friendly error.

If it is urgent for you, you can handle it as you like by overriding Login page and OnGetExternalLoginCallbackAsync method.

<br>

[UnitOfWork]
public override async Task<IActionResult> OnGetExternalLoginCallbackAsync(string returnUrl = "",
    string returnUrlHash = "", string remoteError = null)
{
    ... //Omitted

    var result = await SignInManager.ExternalLoginSignInAsync(
        loginInfo.LoginProvider,
        loginInfo.ProviderKey,
        isPersistent: true,
        bypassTwoFactor: true
    );

    if (!result.Succeeded)
    {
        await IdentitySecurityLogManager.SaveAsync(new IdentitySecurityLogContext
        {
            Identity = IdentitySecurityLogIdentityConsts.IdentityExternal,
            Action = "Login" + result
        });
    }

    if (result.IsLockedOut)
    {
        throw new UserFriendlyException("Cannot proceed because user is locked out!");
    }

    // The 'NotAllowed' status occurs if the user exists in the system, but is not enabled
    if (result.IsNotAllowed)
    {
        Logger.LogWarning($"External login callback error: User is Not Allowed!");
        // Returns a view informing the user about the locked account
        // return RedirectToAction(nameof(Lockout));
        // Or throw error
        // throw new UserFriendlyException("Cannot proceed because user is locked out!");
    }

    if (result.Succeeded)
    {
        var user = await UserManager.FindByLoginAsync(loginInfo.LoginProvider, loginInfo.ProviderKey);
        if (IsLinkLogin)
        {
            using (CurrentPrincipalAccessor.Change(await SignInManager.CreateUserPrincipalAsync(user)))
            {
                await IdentityLinkUserAppService.LinkAsync(new LinkUserInput
                {
                    UserId = LinkUserId.Value,
                    TenantId = LinkTenantId,
                    Token = LinkToken
                });
            }
        }

        await IdentitySecurityLogManager.SaveAsync(new IdentitySecurityLogContext
        {
            Identity = IdentitySecurityLogIdentityConsts.IdentityExternal,
            Action = result.ToIdentitySecurityLogAction(),
            UserName = user.UserName
        });

        return RedirectSafely(returnUrl, returnUrlHash);
    }

   ... //Omitted

    return RedirectSafely(returnUrl, returnUrlHash);
}

The error you get is about healthcheck. Try disabling it to see how it goes: <br>

public override void ConfigureServices(ServiceConfigurationContext context)
{
    var configuration = context.Services.GetConfiguration();
    var hostingEnvironment = context.Services.GetHostingEnvironment();

    ... //Omitted
    //ConfigureHealthChecks(context); //Comment this line 
}

<br> If your problem persists, try deleting the database and use configurations as below.

For development, we are using localhost with port. You are using local ip without port for angular app. I think IIS Express redirects to port 80 as default. Nevertheless, I would suggest using explicit port for angular app also.

Your backend url is https://192.168.1.175:8008 Your frontend url should be with port https://192.168.1.175:8080 (or whatever port you like)

Backend appsettings:

<br>

"App": {
  "SelfUrl": "https://192.168.1.175:8008",
  "AngularUrl": "https://192.168.1.175:8080",
  "CorsOrigins": "https://192.168.1.175:8080",
  "RedirectAllowedUrls": "https://192.168.1.175:8080," 
},

RedirectURLs and CorsOrigins are related with your angular app (since you don't use separate identityserver)

FrontEnd environment.ts

const baseUrl = 'https://192.168.1.175:8080';
export const environment = {
  production: false,
  application: {
    baseUrl,
    name: 'eCTDBackend',
  },
  oAuthConfig: {
    issuer: 'https://192.168.1.175:8008',
    redirectUri: baseUrl,
    clientId: 'eCTDBackend_App',
    responseType: 'code',
    scope: 'offline_access openid profile role email phone eCTDBackend_App',
  },
  apis: {
    default: {
      url: 'https://192.168.1.175:8008',
      rootNamespace: 'Area51.eCTDBackend',
    },
  },
} as Environment;

I guess it is enterprise feature since i couldn't find any group management or related claim management in my personal azure account. Since it is not related with ABP, you can find better answers asking this question in stackoverflow. It should help better about Azure Active Directory specific questions.

But logic should be adding the scope to application in Azure Portal application management and requesting the scope here in openid connection configuration: <br>

.AddOpenIdConnect("AzureOpenId", "Azure AD OpenId", options =>
{
    options.Authority = "[https://login.microsoftonline.com/](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 = false;
    options.GetClaimsFromUserInfoEndpoint = true;
    options.Scope.Add("email");
    options.Scope.Add(ClaimTypes.Groups); //Whatever the claim is

    options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub");

    options.Events.OnTokenValidated = async ctx =>    {
        var claimsFromOidcProvider = ctx.Principal?.Claims.ToList();
        // check here for returned claims
        await Task.CompletedTask;
    };
});

Check the logs, if you come across any error. It will be either the scope you requested in openid configuration is invalid (invalid_scope) or the scope you request is not allowed for the application (that you need to fix in Azure portal).

Check adding custom claims to current user question about how to add newly acquired claim.

@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.

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.

As far as I understand, you have some misconfiguration for microservices:

Infrastructural Microservices:

AdministrationService: If you want to have Sql-Server db, must have AdministrationService.EntityFrameworkCore project with a sql-server connection string which is default when you download template. IdentityService: If you want to have Sql-Server db, must have IdentityService.EntityFrameworkCore project with a sql-server connection string which is default when you download template. SaasService: If you want to have Sql-Server db, must have SaasService.EntityFrameworkCore project with a sql-server connection string which is default when you download template.

If you want to change infrastructural microservice databases, you need to create a new .MongoDB project and replace it with .EntityFrameworkCore project with required module mongodb references.

New Microservice:

CompanyService : If you want to use MongoDB, must have CompanyService.MongoDB project with a mongodb connection string like mongodb://localhost:27017/ZW_CompanyService.

Same as here, create a new CompanyService.MongoDB (or whatever you want to name it) and update connection strings. Check database-migrations docs for more information.

If you have checked the infrastructure docs;

• Sql-Server
• Redis
• Rabbit-MQ

are the required infrastructure services as default. If you are using local Sql-Server (not docker), you need to update all your connection strings.

I executed database migrations with local SQL Express (not docker) and created all databases successfully.

If you used DbMigrator to create and seed the databases, use the same connection string in services Api.Host as well. If you are trying to run services on container and connect to out-of-docker sql-server express, that's requires totally different configuration. Also, if you are using local sql-server, why not using Trusted_Connection something like: Server=localhost;Database=ABPMSTemplate_Administration;Trusted_Connection=True

This is a SQL Connection Error and doesn't related with anything other than your connection string and sql-server.