Disable ADAL cache

[pmaytak]

Issue #1770

• Measure improvement (start with baseline and explore improvements for a small and large cache sizes)
• Flag to disable ADAL cache fallback (.WithDisableAdalCache - suggestions welcome)

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i7-9850H CPU 2.60GHz, 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=5.0.101
  [Host]                      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Job-GetAllAccessTokensTests : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT

Job=Job-GetAllAccessTokensTests  

Method	Cache Size	ADAL Cache Enabled	Mean	Error	StdDev	Median
SaveToken	1	False	114.627 μs	5.0409 μs	14.3002 μs	110.700 μs
SaveToken	1	True	254.866 μs	15.1876 μs	43.0847 μs	249.400 μs
SaveToken	100	False	125.229 μs	7.9097 μs	22.8214 μs	117.900 μs
SaveToken	100	True	3,839.003 μs	426.3727 μs	1,250.4775 μs	3,531.600 μs
SaveToken	1000	False	311.947 μs	46.2354 μs	130.4077 μs	290.300 μs
SaveToken	1000	True	19,656.353 μs	1,146.5410 μs	3,233.8394 μs	18,760.100 μs
FindToken	1	False	6.064 μs	0.0728 μs	0.0681 μs	6.036 μs
FindToken	1	True	25.042 μs	0.2029 μs	0.1799 μs	25.029 μs
FindToken	100	False	292.248 μs	5.0886 μs	4.7599 μs	291.118 μs
FindToken	100	True	1,247.194 μs	13.2774 μs	12.4197 μs	1,244.227 μs
FindToken	1000	False	2,918.332 μs	29.1596 μs	25.8492 μs	2,916.822 μs
FindToken	1000	True	13,160.303 μs	68.0861 μs	56.8550 μs	13,175.005 μs
GetAllUsers	1	False	4.115 μs	0.0369 μs	0.0308 μs	4.122 μs
GetAllUsers	1	True	26.792 μs	0.3861 μs	0.3611 μs	26.760 μs
GetAllUsers	100	False	21.667 μs	0.3096 μs	0.2896 μs	21.775 μs
GetAllUsers	100	True	1,034.691 μs	5.3541 μs	5.0082 μs	1,033.355 μs
GetAllUsers	1000	False	176.886 μs	1.6854 μs	1.5765 μs	176.577 μs
GetAllUsers	1000	True	12,433.904 μs	247.6150 μs	433.6777 μs	12,483.295 μs
RemoveUser	1	False	1.033 μs	0.0075 μs	0.0062 μs	1.035 μs
RemoveUser	1	True	2.185 μs	0.0384 μs	0.0341 μs	2.192 μs
RemoveUser	100	False	5.625 μs	0.0164 μs	0.0137 μs	5.621 μs
RemoveUser	100	True	6.830 μs	0.0394 μs	0.0307 μs	6.838 μs
RemoveUser	1000	False	48.304 μs	0.9617 μs	0.9876 μs	48.550 μs
RemoveUser	1000	True	48.664 μs	0.9403 μs	0.9235 μs	48.667 μs

[jmprieur]

I've left a few suggestions.

(jus so that we remember): We need to understand (and demonstrate) the impact on the https://github.com/Azure-Samples/active-directory-dotnet-v1-to-v2/tree/master/TokenCacheMigration sample

[bgavrilMS]

Looks good so far, I think you should look at the auto-detection separately, as it is out of scope for this work item. Unit tests + a perf tests would be a better next step.

[jmprieur]

@pmaytak : could we please have an estimate of the performance gain (before the fix, and after the idea of the fix) ?
We probably want to understand if this is worth it?

[pmaytak]

@bgavrilMS @jmprieur Thanks for the suggestions; I'll work on a perf assessment.

[pmaytak]

@henrik-me @jmprieur @bgavrilMS @jennyf19
I added the test results above for four methods that access the legacy cache (for different cache sizes and with enabled and disabled legacy cache). Seems like there's improvement even if cache has only one item.

