Versions Compared

Old Version 4

changes.mady.by.user Marcus Hardt

Saved on

compared with

New Version 5

changes.mady.by.user Marcus Hardt

Saved on

Key

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

...

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.


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 Goals from the FEUDAL perspective:
    • Verify the approach taken (VO based approach, architecturearchitectural 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

Activity Details

Panel
titleTechnical details
  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

Not enough resource providers interested?

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

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

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


Panel
titleDefinition of Done (DoD)

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

...