Notes: Assurance Call of Feb. 12, 2014

Attending

Ann West, Internet2
Karen Harrington, VA Tech
Scott Koranda, Spherical Cow Consulting
Benn Oshrin, Spherical Cow Consulting
David Walker, Internet2

DISCUSSION

FICAM Update and Impact on InCommon Assurance Program

FICAM has released a 2.0 version of the FICAM spec.

http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.html

Trust framework providers, such as InCommon, have 6 months to comply with the new FICAM spec.  We are starting discussions to see what is 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 consumer based services like the VA.
They want to use their campus credentials for grant submissions and teaching resources or for interactions  with the  Dept of Ed.
So we are trying to find out from FICAM, what is the ETA for the services that are more related to higher ed?
The answers to these questions will help the AAC determine how to support FICAM 2.0.

There is interest in our community in exploring/pursuing assurance for research and in developing a community profile to address research needs.
There has also been a request for a community profile that is more multifactor oriented. The hope is to address the needs of those SPs that are of interest to the InCommon community and the needs of the IDPs for good practices. The AAC is trying to come up with a happy medium that grows the trust level of the InCommon federation in a logical way.

Scott: has the AAC had input from Steering or TAC on the amount of effort to continue to put into  FICAM?

Ann: InCommon TAC has been working on priorities and has passed along its recommendations to Steering. TAC wants to make assurance relevant to the community as a whole. One approach is to set a baseline set of practices for the community, to bring up the trust level. This can potentially address the fact that the current POP (Participant Operational Practices) document does not provide sufficient transparency to help SPs and IdPs fully understand the identity practices in effect.

Scott: If new profiles are developed for HE and Research will there be a chance to help influence Federated Incident Response in the profiles from the beginning?

Ann: The first step is requirements gathering. Eventually yes, there will be the chance to provide input

AD Assurance Update

https://spaces.at.internet2.edu/display/InCAssurance/AD+Silver+Cookbook

David reported that the comment period for the AD Assurance work closed at the end of January. 

The comments that were received have resulted in some tweaks to the document. Soon there should be an announcement of publication of the 2014 version of the AD Assurance Cookbook

Multi Context Broker

https://spaces.at.internet2.edu/display/InCAssurance/Multi-Context+Broker

David reported that the Multi Context Broker (MCB) code is ready and a community announcement will be coming soon.

https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Broker

David has developed some documentation that introduces concepts and why a site may be interested in the MCB. We are interested in getting community input on the MCB. The Shib users list will be used for questions and comments on the MCB. The code is stored on GITHUB. An issue tracker will be using for tracking bugs. Dave Langenberg from U. Chicago said he's been able to implement DUO authentication for the MCB. Some of the other acceptance testers are now trying that out. A roadmap will be developed for next steps, such as additional authentication modules that may be needed. We will also need to understanding what needs to be done to integrate into Shib V3 when it comes out.

It has taken about 1.5 years from developing the spec to getting this MCB implemented

Benn:

Failed Authentication

Berkeley was interested  in counting failed authentication as a way of looking at pas ward entropy and reset policies 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 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 at a given threshold

So after 10K events, email this address

Actions are e-mail to the subject,
Or to an arbitrary email address
Notify the security team

Or cut a ticket to an issue tracking system

End goal is ability to stop asserting an IAQ for someone

Have ability to add or remove somebody to a group (such as Grouper)

Berkeley will track IAQs in one or more Grouper groups

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 for user level and 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