Logging relyingPartyId (service provider) for authentication failures

[MacDonald, Michael J.]

Thanks Scott.  Is there a list of other MDC Variables?  Or is it just what is listed here: https://wiki.shibboleth.net/confluence/display/IDP30/LoggingConfiguration#LoggingConfiguration-MappedDiagnosticContext

Thanks,
-Mike


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, March 01, 2017 4:40 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Logging relyingPartyId (service provider) for authentication failures

On 3/1/17, 4:20 PM, "users on behalf of MacDonald, Michael J." <users-bounces at shibboleth.net on behalf of Michael.MacDonald at tufts.edu> wrote:

> Is there an easy way to append the relyingPartyId / ServiceProvider 
> name for authentication failures in Shibboleth in either idp-audit.log or idp-proces.log?

No, "failures" in authentication are localized inside a login flow and just aren't visible to the rest of the system. A user just sits on a page and fails until they stop and the system never gets to a state where auditing happens.
 
Auditing the "event" of a request from a service is something I considered but it eventually got merged into the main audit record at the end and the problem is that it just never happens when "authentication fails", the request just gets abandoned. It might be interesting to see if there's a way to catch that timeout but it would happen long after the user was gone, nowhere near the actual failures in time.

Brute force there can probably be logging of particular information added to the failure messages but it would be arbitrary what got included. What might make sense is to consider the possible addition of more MDC variables based on important state. That might not be that difficult to add, though what I'd probably want to do is just make it extensible via script so you'd be able to just sketch up the addition of anything you wanted at runtime.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net