[pmaytak]

Note: Just moved these helper methods to LegacyTokenCacheHelper for ease of access.

[pmaytak]

Ready for review for the first two bullet points.
The telemetry and auto detection can be added in the next PRs.

[jmprieur]

Thanks @pmaytak
I've proposed an improvement for the XML comment of the new API.

[jennyf19]

Is there a reason to have this exposed only in the confidential client application options? As it's more of a confidential client issue. Also, i'm a little concerned about discoverability of this, and it can only be used w/MSAL only applications. Any applications that might share w/ADAL should not use this, would there be a risk of losing the cache? Do we have an internal partner or customer that we can have try this out? From my understanding, first party customers tend to try in MSAL first, and then fall back to ADAL if the call fails, so they might have to use the ADAL cache. Do we have a customer who has complained about the ADAL cache lookup?

side note, not a fan of having "ADAL" in the MSAL public API, just like we were told not to have B2C, ADAL seems even worse as it's being deprecated. As a new customer, I wouldn't understand why i would need this or not (what is ADAL?). Maybe auto-detection is better?

---

In reply to: 754546278 [](ancestors = 754546278)

[pmaytak]

Is there a reason to have this exposed only in the confidential client application options? As it's more of a confidential client issue. Also, i'm a little concerned about discoverability of this, and it can only be used w/MSAL only applications. Any applications that might share w/ADAL should not use this, would there be a risk of losing the cache? Do we have an internal partner or customer that we can have try this out? From my understanding, first party customers tend to try in MSAL first, and then fall back to ADAL if the call fails, so they might have to use the ADAL cache. Do we have a customer who has complained about the ADAL cache lookup?

side note, not a fan of having "ADAL" in the MSAL public API, just like we were told not to have B2C, ADAL seems even worse as it's being deprecated. As a new customer, I wouldn't understand why i would need this or not (what is ADAL?). Maybe auto-detection is better?

@henrik-me @bgavrilMS What's you opinion on Jenny's 3 points above?

As far as the renaming, I could change it to WithLegacyCacheCompatiblity and just mention ADAL in the XML comment.

[henrik-me]

@peter did you explore the impact on the cache compat tests JM pointed out?

The concern is if we disable this functionality by default how many are going to be impacted, if it's opt in then none. I was considering we should auto detect to opt. out of this, however people should be able to opt. out of disabling. The only otherway to validate this would be to start adding telemetry and let us measure how many really still need this. I would think that there might be a few for public client applications in migration scenarios (thus though could have a way to opt out of the behavior change in case our auto detection doesn't work) but I don't see a need for this in confidential client applications. Typically the fallback to ADAL there is to a completely different cache as it's a completely different library. I think this change is safe on confidential client, and that is also where we need it the most. We can start by making this confidential client only.

---

In reply to: 755112571 [](ancestors = 755112571)

[henrik-me]

@pmaytak : having discussed the overall impact of implementing auto detection with @jmprieur, we suggest to not implement that at all. this feature should be opt. in and we will find other ways to encourage customers to opt.in. This means regardless of scenario it should only be disabled if a customer has opted in.

[henrik-me]

[bgavrilMS]

Oh wow, I just saw the numbers. These are super impressive. We should really disable ADAL by default.

[henrik-me]

+1: to disable for confidential client asap (though we already discussed this... telemetry would help).
@jmprieur @jennyf19 ... perhaps we can do this in id.web?

[jmprieur]

@henrik-me @jennyf19 : AzureAD/microsoft-identity-web#961

[bgavrilMS]

My thought for automatic detection of ADAL usage is:

• if after saving tokens to the cache (all AcquireToken* operations do this), you do not use SerializeAdal / DeserializeAdal methods, then we disable ADAL caching because it's just in-memory.
• in a migration sceanrio, where app A uses ADAL cache and app B uses ADAL + MSAL cache, app B should read / write at least one to the ADAL cache.