Fix SAML auth context handling for IAL2 strict request

[aduth]

Why: So that an IAL2 strict request behaves similar to a standard IAL2 request, particularly in how a user should be directed to enter their password to decrypt PII if encrypted.

Discovered in #6229, via failing feature specs where user would not be prompted to enter their password to decrypt profile when authenticating as IAL2 strict.

[aduth]

Discovered in #6229, via failing feature specs where user would not be prompted to enter their password to decrypt profile when authenticating as IAL2 strict.

For example, you can see the issue by checking out the changes of #6255 against the current main.

git checkout main
git checkout 1b3b5d45a02d31f56fb042b083b1411f03b1d1db -- spec
rspec ./spec/features/reports/authorization_count_spec.rb:162
#     Capybara::ElementNotFound:
#       Unable to find field "Password" that is not disabled

[solipet]

Great catch!

[solipet]

nice.

[aduth]

I discovered an additional, similar issue with how we're not upgrading IAL1 accounts to IAL2 for IAL2 strict requests, but I filed this as a separate bug, since the changes here are sufficient to unblock me in #6229.

See: LG-6217

[aduth]

@solipet , I pushed a minor revision in 3cd0288 to revert the IAL2 authns' constant to its original value, and instead check explicitly for IAL2 strict when considering requested attributes. While I sorta like the idea of disambiguating "IAL2" and "IAL2 strict", we don't have a tendency of doing that anywhere else, so this feels more in line with what we're usually doing when checking for IAL2 or IAL2 strict.

Could you give it a quick look and let me know if this makes sense to you?

[solipet]

I agree with your decision to avoid messing with the current definition of IAL2 authn contexts.