Audit logs, MFA, and SSO sessions

[Clay Cooper]

Scott,
Thanks for the assessment and suggestions.

I think that probably my problem statement is wrong. What I really want to know is if the user was prompted for a credential: primary or secondary. I have that information in the process log but not in a way that attaches the authentication success to the resulting session logged in the audit log.


Clay Cooper 
Software/Systems Design Engineer Technical Specialist
Information and Technology Services 
Finance & Administration 
Rochester Institute of Technology 

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Thursday, September 2, 2021 08:39
To: Shib Users <users at shibboleth.net>
Subject: Re: Audit logs, MFA, and SSO sessions

>    Is there a strategy on getting the log to properly reflect the reuse of an SSO session in this configuration?

Not easily. There's a flag on the AuthenticationResult that's produced by the MFA flow that signals whether it's a previous result. That's not set normally by anything but the code that deserializes results out of a session and running the flow every time means the result object is always new.

You would have to override the process that builds the final result and somehow know to toggle that flag on. The mechanics of producing the result can be overridden (see Merging Results in the MFA docs) but it's not easy.

I think all of that is probably dumb and it would make more sense that if you somehow knew whether SSO happened or not (and that's not itself clear to me), you could stash something off in e.g. a ScratchContext and then build a custom audit extraction rule to log the SSO field based on that instead of the default extractor.

Given that both are ugly-ish, the latter's probably less ugly and less disruptive to the internals.

-- Scott


-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net