Versions Compared

Old Version 4

changes.mady.by.user Marcus Hardt

Saved on

compared with

New Version Current

changes.mady.by.user Michael Schmidt

Saved on

Key

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


Ask Christos, Marcus and Uros to add stuff

Table of Contents

Participants

...

Panel
titleGN4-3 project team


#Enter the persons who are participating in the team that works on this Activity - delete this line after using the template#

NameOrganisationRole

Michael Schmidt

LRZScrum Master

Uros Stevanovic

KITProduct Owner, Developer

Slávek Licehammer

CESNETeduTEAMS Developer



Panel
titleStakeholders


Name

Organisation

Role 
Christos KanellopoulosGEANTeduTEAMS Service Owner

Marcus Hardt

KITInterested Party



eduTEAMS service owner
Panel
titleStakeholder engagements


DateName(s)OrganisationNotes
21.11.19

Christos Kanellopoulos

(stale)
GEANT

GÉANTInitial stakeholder kick-off
17.12.19--Sprint Demo 2.1
08.01.20Christos KanellopoulosGEANTUsing Perun (and potentially FEUDAL) to provision apps (e.g. GSuite)
04.02.20Christos KanellopoulosGEANTProvide, in addition to PERUN, the ability of FEUDAL to provision data in LDAP
19.03.20--Sprint Demo 2.3
06/20Christos KanellopoulosGÉANTOngoing discussion to make FEUDAL available through eduTEAMS.
02.07.20--Sprint Demo 2.6


Activity overview

Panel
titleDescription

Some systems cannot be federated easily per se (e.g. like non-web services, such as login to remote *nix machines, ...) need user accounts to be provisioned before they can login. 

We have a prototype of an instant deployment tool (FEUDAL).  It facilitates provisioning of user accounts on a per VO basis. It makes use of rabbit-MQ to instantly deploy provisioning and deprovisioning events. 

Feudal is based on OIDC: It is an OIDC client, and it simply transports the information of the /userinfo endpiont along.

Feudal is based on the concept of VOs (or authorisation Groups), i.e. the end services provide the information which VOs it supports. Feudal web fronted will only display services for provisioning to  a given user based on his VO membership.

Feudal features deprovisioning and comes with a REST interface for programmatic use.

This topic is related to (De)provisioning connector for services running on Windows OS (TIM). Where possible, technical synergies shall be identified to the benefit of both solutions.


Panel
titleActivity goals
  • Goals from the
Panel
titleActivity goals

#Please describe the goals of Activity, including what needs to be delivered, participants, the community(ies) that require a solution. Describe when the Activity is done and how to measure the success of it, in a SMART way. - delete this line after using the template#

Goals of the activity are:

  • From the FEUDAL perspective:
    • Verify the approach taken (VO based approach, architecture, architectural design of components, rabbit-mq for transport)
    • Verify the decision of not  using SCIM  for provisioning (using we use the unmodified /, augmented information of the userinfo endpoint instead)

Activity Details

Panel
titleTechnical details

#Please describe the technical details for the Activity. - delete this line after using the template#

<Enter here>

Panel
titleBusiness case

#What is the business case for the Activity? Who would be beneficiaries of the results of the Activity and what would potential business case look like if applicable? - delete this line after using the template#

We’d like to pilot FEUDAL to provide a way for communities or infrastructures to integrate services that require provision of accounts. For this, we will provide the central instance, support on integration of services and consider developing required extensions.

Interest in testing this the context of eduTEAMS

    • Deliver a test installation into two or more independent installations. (We already have two in germany, built up by national funding. Using those is not the point, since this would not verfiy the approach taken)
    • Deliver feedback for improvement
    • Verify that from the policy point of view the intended flows can work as envisaged.
  • Metrics for success
    • 100% Success is when an involved local site administrator agrees to integrate the test-installation into a production system.
    • 80% Sucess is when the architecture and design decisions are approved (likely with minimal feedback), but ad-hoc no site willing to integrate with production can be found
      • This is the expected minimum outcome of the project
    • 50% Success is when major components or the architecture are found to be invalid and useless
  • Participants:
    • Resource sites: partners willing to organise access to their site via feudal
    • Central site: partner willing to operate the central components
    • eduTEAMS: we need to integrate with the eduTEAMS ecosystem in term of authentication and group management
    • A Virtual Organisation (VO), i.e. group of participants.
      • That groups PI would manage the group membership in eduTEAMS.
      • Members of the group would test access to provided resources at the sites
  • Activity once users can log in to accounts provisioned on remote resources
  • Dissimate results amoung research communities and including in the InCommon Trusted Access Platform working group

