This Wiki is available to view at but still under maintenance. PLEASE DO NOT EDIT THE WIKI UNTIL FURTHER NOTICE. We are attempting to restore missing edits which took place between Monday 8 and Thursday 11 April 2019, therefore the site is likely to be taken off line at any time. Updated 20:43 CEST 16 April 2019.
Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

CategoryRequirementExplanationRelevant?Achived?
Identity lifecycle & linkingAccount linkingThe ability, for one entity, to link credentials from multiple IdPs to one account on an SP. More generically, the ability for a researcher to link multiple identities together, whether held in parallel or succession. The ability to accurately link accounts depends strongly upon the release of an appropriately unique and persistent identifier.No(error)
ORCIDORCIDs have become a common requirement. There are several ways by which they can arrive at Research SP: from the home organisation IdP, integrated by a proxy, user login at ORCID IdP, or provided manually by the researcher. The release of ORCIDs and their aggregation in community proxies should be prioritised.No (not relevant for this pilot)(error)
Discovery & usabilitySmart discoveryIdP discovery should be “smart enough” to quickly and easily take a user to their appropriate home IdP. For example show the user a short list tailored to them by home country, institute, e-Infrastructure, research community, project or other hints.Yes(tick)

(tick)

Was already implemented before the pilot

Logo in metadata at an agreed standard sizeDiscovery services should display organisation logos to aid the user in choosing the IdP. IdPs or research community proxies should provide a logo at an agreed standard size.No(error)
Service catalogueEach research community should provide a service catalogue to help users find relevant resources,i.e., service discovery.No(error)
AuthZ


Real time authorisationAuthZ decisions at an SP must be based on identity credentials, attributes or assertions that have a short lifetime, i.e. they are valid now and not for too long into the future. Even within this short period it should be possible for the SP to look up real time status information, e.g. revocation lists and/or suspension lists.Yes(tick)(tick)
Both DARIAH and EGI allow to restict the validity of AuthZ information in time
User blockingIt must be possible for an Infrastructure or research community to block access to a service based on the presence of an identity credential in an operational suspension list or revocation list.Yes(tick)(tick)
EGI can revoke validity of a user
Service Provider quota management. Resource allocation + accounting, e.g. computer resources, access permissionsIt must be possible for an SP operator to limit access of an individual identity or a group, or by attributes or roles allocated to the identity by the IdP or the research community AA/Proxy, to subject them to quotas and make resource allocations. Usage records (accounting) must be possible at the same granularity.No(error)
DeprovisioningDeprovisioning of AuthZ attributes, assertions, credentials, tokens, or other artifacts is an essential part of access life-cycle management. It must be possible to suspend or remove an individual’s access when they no longer possess right of access, e.g. because they have left the research community. Some use cases may require immediate removal of access while others may only require removal in an identified determinate period of time.Yes(tick)(tick)
EGI allows deprovisioning of users already
Bona-Fide users for registered accessFor controlled access (“registered” access) to a dataset or other resources, it must be possible to grant this only to those users who have been proven to have bona fide rights to access.No(error)

Group management

Research communities must be able to add individuals to Groups, for use in AuthZ, Quota management and Accounting. Groups should be hierarchical and users can belong to more than one group.YesYes, it(tick)

(tick)

It's already implemented but we are seeing some possible future improvements

Active role selectionIndividual users must be able to select which attributes, groups or roles are “active” for a particular connection request and AuthZ decision.No(error)
Attribute releaseAttribute releaseIdPs must release a unique, persistent, omnidirectional identifier, email address, and name for users when accessing research services. For example, ensure that the CoCo and R&S entity categories are widely adopted.Yes(tick)Yes,

(tick)

DARIAH has implemented a DARIAH-scoped ePUID ans sends this + attributes to services and EGI

Entity attribute adoption streamliningFederations can take a long time to implement support for new entity tags and entity attributes, so in addition to federations implementing support for new entity attributes as soon as possible, the requirement is to find a work around to that problem that enables dependent research activities to proceed pending Federations completing their implementation.No(error)
Attribute release across bordersThe R&S bundle, especially, needs to easily flow from IdPs to SPs without regard to their nationalities. More outreach of the risk analyses performed by GEANT and REFEDS about R&S + CoCo entity categories is needed to increase adoption.No(error)
Security incident responseSirtfi adoptionTo be acceptable to research communities, an IdP must meet the requirements of Sirtfi and assert this in metadata.Yes(tick)TBC
Peer assessment of incident response performanceProvide a way for participants in a federated security incident response to provide feedback on how well each participant has performed, as an incentive to maintain good operations-security processes.No(error)
Incident response communication channelsNext step after Sirtfi is to require the definition and maintenance of IR communication channels. These channels should be tailored to the incident scenario, involving only necessary people, and the contact points should be periodically checked for responsiveness. Assume that Snctfi addresses this with Proxied Research SPs.No(error)
IdP suspensionAbility to disable all logins from identified IdPs as part of managing a security incident. Can happen by home federation or by Proxy.No(error)
Research community proxiesIdP/SP Proxies must be allowed to join edugainIdP/SP Proxies must be permitted to join eduGAIN or one of its constituent national federations. Snctfi requirement below is related.Yes(tick)Yes,

(tick)
DARIAH Proxy (SP side) is in eduGAIN

Research communities voiceRepresentation of needs of research communities should be incorporated into eduGAIN governance with the ability to influence (inter)federation. Similar for REFEDS.No(error)
SnctfiResearch communities should become Snctfi compliant for scalability and ease of management, enabling a Proxy to meet operational and policy obligations of both worlds that it interconnects: the research community and eduGAIN. Federations should accept a Snctfi´d Proxy as meeting its R&S, Sirtfi, and CoCo obligations.Yes(tick)(error)
There are some requirements missing, which we plan to address will be addressed in the future
.int for R&E federationSome research organisations have parts in multiple countries, making membership in one national R&E federation problematic. eduGAIN should provide a federation home for them.No(error)
Assurance & Multi Factor Authentication (MFA)Assurance frameworkThe international community should continue work on developing assurance profiles to meet the evolving requirements of research communities.No(error)
Step up Auth/MFAStrong authentication, e.g. MFA, is required for some research community activities. The inclusion of MFA information in authentication tokens and metadata should be supported.No(error)
InteroperabilityAvoid user/interop issues due to inconsistent propagation of metadata for entities.Federations should support standard and automated metadata propagation processes and, where out of band actions are required, provide clear documentation and supportNo(error)
IdP deployment profileSpecify precisely what conditions IdPs must meet in order to provide federated credentials in research collaborations. Eg, Sirtfi + R&S. FIM4R to define the deployment profile and IdPs to adopt it.No(error)
Federation entity attributes designed to enhance user experience should be populatedEg, the entity attributes defined in the SAML “MDUI Information” specification and errorURL should be populated at least.No(error)
Non webNon-web use cases & supportA very important requirement for research communities. Many interactions between clients and servers are via the user’s command-line or via interacting applications using API access to AAI. Cannot assume that all access will be via a web browser interface, or that a web browser will be part of the authentication flow, even beforehand to set things up. Strong authentication (not necessarily MFA) may be required for some use cases.No(error)

Beyond ECP

One way of solving non-web access is via the use of SAML-ECP. Certain services currently depend on this, but other good means are available that should be used in preference. Hence, this requirement is to retool where ECP is currently present.No(error)
DelegationDelegation here means providing end-entities (users) ability to give a constrained portion of their access to another entity acting on their behalf. This might be reasonably accomplished either by impersonation or by proper delegation. This is required in any use case in which a work-flow continues without the presence and direct connection of a user.No(error)
Credential translationServices will not always be able to consume the credentials the user currently has. Translations from one type of credential to another is a very common and important requirement.Yes(tick)Yes(tick)
On-boarding & supportNon-legal entity participation in eduGAINResearch communities are often not legal entities. This causes problems should they wish to join R&E federations and hence eduGAIN. One institute does not wish to take on liability for the actions of others in the community.No(error)
eduGAIN test/dev environmentEasy-to-use testing environments to allow new Proxies and new SPs to experiment with their Federationfacing parts without interfering with existing production deployments.No(error)
Proxy test/dev environmentEasy-to-use testing environments to allow new Proxies to experiment with their SP-facing parts and new SPs to experiment with their Proxyfacing parts without interfering with existing production deployments.No(error)
Simple process for scientific SPs to become relying partiesDevelop guidance and corresponding on-boarding process to address questions such as: How does a new research SP become a relying party? And an RP of what? Relying parties through a Federation, or behind a proxy?No(error)
Help DeskFederations and eduGAIN should provide a Help Desk capability suited to supporting interactions between federations and research communities.No(error)
Sustaining critical infrastructure

IdP of Last ResortProvide sustained services to meet the many cases where global researchers do not have access to an acceptable Home Organization IdP, as an alternative to each research community solving this problem for itself.No(error)
IdPoLR not-a-robotGoogle-based captcha is not available to some users in China, so another approach to not-a-robot must be determined.No(error)
Sustainable operation of specified critical servicesWhen a “component” service ,i.e. one that is integrated with others to produce a valuable result, e.g. CILogon, becomes established as a critical element of federated e-Infrastructure, research communities look to Federations to ensure sustainable operations.”Yes(tick)

(tick)

Sustainability Statement received from EGI Check-In