Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

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 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 The 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 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 attempts as a way of looking at password entropy and reset policies for the bronze and/or silver profiles. There was the A strawman proposal posted to the wiki is seen 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   Thresholds will be configurable via a database. Benn will send links to keep the Assurance list informed as portions of the work are released publicly.