...
Panel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
Panel | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
|
Panel | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||
|
Activity overview
Panel | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
|
...
Panel | ||
---|---|---|
| ||
The activity will contain the following steps:
|
...
Panel | ||
---|---|---|
| ||
Feudal should make it easy for
|
Panel | ||
---|---|---|
| ||
Not enough resource providers interested?
|
Panel | ||
---|---|---|
| ||
FEUDAL receives all those information (via AccessToken and Userinfo Endpoint) that the OP releases. This is typically:
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 |
...
Panel | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
Precondition: Users are managed in eduTEAMS VO Project is done, once users can be provisioned to participating sites. |
Panel | ||
---|---|---|
| ||
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 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. 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 | ||
---|---|---|
| ||
Starting point could be https://feudal.scc.kit.edu |
Meetings
Date | Activity | Owner | Minutes |
---|---|---|---|
January 1, 201713 Nov 2019 | Kickoff meeting | - | |
Every Friday | Weekly Scrum | - | |
Every Tuesday | Weekly Chat | - |
Documents
Attachments