Child pages
  • Minutes of Assurance Call of 12-Feb-2014

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.

Failed Authentication Counter

Berkeley was interested  Benn reported that UC Berkeley has been interested in counting failed authentication attempts as a way of looking at pas ward password entropy and reset policies for  for the bronze and/or silver profiles.

There was the straw man posted to spaces wiki

Looked using a SYSLOG to export to  a  central accumulator

Which would put relevant events in a simple database table
Which a monitor could pull
And send an email or
Cut off an assurance qualifier

Thought we Could do reporting out from credential stores using existing technology and aggregating results w existing technology
But the monitor was the big gap

Brett from U Nebraska Lincoln had a similar system that he demoed at Idnetity week

The news is that Berkeley has signed a contract w Unicon to build out this monitor

It will be open source under the   BSD ? license

Developmetn will be open in that we have a GITHUB  ? Where the code will be placed as developed
Will be using internal issue tracker for project management purpose but it will be world readable

Docuemntation is internal
Need to make that more accessible

The development is about to kick off

So code should be going out soon

A couple of months before we have reasonably full featured project

But moving along

Still to be Determined where final home of  the project will be

Benn can talk about what the monitor will be capable of

Or at least what is scoped into the SOW

Minute 26.

Ann is interested in that

Sure

Not that much

The aggregator writes failed auth A strawman proposal is seen at https://spaces.at.internet2.edu/display/InCAssurance/Failed+Authentication+Counter+Strawman

Berkeley has contracted with Unicon to build out the Failed Authentication monitor. The work is moving along and development is about to start. 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 queries this

Periodically is TBD

There will be thresholds with actions fired off .  Actions will be triggered at a given thresholdSo . So for example, the system might be configured so that after 10K events, email this addressActions are e-mail a particular address. The email might go to the subject,
Or or to an arbitrary another email address
Notify such as the security teamOr cut . 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 someoneHave . There may be the ability to add or remove somebody to from a group (such as Grouper )

Berkeley will track IAQs in one or more Grouper groups

Where group), where removing somebody from the group would effectively remove them from LDAP

Expiring credentials directly is another potential action

Or send a message (in JSON?) to an endpoint

Updating LDAP directly rather than going through a group store

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 a report out for when the user logs in

Need integration w credential management apps to reset the counter

Obtaining and setting thresholds.
Configured via a database
Configuration options would be set via a UI, possibly after the 1.0 release
Benn will send links to the Assurance list as portions are released publicly

Ann: Benn could also put info on the Assurance wiki, the straw man and the requirements document are in the wiki already

===

Karen, add anything?

Nothing , thanks for asking though

===

Scott, nothing to add

====

David, general comments, I have now linked the draft documentation  page into the project status pDi

it would be possible to show a notification when a user logs in.  Thresholds will be configurable. Benn will keep the Assurance informed as portions of the work are released publicly.