Activity Details

Panel
titleTechnical details

The activity will contain the following steps:

  1. Find at least a set of three partners willing to participate
    1. two of them should ideally be willing to provide access to existing resources (e.g. unix or HPC clusters).
    2. one of them should be willing to operate the central feudalBackend and feudalWebclient component
  2. Integration:
    1. the resource sites would need to install a feudalClient (for connection to backend) and to adapt/implement a feudalAdapter (for implementing the incoming provisioning/deprovisioning events to take effect on their sites)
    2. the central site would need to install feudalBackend and integrate with eduTEAMS
  3. Group Management
    1. After initial testing, a PI would be given admin rights for one group in eudTEAMS, so he can add members
    2. The sites would support this group in their feudalClients
  4. Access
    The members can then use the following flow:
    1. Register in the VO
    2. Provision their Accounts via FeudalWebclient (or commandline)
    3. Directly access the resources


Panel
titleBusiness case

Feudal should make it easy for

  • resource providers to provide access to their resources: Provider specifies the group that is authorised. Group management itself is outsourced to the group membership component of the community AAI (e.g. eduTEAMS)
  • communities to have a consistent authorisation at multiple (*nix) resources: Everybody who is in the group, has access to a given resource
  • All the complicated bits in the middle (usernames, unix-UIDs, local policies) are handled by FEUDAL.


Panel
titleRisks
  • New concept of user provision → Unknown how many resource providers might adopt this solution
Panel
titleRisks

#Are there risks that influence either the implementation of the activity or its outcomes? - delete this line after using the template#

<Enter here>


Panel
titleData protection & Privacy

FEUDAL receives all those information (via AccessToken and Userinfo Endpoint) that the OP releases. This is typically:

  • Name, Email, Affiliation, RAF-Assurance
  • VO/Group Memberships
  • Credentials (such as ssh-keys)

This information is stored in FEUDAL until users are deprovisioned on all resources (i.e. until the business relation is terminated). The Audit Log lifetime is specified by an admin via logrotate.

This information is passed on to the ressources that support a given VO. This is done according to GDPR Art 6.1.f and GDPR Art 45.

Our Privacy Policy for the national instance is online at https://feudal.scc.kit.edu/static/privacy_policy.html

#How do data protection and privacy impact the Activity? Think about e.g. handling of personal data of users - delete this line after using the template#

<Enter here>


Panel
titleDefinition of Done (DoD)


RequirementState

A general prototype is prepared based on the KIT solution

(tick)

The concept and implementation is documented

(tick)

The prototype is integrated and tested with the eduTEAMS platform

(tick)

The source code it provided to the open source community

(tick)

#Please describe here the set of criteria that the product must meet in order to be considered finished. - delete this line after using the template#

<Enter here>



Panel
titleSustainability

#How are the results of the Activity intended to be used? If this requires further engagement, can you describe how you intent to sustain it? - delete this line after using the template#

<Enter here>

The aim of this project is to create an easy to use, adoptable software solution to provision server users and provide this tool to the community.

The solution is ready to be picked up and further developed and used by KIT. They plan to use this software in two "Helmholtz" projects HDF and HIFIS in Germany for the foreseeable future. As part of this we are working on Version 2 of the two central components FeudalBackend and FeudalWebclient. 

Besides this, the solution shall be adjusted to the needs of eduTEAMS. The solution will be provided to the eduTEAMS service task to be integrated into the GÉANT service.

Activity Results

Panel
titleResults
#Please provide pointers to completed and intermediary results of this activity - delete this line after using the template#

Meetings

Date

Activity

Owner

Minutes

January 1, 201713 Nov 2019

Kickoff meeting

Michael Schmidt

-
Every FridayWeekly Scrum

Michael Schmidt

-
Every TuesdayWeekly Chat

Michael Schmidt

-

Documents

Attachments