Child pages
  • Minutes of Assurance Call of 12-Feb-2014
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

Assurance Program Update

FICAM has released a 2.0 version of their spec as of early February 2014.

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 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

Starting discussions to see what is the impact to the InCommon Assurance program and the community

The question came up about what are the service providers they are working with first?

The Veterans Admin is the biggest one.

Most campuses don't want their faculty and staff leverage their campus credentials to interact w consumer based services like the VA

They want to use their credentials for grant submissions and teaching resources or dept of Ed resources
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 exploring assurance for research

and in developing  a community profile to address research needs

There has been  a request for a community profile that is more multi factor oriented

The hope is to address the needs of the SP s that are of interest to the InCommon community

And the needs of the IDP s 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 Koranda : have you 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 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

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?

Ann: first step is requirements gathering and LIGO will have a 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

Then we will announce the 2014 version of the AD Assurance Cookbook
Just doning final tweaking
====

Multi Context Broker

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 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

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 pag

  • No labels