Distinguishing SSO from login with initial auth (3.2.1)

[Christopher Bongaarts]

On 12/6/2016 2:49 PM, Cantor, Scott wrote:
>> I expect this to be easier in 3.3 when we're able to ditch the initial
>> auth construct...
> There's an API for this, and there're already success/failure counters.

For completeness, the goal is to get an audit log entry for each of the 
following cases:
- user enters valid username/password on password form
- user enters invalid username/password on password form
- user auths with Duo 2nd factor (and maybe a fail counterpart if 
detectable)
- user is considered authed by virtue of SSO (either password or Duo)'
This would be in addition to the standard audit log entries.

General format of log messages is:
login ok for USERNAME on CLIENTIP (AUTHNCONTEXTCLASSREF) SPENTITYID
login failed for USERNAME on CLIENTIP () SPENTITYID
sso ok for USERNAME on CLIENTIP (AUTHNCONTEXTCLASSREF) SPENTITYID

The first two I had to insert directly in 
ValdiateUsernamePasswordWithLDAP (actually my lockout derivative) in 
order to catch that particular case, particularly failure.

In fact, if I didn't care about differentiating between SSO and entering 
user/pass, I was *almost* able to get the stock audit log configured to 
output these; I forget which item was not immediately available - think 
it was the relying party entity ID or the authn context.  And the audit 
log seems to only be invoked for ultimately successful authentications.  
I'm pretty sure I could have worked around that by dropping a new field 
in the audit context, but i think it would have meant modifying yet 
another system bean.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161206/b61277cc/attachment.html>