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

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.

• Goals from the FEUDAL perspective:
  • Verify the approach taken (VO based approach, architectural design of components, rabbit-mq for transport)
  • Verify the decision of not  using SCIM  for provisioning (we use the unmodified, augmented information of the userinfo endpoint instead)
  • 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

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

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.

Not enough resource providers interested?

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

Precondition: Users are managed in eduTEAMS VO

Project is done, once users can be provisioned to participating sites.

We will use this software in our 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

Starting point could be https://feudal.scc.kit.edu