Solving Federated Access in Indianapolis
27 October 2014 at 11:11am
This week is the Internet2 Technology Exchange Meeting in downtown Indianapolis. As is the way with these big international meetings there are a number of co-located meetings including the REFEDS (https://refeds.org/) meeting and there has been a lot of discussion of relevant topics for the Jisc community so I've provided some links and brief notes here. If you'd rather jump straight to the presentations you can get to them at https://refeds.org/meetings/oct14/. If you want me to expand on any points please let me know in the comments, below.
As usual, the meeting started with an update on what's been happening in REFEDS:
* there's a new wiki - http://wiki.refeds.org
* and a blog http://blog.refeds.org
* REFEDS has a seat on the Kantara Board of Trustees
* Assurance is still a big topic, but we can't move forward until a baseline is agreed
* Vectors of Trust - a new IETF group recently formed (see below for more info)
* "traditional" Levels of Assurance don't really work for REFEDS organisations
* MARI - Managing Attribute Release in Interfederation use cases - https://wiki.refeds.org/display/GROUPS/MARI - The MARI working group was set up following to solve a problem of SPs being unable to rely on consistent attribute release from different countries. Attribute bundles via entity categories are supposed to address this, but until they are effectively managed MARI has been set up to search for better solutions.
* Charging model - REFEDS is moving from an informal subscription to a lightweight funding agreement; moving to automatic generation of invoices; want to formalise levels, but not sure how to differentiate.
* AARC - AuthN and AuthZ for Research and Collaboration - a Horizon 2020 proposal - Training and outreach - lower barriers for organisations to join national federations; training activities for data professionals; best practice and legal. Tech/policy work: use eduGAIN; define an incident response framework to work in a federated context; define an LoA framework.
US eGov update
* As a community we have a good chance to influence the US government - our success is acknowledged, but due to election cycles any implementation may not happen.
* FICAM and NSTIC are the 2 main US gov Id Activities - NSTIC is more experimental, looking at next generation services, privacy etc., has distinct government and pilot efforts. Currently is just US citizen to US Gov, but keen for it to be wider and more international.
* US Gov announced a new programme a couple of weeks ago looking at multifactor requirements for citizen to governments - 90 days to spec and 18 months to implement, also includes chip and pin (old hat to non-US, but new and shiny for them) - but only for (most) government agencies - not commercial services.
* Identity resolution bundle - I have an acoount for a user how do I connect him using his federated identity? Bundle of attributes: legal first name, last name, middle name or initial
current address; DoB; SSN; email address.
* The National Association of Purchasing Managers believe these attributes can identify 95% of people - is this useful or evil? - Depends if user driven or centrally provided. Individual agency autonomy in government makes this hard.
* No protection for IdP if they tie up the wrong John Smith - does there need to be some indemnity?
* Bundles can stop SPs asking for everything - How about 2 flavours: vanilla = privacy preserving, chocolate = core set of identity attributes?
* PrivacyLens as a paradigm for attribute release consent manage. enabling effective and informed end user consent. Google is all or nothing, not fine grained. How do you revoke consent?
Security Incident Response trust Framework for Federated Identity (SirTFi)
* NREN CSIRTs good at handling incidents, GRID and HPC world good at dealing with users
* SCI - Security for Collaborating Infrastructure - developing a Trust Framework.
* A collaborative activity of information security offiers from large-scale infrastructures
– EGI, OSG, PRACE, EUDAT, CHAIN, WLCG, XSEDE, …
* Developed out of EGEE – security policy group
* Developing a Trust framework
* Enable interoperation (security teams)
* Manage cross-infrastructure security risks
* Develop policy standards
* Especially where not able to share identical security policies
* Version 1 of SCI document at http://pos.sissa.it/archive/conferences/179/011/ISGC%202013_011.pdf
* SCI is IdP led - not Federation Operator led
* IdPs self-assert a level of assurance - more a statement saying I am willing to play nicely and have the right policy.
* SIRTFI are proposing a lightweight approach to see if it meets peoples' needs.
* "We know we have reasonable policies in place, but haven't had a way to reveal that to people."
* Don't need external audits, used to peer review etc.
Remote Vetting
* OpenIdP for students and staff in SWAMID
* Will be Kantara AL2 compliant
* Easy to vet someone face to face on campus by seeing their passport, but how do you do it remotely?
* AL2 remote vetting - microtransaction (PayPal, creditcard, bank) + utility bill or copy of ID card
* That's okay in-country - in Sweden there are many government databases that can be cross referenced, but how do you verify a user from Pakistan and how many 17 year olds have a utility bill?
* If a federation can vouch for a university then that could be used, but there are no universally accepted LoAs across federations.
* But do SPs really need to know an identity? Or do they just need to know that it is the same person each time and that they will still get paid.
IETF Vector of Trust
Back to basics:
* Identity proofing
* credential strength
* assertion presentation
* operational management
* org maturity
* information security collaboration
Aiming for:
* increased comparability
* common syntax
* "LOA1.5"
* more focus on auditing
* http://secureidnews.com/news-item/nist-may-revise-four-levels-of-assurance - interesting article from US Gov
* "The vot@ietf.org list is for discussion of a common set of baseline "vectors of trust": common, orthogonal aspects of organization, technology and policy that help to determine the level of assurance that can be placed in a deployment of digital identity technology. Work will draw on deployment experience related to web identity technology (eg SAML, OAUTH and OpenID
Connect) as well as experience with current state of the art in identity assurance."
Supporting Virtual Organisations
* A comparison of multiple systems: www.bit.ly/aa-overview
* HEXAA, PERUN, OpenConext, Unity, Switch GMT, GakuNin mAP, Grouper, COmanage, REMS, Openstack VO, FeideConnect.
Enabling group management in eduGAIN using PERUN system: https://refeds.org/meetings/oct14/slides/REFEDS_Prochazka_eduGAIN_Groups...
LIGO
* Multimessenger Astronomy - joining up 10s of billions dollars of equipment.
* Hard deadline of July 2015 when advanced LIGO detectors begin observing
* gw-astronomy.org
* Uses COmanage and Shibboleth SP as an Attribute Authority (SAML and LDAP interface)
* All SPs tagged by InCommon as InCommon R&S SPs
* All good apart from Attribute Release. Attributes filtered on R&S entity - just need eduPersonPrincipleName. Only Swedes and Swiss currently using R&S categories.
* Currently 166 users obtained LIGO guest credentials
* Federation operators and IdP operators see R&S as a barrier.
* Money talks. If a CIO/IT director won't listen, go to the VP Research - take along a hotshot researcher if necessary.
* LIGO is confident that this Gravitational wave science will end up in a Nobel Prize: "Wouldn't it be great to be able to say this was made possible via our federated Id solution?"
REFEDs RFC work
* Big change - moving from ASCII-only plain text documents to XML with SVG line art.
* For changes see https://datatracker.ietf.org/doc/draft-flanagan-rfc-framework/
* Drafts stable in next 2-3 weeks then will put out RFP for people to make this happen
Entity Categories
* Hide from Discovery Entity category - https://wiki.refeds.org/display/ENT/Hide+From+Discovery
* Basically means don't add into your Discovery Service
* Security consideration - just because it is not in the Discovery Service doesn't mean that SPs won't accept assertions from this.
* https://wiki.refeds.org/display/ENT/Research+and+Scholarship - caused lots of discussion on REFEDS list, but appears to be consensus now.
* LIGO needs this. We'll be in touch shortly with UK insitutions that have LIGO researchers to discuss the R&S category and what it means for you as an IdP.
* Library/affiliation - controversial as eqaul number of people think this is needed/not needed.
* Alternatively could be InAcademia - attempting to build a use case for global interfederation to assert 'studentness' to SPs in the simplest RP interface.
* IdP proxy that asserts a single attribute using OpenIDConnect - typically for discount companies (who don't need email or name or anything) so don't have to do the full 'SP dance'.
Monitoring Tools Update
* SAML2 testing tools aka FedLab
* How do you make sure your federation is working and running correctly?
* Saml2test - checks implementation/installation conforms to the standard and the profile
* Metadata analysis - e.g. http://monitor.edugain.org/coco
* Verify_entcat - verifies that an IdP is compliant with an entity category
* metadata consumption check service - checks if an IdP wants to talk to an SP
* IdP monitor - verifies the whole authN process works for a user.
* See https://github.com/rohe
Impact of Interfederation
- Update from UK
* Had 46 entities in eduGAIN based on an opt-in policy.
* In our metadata 74% is UK entities and 26% is eduGAIN metadata.
* Just have one single feed that is UK fed + eduGAIN metadata.
* Opt-out is more useful - let the metadata flow.
* So from mid-November we're moving to opt out.
* Currently UK represents just 7% of eduGAIN.
* By the end of the year apart from schools and some specific test IdPs or wildcard IdPs all of the UK metadata will be in eduGAIN and will make up 70% of eduGAIN.
* We filter on inbound aggregate to remove 1024 bit keys, incorrect data and country contract specific metadata.
- Update from US
* US intentions similar to UK to get to opt-out, but might need some more steps.
* Working Group discussing legal, campus and technical issues.
* The InCommon Participation agreement in 2004 never had indemnification in it. In discussions with lawyers about eduGAIN concerns have been raised about indemnity.
* The original agreement only mentioned publishing metadata to *InCommon* participants. To be able to share wider a change is needed to the Participation Agreement.
* US Import laws are pretty liberal, but export metadata has PII (contact details) so checking legality of this - but practically it is public information so shouldn't be an issue.
