Activities of "hra"

Hi @ismcagdas,

Thanks for responding. I kept digging and I actually figured it out. It was my fault.

I had adapted the Abp dbcontext conventions such that all changes within a UOW that are saved at the same time, will share the same timestamp. That's been working great for us, up until now, when I've started using the BackgroundJob infrastructure.

It appears to have effectively set the "CreationDate" and "TimeOfNextExecution" (I think thats the field name) to the exact same value. For some reason this makes the background worker process chase a date/time that never arrives (well, almost never - very unreliable). I have altered my UOW modification such that I only turn it on for UOW scopes that I need it, rather than across the board.

Thanks please consider closed.

Hi musa - it wasn't my code, but the admin portal. You are correct, it changed the DisplayName, not the Name.

Thanks

A supplement to @ismcagdas's workaround - he's also supplied some additional code - thanks:

protected virtual void FillClaimsFromJObject(ExternalAuthUserInfo userInfo, JObject payload) { var dict = new Dictionary<string, string>(); foreach (var item in payload) { dict.Add(item.Key,item.Value?.ToString()); } userInfo.Claims = dict; }

You can use the class MicrosoftAuthProviderApi in the TokenAuthController's (for angular project) ExternalAuthenticate method. Just check for (input.AuthProvider == "Microsoft") and if it is true, create a new instance of MicrosoftAuthProviderApi and get the user info from your custom class.

If you are using the MVC version of AspNet Zero, you can do it in AccountController.

Hi @ismcagdas,

I'm on version 10.0 of Core/Angular.

Whats the justification for using OpenID Conect vs Microsoft?

@ismcagdas - I'm pretty sure this is contributing to our issue here: https://support.aspnetzero.com/QA/Questions/10620/Setting-up-Microsoft-Azure-AD-Login

Where did this end up?

Hi @ismcagdas,

Thank you for your response.

I hear your point, however I would like to respectfully appeal that you reassess your position for the sake of the AspNetZero/Boilerplate platform. All things being equal, if both are strange behaviors, it would be far safer to err on the side of not leaking potentially sensitive data to unintended users/organisations.

At best, data could be moved from tenant to host, causing the effect I had, a customer noticing missing data. At worse, data could be moved to another tenant, causing leakage of potentially sensitive data outside of the organisation, exposing your customers to potential legal ramifications.

Should the user have intended the data to be moved to another tenant, this specific failure would be observed in feature testing - as it's an explicit feature rather than an edge case. We could mitigate this being overlooked by throwing an exception should the tenant change without the "block tenant changes guard/filter" being disabled - this would clearly highlight the violation in testing.

There is no impact on my organisation given I have caught this flaw and mitigated it, so I promote discussion on this topic for the benefit of my peers in this community. I feel this also reflects on AspNetZero's internal security strategy whether or not to err on the side of caution.

Thank you and best Regards,

Hi @payoff,

Thank you for your suggestion. This is exactly the kind of best-practice I was looking for.

Regards,

Hi @imscagdas,

I have created a PR in AspNetBoilerplate which fixes the issue for me. Please review.

UserManager and PermissionManager appear to use different techniques to determine the active MultiTenancySide - by copying across the UserManager technique to PermissionManager, it appears to resolve the issue.

Thanks and regards,

https://github.com/aspnetboilerplate/aspnetboilerplate/pull/6116

Hi, I have tracked down the issue.

After restarting the application server, and clicking "return to my account", all caches are empty - and the RoleManager will repopulate the cache with the admin user role permissions (role 1). The Role Manager calls "PermissionManager.GetAllPermissions(true)", and you can see that AbpSession still contains all the information for the impersonated account - rather than the impersonator account.

This fails to return the permissions on the Host side, and hence, a much smaller permission set (50, instead of 70-something) - but you can clearly see that this permission set is assigned in the cache to cacheKey "1@0".

This is what "GetAllPermissions" should look like...

Because these corrupt permissions are then stored in the cache, this explains why the application must be reset, or permissions changed (to trigger repopulation of the cache).

I guess the real question is - why is AbpSession still returning "MultiTenancySide == Tenant" after returning back to the Host account?

hi,

yes, that looks like the same issue I'm having. I also found those 2 actions (editing the user permissions, or recycling the application pool) were the only solutions.

Of course, neither are really acceptable for my production customers...

Is there some part of the authentication token/crypto that is generated on app-start? If so, it would explain why recycling the server breaks active session tokens - i.e, theyre not expired, but essentially become corrupted...

I can reproduce this issue consistently. I can share a screen recording with you (privately) if you wish.