...
David has developed documentation that introduces concepts and why a site may be interested in introducing the key concepts for the MCB. Community input on the MCB is welcome. The Shib users list will be used for questions and comments on the MCB. Community input is welcome. The code is stored on GitHub and an issue tracker will be used for tracking bugs. A roadmap will be developed for next steps, such as to track if additional authentication modules may be needed. It will also be important to understanding understand what needs to will be done required to integrate into Shib V3 when it comes out.
...
Benn reported that UC Berkeley has been interested in counting failed authentication as a way of looking at password entropy and reset policies for the bronze and/or silver profiles. There was the A strawman proposal was posted to the wiki at https://spaces.at.internet2.edu/display/InCAssurance/Failed+Authentication+Counter+Strawman
Berkeley has contracted with Unicon to build out this the Failed Authentication monitor. Things are The work is moving along and development is about to start. It should be a couple of months before there is reasonably full featured project. This will be an open source project. Code will be in GitHub.
The scope of the work involves an aggregator that writes failed authentication events to a database that logs the subject, the time, and IP address and a service. The monitor periodically (TBD) queries this. There Actions will be thresholds with actions fired off triggered at a given threshold. So for example, the system might be configured so that after 10K events, email this a particular address. The email might go to the subject, or to an another email address such as the security team. Another action that could be triggered might be to cut generate a ticket to an issue tracking system. End goal is ability to stop asserting an IAQ for someone. There may be the ability to add or remove somebody to from a group (such as Grouper group), where removing somebody from the group would effectively remove them from LDAP. The idea is that the the system will fire off the appropriate actions and record history that it did that. There would be an API into it this system for user level and Admin admin operations, such as obtaining current counts for a user. That could be tied into the user identity portal, so you can put it would be possible to show a notification when the a user logs in. Obtaining and setting thresholds will be configurable via a database. Benn will send links to the Assurance list as portions are released publicly