-
Notifications
You must be signed in to change notification settings - Fork 130
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking AAL attribute value differences #11817
Changes from 3 commits
f224557
61942f2
6c1a157
d09e2a9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,6 +59,10 @@ def build | |
:decrypted_pii, | ||
:user_session | ||
|
||
def analytics | ||
Analytics.new(user:, request: nil, session: {}, sp: nil) | ||
end | ||
Comment on lines
+62
to
+64
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ditto about logging from the controller layer if possible! SAML idp controller is a mess but is there a way? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is actually way messier than the OIDC code path, since the |
||
|
||
def should_add_proofed_attributes? | ||
return false if !user.active_profile.present? | ||
resolved_authn_context_result.identity_proofing_or_ialmax? | ||
|
@@ -150,9 +154,22 @@ def add_aal(attrs) | |
requested_aal_level = Saml::Idp::Constants::AUTHN_CONTEXT_CLASSREF_TO_AAL[requested_context] | ||
aal_level = requested_aal_level || service_provider.default_aal || ::Idp::Constants::DEFAULT_AAL | ||
context = Saml::Idp::Constants::AUTHN_CONTEXT_AAL_TO_CLASSREF[aal_level] | ||
|
||
if context != asserted_aal_value | ||
analytics.asserted_aal_different_from_response_aal( | ||
asserted_aal_value:, | ||
client_id: service_provider.issuer, | ||
response_aal_value: context, | ||
) | ||
end | ||
|
||
attrs[:aal] = { getter: aal_getter_function(context) } if context | ||
end | ||
|
||
def asserted_aal_value | ||
authn_context_resolver.asserted_aal_acr | ||
end | ||
|
||
def add_ial(attrs) | ||
asserted_ial = authn_context_resolver.asserted_ial_acr | ||
attrs[:ial] = { getter: ial_getter_function(asserted_ial) } if asserted_ial | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like our typical pattern is to log analytics from the controller level. is there a way that we can have this class expose an
analytics_attributes
or something that we can leverage from the controller? then we can attribute the right request, SP, session info as needed as wellThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i found some examples of this pattern, so thought that it would be okay in this scenario, especially since it's a short-term event that will be removed when it's safe to implement the actual fix.
but i don't feel that strongly about it, and can try to figure out how to expose the needed data at the controller level -- just means it will have to wait until after i'm back!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think some of the context such as SP is valuable, maybe as another option we could popular
sp:
from that data hereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree that we could populate sp data -- i'm not sure what "as another option" means exactly here? do you mean keeping this event in the presenter with the included data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the suggestion is to use
identity
and pass insp: identity.service_provider
or similar. In this case, it is probably less useful since we pass inclient_id: service_provider.issuer,
to the event itself.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i know that the Analytics object adds some extra details if theactually, when i look a little closer, i think that's only the case if there's also asp
value is there, so i can add it in, in case any of those details end up being useful!session
object. so maybe it's not that useful