...
Ann West, Internet2
Karen Harrington, VA Tech
Scott Koranda, Spherical Cow ConsultingGroup
Benn Oshrin, Spherical Cow ConsultingGroup
David Walker, Internet2
DISCUSSION
...
Trust framework providers, such as InCommon, have 6 months to comply with the new FICAM spec. There are discussions underway to determine the impact of FICAM 2.0 to the InCommon Assurance program and the community. An important question is: what are the service providers FICAM will be working with first? The Veterans Admin is a big one. InCommon is aware that many campuses don't want their faculty and staff to leverage their campus credentials to interact w with consumer based services like the VA. They Campuses want to use their the campus credentials to be used for grant submissions and teaching resources or for interactions interactions with the the Dept of Ed. InCommon is hoping to find out from FICAM, what is the ETA for FICAM to bring on board the services that are more related relevant to higher ed? The answers to these questions will help the AAC determine how to support FICAM 2.0.
...
David has developed documentation introducing the key concepts for the MCB. The Shib Shibboleth 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 if additional authentication modules may be needed. It will also be important to understand what will be required to integrate into Shib V3 when it comes out.
...
Benn reported that UC Berkeley has been interested in counting failed authentication attempts as a way of looking at password entropy and reset policies for the bronze and/or silver profiles. A strawman proposal was posted to the wiki is seen at https://spaces.at.internet2.edu/display/InCAssurance/Failed+Authentication+Counter+Strawman
...
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 queries this. Actions will be triggered at a given threshold. So for example, the system might be configured so that after 10K events, email 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 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 from a group (such as Grouper group), where removing somebody from the group would effectively remove them from LDAP. There would be an API into this system for user level and admin operations, such as obtaining current counts for a user. That could be tied into the user identity portal, so it would be possible to show a notification when a user logs in. Obtaining and setting thresholds Thresholds will be configurable. Benn will send links to keep the Assurance list informed as portions of the work are released publicly.