...
Ann West, Internet2
Karen Harrington, VA Tech
Scott Koranda, Spherical Cow ConsultingGroup
Benn Oshrin, Spherical Cow ConsultingGroup
David Walker, Internet2
DISCUSSION
FICAM 2.0 and the InCommon Assurance Program Update
FICAM has released a 2.0 version of their the spec as of early February 2014..
http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.html
Trust framework providers, such as InCommon, The trust framework providers have 6 months to comply with the new FICAM spec.
InCommon will talk w Anil on Feb. 7 to share thoughts about There are discussions underway to determine the impact of FICAM 2.0
We had previously submitted comments in writing.The 6 months for compliance applies to InCommon but not to IdPs.
We don't know what this means for our IDPs. We are starting discussions to see what is the impact to the InCommon Assurance program and the community. The question came up about An important question is: what are the service providers they are FICAM will be working with first? The Veterans Admin is the biggest a big one. Most 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 want to use their credentials . Campuses want the campus credentials to be used for grant submissions and teaching resources or dept for interactions with the Dept of Ed resources.
So we are trying . 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.
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 multi factor 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 seeks to grow the trust level of the InCommon federation in a logical way.
Q: Scott Koranda: have you has the AAC had input from Steering or TAC on the amount of effort to continue to put into FICAM?
Ann: no input directly from Steering on this. InCommon A: 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.
The idea is it comes back to the current POP and how the POP does not help SP s and IdP s to understand transparency on identity practices
There have been discussions about "we need an entry level set of practices for Sps and IDPs coming into the federation"
Research requirements for profiles is on the TAC list
Doing an analysis and keeping tabs on FICAM is on the ist
There are opportunities in the community that are more compelling than FICAM for the TAC
Assurance is on the TAC list, but not necessarily FICAM related
This is preliminary
Steering is looking at what TAC has recommended
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.
Q: Scott: If new profiles are developed for HE and Research will Scott: As there are new profiles for HE or for Resrearch
Will there be a chance to help influence Federated Incident Response ? That is in the profiles from the beginning?
AnnA: The first step is requirements gathering and LIGO will have a . Eventually yes, there will be the chance to provide input
===
AD ASSURANCE
David
It was open for a round of comments , that closed a while ago
We are putting a page that mentions the comments and has a respones to them
That results in a few small edits to the document
AD Assurance Update
https://spaces.at.internet2.edu/display/InCAssurance/AD+Silver+Cookbook
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 Then we will announce the 2014 version of the AD Assurance Cookbook
Just doning final tweaking
====
Multi Context Broker
.
Multi Context Broker
https://spaces.at.internet2.edu/display/InCAssurance/Multi-Context+Broker
David reported that the Multi Context Broker (MCB) code (version 1.0) is ready and a community announcement will be coming soon.Multi Context Broker code is ready, see:
https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Broker
David is putting together some documentation
Something that introduces concepts and why they may want to be interested in the MCB
David will link from the top level assurance page / project status page
It is close and we will be sending out an announcement soon
Document introduces concepts , gives some examples of how it might be used
Does not go real deep into installing and configuring
And provides link on where to get the code and config instructions
Will be using the Shib users list for questions and comments
Stored on GITHUB on internet2 space
There is an issue tracker we will be using for bugs
Right now the draft page says that we support authentication methods that can be invoked via the AAS
Also via the legacy Shib remote user authentication method
That's a less functional method but it allows people to bring in authentication methods they are already using with Shib
Dave L at U. Chicago said he has been able to implement DUO authentication for the MCB. Some of the other acceptance testers are trying that out
There will be link from project status page to the documentation
Getting community input on this
A roadmap for what should happen next
Additional authentication modules people may need
Understanding what needs to be done has developed documentation introducing the key concepts for the MCB. 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 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
Basic functionality is there
Some want a slicker user interface
What we have is not the best looking but it's functional
The 1.0 cod is out there, we just have not had time to do the community announcement
Took about 1.5 years from developing the spec to getting this implemented
This should help those interested in MFA with Shib and Assurance.
24
Benn:
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
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 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 . 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 pagit 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.