Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: LG13235 consume eipp data from sinatra #10618

Merged
merged 11 commits into from
May 21, 2024

Conversation

KeithNava
Copy link
Contributor

Adding the ability to pull Enhanced IPP from the VTR parameter

馃帿 Ticket

Link to the relevant ticket:
LG-13235

馃洜 Summary of changes

Allow the application to recognize the Enhanced In Person Proofing flow coming from the Vector of Trust request (VTR) parameter by introducing a new value of Pe which represents the Enhanced Proofing component.

馃摐 Testing Plan

Most of the confirmation is done through the spec tests but the follow on ticket to actually enable the passing of the values from the Sinatra application would be the true end to end test -> https://cm-jira.usa.gov/browse/LG-12858

@KeithNava KeithNava requested review from a team and svalexander May 14, 2024 10:38
Copy link
Contributor

@JackRyan1989 JackRyan1989 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -38,6 +38,12 @@ module SupportedComponentValues
implied_component_values: [P1],
requirements: [:biometric_comparison],
).freeze
Pe = ComponentValue.new(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does Pe mean here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Proofing Enhanced?" 馃槅 I really put it out there for feedback. I initially had it as "P2" since it was a step up from the P1 component. I'm really happy to change it to whatever is more intuitive though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh ok, I wonder what the convention was here? It isn't obvious to me what any of the other names in the file mean either.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that P2 is the way to go. This isn't necessarily as step up from the base proofing experience since it is scoped to in-person. For the same reason proofing with a biometric was named Pb instead of P2.

The naming convention for vectors of trust is described in [RFC 8485]. They are an upper-case letter followed by a lower-case letter or a number.

Pe = ComponentValue.new(
name: 'Pe',
description: 'Enhanced In Person Proofing is required',
implied_component_values: [P1],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also what does P1 signify?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was understanding the "P" to signify proofing related components and "1" was because it was the initial component in the proofing category...I could be wrong though 馃槄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm ok, i guess i wonder what implied_component_values is supposed to be? This file is totally new to me

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description in this PR is super helpful!

The P component represents identity proofing. It contains the following values:
1: Identity proofing is performed

@gina-yamada
Copy link
Contributor

gina-yamada commented May 14, 2024

@KeithNava I started to set up the Sinatra app side. I am testing with your branch. Can you add enhanced_ipp_required to the Service Provider session on this branch? I am able to login with your branch (and not with main).

Update: I can see the vtr on your branch has Pe included when I sign in from my branch (yamada/LG-12858-EIPP-Option) after selected Enhance IPP.

@gina-yamada
Copy link
Contributor

gina-yamada commented May 16, 2024

Nice work Keith! 馃憦 馃コ

  1. I got our branches to work together by adding to app/forms/openid_connect_authorize_form.rb this function:
def enhanced_ipp_required?
   parsed_vector_of_trust&.enhanced_ipp?
end
  1. Not needed to work but I think we should add it to saml. app/models/federated_protocols/saml.rb
def enhanced_ipp_required?
   false
end
  1. What do you think about moving enhanced_ipp_required on sp_session to be next to biometric_comparison_required? I think the acr values and vtr values are nice on the end. Only my preference so if you don't like it- ignore it.

@@ -5,7 +5,7 @@ class ServiceProviderRequest
# since these objects are serialized to/from Redis and may be present
# upon deployment
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KeithNava I am not sure what precautions are needed. I would ask to ensure you handled everything for a smooth deployment since you made some modifications.

@KeithNava KeithNava force-pushed the keithw/LG-13235-consume-eipp-data-from-sinatra branch 2 times, most recently from a075b2b to a9b5056 Compare May 20, 2024 13:19
@@ -138,6 +138,10 @@ def biometric_comparison_needed?
!current_user.identity_verified_with_biometric_comparison?
end

def enhanced_ipp_required?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this method doing on the authorization controller? I'm not sure I see where it is used.

@@ -38,6 +38,10 @@ def service_provider
request.service_provider
end

def enhanced_ipp_required?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have been trying to get away from including these methods on the protocol classes or adding the to the session. This was the way we would forward along SP request requirements before we built the AuthnContextResolver and resolved them based on VTRs and ARC values downstream.

@@ -20,6 +20,7 @@ def initialize(
# rubocop:disable Lint/UnusedMethodArgument
ial: nil,
aal: nil,
enhanced_ipp_required: false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 things here:

  1. This is going to be problematic in the 50/50 state because this could get serialized to the session by a new instance and read from an old instance. That would result in an ArgumentError because the old instance will not know about this arg.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking back over this and I forgot to write out the second thing. How embarrassing. I believe I was going to describe here what I described in this comment: #10618 (comment)

allow(controller).to receive(:pii_requested_but_locked?).and_return(false)
end

it 'redirects to the redirect_uri immediately when pii is unlocked if client-side redirect is disabled' do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like an odd test-case here since PII being locked isn't necessarily related to enhanced in-person. I am not actually sure that we need changes to the authorization controller since its behavior should not change. It should continue forward the VTR along and we will operate on it downstream when we decide if we need enhanced in-person proofing.

@jmhooper
Copy link
Member

It looks like this change is adding the enhanced_ipp_required to sp_session. We have actually been moving away from this pattern. Recently I actually merged a change to stop writing biometric_comparison_required in the session (ref). This was done for a few reasons:

  1. It is difficult to keep in sync between ACR values and VTR with the code for determining what is required spread amongst other concerns
  2. It doesn't work well with multiple vector of trust requests where the vector that is in-use can change over the course of a request
  3. It makes adding and removing new requirements challenging because they SP request and SP session need to be modified and both introduce 50/50 state concerns

We should be able to introduce the Pe vector component and update the parser to return the requirement for enhance in-person. The VTR will be passed along into the SP session and the AuthnContextResolver will pick it up there. From there we can call resolved_authn_context_result.enhanced_ipp? without needing to make any changes to the SAML/OIDC interface code or the code that writes into the SP session.

@jmhooper
Copy link
Member

This one looks like a good model implementation for what you need to do to add a new vector. Thank you @KeithNava!

@svalexander
Copy link
Contributor

looks like there are just lint fixes that are needed to be able to merge this

@gina-yamada
Copy link
Contributor

gina-yamada commented May 21, 2024

LGTM! 馃コ I tested your last commit with branch yamada/LG-12858-EIPP-Option and I can see vtr values C1.P1.Pb on sp_session.

@KeithNava Can you have this merged in before the next deployment? I cannot push my Sinatra PR in until this makes it into prod. Thanks

@KeithNava KeithNava force-pushed the keithw/LG-13235-consume-eipp-data-from-sinatra branch from e650498 to 5107a9b Compare May 21, 2024 19:56
@KeithNava
Copy link
Contributor Author

Thanks so much everyone! I learned a lot during this review, really appreciated all the feedback! 馃挴

@KeithNava KeithNava merged commit 56cb759 into main May 21, 2024
2 checks passed
@KeithNava KeithNava deleted the keithw/LG-13235-consume-eipp-data-from-sinatra branch May 21, 2024 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants