Versions Compared

Key

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

Table of Contents

Participants

...

Panel
titleContact dataProposers


NameOrganisation
KIT / DFN



Please provide contact details for participants involved in this activityActivity Participants
Panel
title
GN4-3 project
team


Name
Email
OrganisationRole
Proposer
uros.stevanovic@kit.eduP.I.

PI
jule.ziegler@lrz.de
DFN-LRZScrum Master
niels.vandijk@surfnet.nl
SURFnetMentor
Halil AdemGRNETA-Team: Developer
andrejshliamin@gmail.com
LitnetA-Team: Developer




SIRTFI
Panel
titleContact data of Parties involvedStakeholders


Name
Organisation
Role 
Hannah Short

Sirtfi

Please provide names and contact details for additional (external) organizations involved in this Incubator project

Organisation Name
Person names
Person emailRole within pilot

community (REFEDs)

Hannah (

also in GN4-3 WP5 T4

),
DavidG (

 Review and feedback
David Group 

Sirtfi community (REFEDs)

also in GN4-3 WP5 T4

),

Review and feedback
Tom Barton

Sirtfi community (REFEDs)

University of Chicago & Internet2

)

hannah.short@cern.ch

davidg@nikhef.nl

tbarton@uchicago.net

 Review and feedback SIRTFI

Review and feedback
Scott Koranda 

 Sirtfi community (REFEDs)

 Scott Koranda (Ligo)

LIGO

 Implement & test solution in context of LIGO


Activity Overview

Panel
titleDescription

Research communities have a need to express and potentially share certain trust marks on IdPs and SPs. These trust marks may differ from existing trust marks issued by identity federations, or . They may be put in used to compliment existing ones, in case the federation operator does not support these, particular trust marks like e.g. in the case of SIRTFISirtfi.

This project activity tries to implement a technical solution that matches the requirements as described by the SIRTFI Sirtfi community and investigates usability of the solution for research communities and the impact of the solution of Identity to the identity federations. It also explores potential other scenarios where a similar methodology could be used, like e.g. REFEDs REFEDS MFA and in the context of the IdP self assessment tool that was developed in GN42GN4-2.

Out of scope for this activity are the questions about It does not consider itself with the questions on where and how such a tool would be used in the context of existing trust frameworks.


Please describe the goals of pilot, including activities, participants, the community(ies) that require a solution. Describe when the pilot is done and how to measure the success of it, in a SMART way.
Panel
titlePilot goals
Goals

Activity goals:

  • Create technical implementation based on
SIRTFI
  • Sirtfi + Registry
document
  • requirements;
• Distil
  • Distill technical requirements from
SIRTFI
  • Sirtfi + Registry
document
  • requirements;
  • Create/Describe technical design;
  • Buy or build (or modify existing);
  • Improve trough sprint iterations;
  • Interact with
SIRTFI
  • Sirtfi working group to improve features if needed
.
  • ;
  • Learn and discuss flows and usability in ‘real world’ (Collaborate with LIGO);
  • Deploy working setup so it can be tested with
stakeholders
  • stakeholdersv
  • Explore and describe (& implement) authZ architecture in collaboration w/
SIRTFI
  • Sirtfi working group.


Panel
titleBackground information

Sirtfi Registry Requirements: https://docs.google.com/document/d/1wh2SQU62zDRwlJLPFgwxmRnIq7IiVgPf76XI97Hzt80

Use User story description: https://docs.google.com/document/d/14pzjKo-QHWlGd5D0aRRzADSraPcDuf7HbUJrO_IbYqE/edit?ts=5c90ce9d

...

Activity Details

Please describe the technical for this pilot.
Panel
titleTechnical details
details

Initial technical details:

The project is supposed to represent a web portal, where users (i.e. dusters) will access using their federated credentials. The users will, upon invitation, be able to assert Sirtfi tag for the entity under their control. The flow will resemble https://access-check.edugain.org/. The more detailed description can be found here: https://docs.google.com/document/d/1Hwdi7iO3v2U-RrzgT_EhL7AA0xkE9RIr_bQac2IhZ3M

Initial technical implementation:

Initial implementation contains Access Check tool in conjunction with Jagger tool. Access Check tool is used to identify the owner of the entity (which is intended to be tagged), and to create an account on Jagger (for said owner/administrator). Jagger is a federation management tool, and is therefore capable of editing federation metadata. Once an account is created for the administrator of the entity in question, the administrator can then use Jagger to add a desired entity category. More technical details, including the user flow, can be found here. Installation instructions can be found under 'Activity Results'.

Architecture rationale:

The tool needs to achieve two goals:

  • Identify the owner of the service in question
  • Provides the ability to 'tag', i.e. add an entity category for the metadata of  the service

The straightforward way to identify the owner of the service is to look at its eduGAIN metadata, and identify the "owner" email of the service, for which we used a technical support email from the metadata. Access Check tool is capable of consuming metadata, identifying the necessary email, and creating an account (i.e. username/password) for the owner of the service. This is then "exported" to Jagger, where an account is created with credentials obtained from the Access Check tool. Jagger is then capable of adding entity categories and generating metadata, in essence creating an xml file that contains the desired entity category for the service.


What is the business case for this Incubator project? Who would be customers of this solution and what would potential business case look like?
Panel
titleBusiness case
Panel
titleBusiness case

The current plan is to test the implementation, and to determine whether the trust model is satisfactory. Potentially, potential applications of the solution may extend the current Sirtfi+ use case.

...

Panel
titleData protection & Privacy

How do data protection and privacy impact this Incubator project? Think about e.g. handling of personal data of users

With the federated access and adhering to basic principles of Federated Identity Management federated identity management (following DPCoCoV2 and, e.g., applicable AARC guidelines), no new issues regarding processing of personal data are foreseen.

...

Panel
titleDefinition of Done (DoD)

Please describe here the set of criteria that the product must meet in order to be considered finished.

Work is done when the initial version for proof of concept is implemented and evaluated.


Panel
titleSustainability
The assumption is that the solution will be a software product that can be operated by a collaborative organization or a technical partner on their behalf.
The software product resulting of this activity will be made available under appropriate open source license so development may continue even after the work finished in the GEANT project


Panel
titleGAP analysis

The first version of the tool is done. The consideration for potential future activities can be found here.


Activity Results

Panel
titleResults

First version of the tool contains Jagger and Access Check tool. See github: tbd

The tools is a combination of 2 services with a Service and an Identity Provider

Requirements for both parts: mariaDB, Apache2, shib2 module for apache

Part 1: Community Tagging Access installation instructions

Part 2: Enities Managment Tool


There are also three demo videos available considering different perspectives and functionalities: Video 1, Video 2, Video 3

When this Incubator project is completed, do you intend to continue using the solution? If yes, can you describe how you intent to sustain it? (E.g. through own staff, by using an e-Infrastructure provider, ...)

<Enter here>


Meetings

Date

Activity

Owner

Minutes

Feb 18, 2017

Kickoff meeting

















...