FEderated User Deployment portAL

Lukas Burgey, Uros Stevanovic, Marcus Hardt

November 2020

Feudal: User Provisioning


  • Integrate non-federated services
    • ssh, mysql, s3, ceph, ldap, …
  • Provision local accounts, based on federated Identity
  • Requirements:
    • Respect Local site policies:
      • Username policies
      • Blocked users policies
    • Deprovisioning / User updates
    • Real-time requirements

Our approach FEUDAL

  • Backend
    • Trigger (de)provisioning events to sites
    • Store Status
  • Frontend
    • Web and commandline interface
    • Communication with backend
  • Client
    • Obtain (de)provisioning events from backend
    • Monitored execution of “Adapters”
  • Adapters
    • Implement (de)provisioning events into the local system
    • Examples exist for
      • Local accounts
      • LDAP
      • KIT user management (via REST Interface)
    • Can be customised by site admin

FEUDAL Architecture


  • Rabbit MQ
    • Low latency communication
    • Clients only require outgoing connectivity
    • Privacy-by-design: message-routing
  • Fault Tolerance
    • Clients register via REST
    • Clients retrieve missed messages via REST
  • Dynamic Infrastructure supported
    • New clients (think VM, grid site, …) obtain all deployments


  • Backend: Django/Python
    • Built-in admin and Database usage
    • Django REST framework
  • Frontend: Two REST Implementations
    • Web: Angular / Typescript
      • Asynchronous request handling
    • Cmdline: Go
    • Any other authorised (OIDC) user
  • Clients: Go
    • Static linking for easier deployment to sites
  • Adapters: Any language
    • Three Python based adapters are provided
      • $localhost
      • LDAP
      • KIT user management


How to integrate your service

  1. Register a client with us
  2. Define the service(s) that you have
    • Description of the service
    • Adapter to use
  3. Define your authorisation scheme
    • Virtual Organisations (VOs) to support
      • groups or eduperson_entitlement claims supported
  4. Run the client

What does the client see?

  • Incoming requests contain:
    "state_target": "deployed",
    "answers": {
        "primary_group": "egi-eu_goc-egi-eu" },
    "user": {
        "credentials": {
            "ssh_key": [
                { "id": 48,
                    "name": "id_ed25519.pub",
                    "value": "ssh-ed25519 AAAACa...dXg6ym/ marcus@nemo2019" } ] },
        "userinfo": {
            "eduperson_assurance": [
                "https://aai.egi.eu/LoA#Substantial" ],
            "eduperson_entitlement": [
            "eduperson_scoped_affiliation": [
            "eduperson_unique_id": "d7a53cbe3e966c53ac64fde7355956560282158ecac8f3d2c770b474862f4756@egi.eu",
            "sub": "d7a53cbe3e966c53ac64fde7355956560282158ecac8f3d2c770b474862f4756@egi.eu",
            "email": "hardt@kit.edu",
            "preferred_username": "mhardt",
            "family_name": "Hardt",
            "given_name": "Marcus",
            "iss": "https://aai.egi.eu/oidc/",
            "name": "Marcus Hardt",
            "acr": "https://aai.egi.eu/LoA#Substantial"

Client has full control over provisioning decision!

What does the client see?

  • If the client was offline for a while (or added to the VO later)
    • ALL deployments are sent
      • To make sure that a user that provisioned for all services of a VO will also be in this one
      • Useful if you spin up VMs for the VO


(sorry for being repetetive)

  • Site admin has full control
    • Will only be subscribed to the supported Virtual Organisations
    • Can filter on assurance
      • Example (from an adapter implementation):
    prefix = https://refeds.org/assurance/
    require = profile/espresso |
        IAP/medium & ID/eppn-unique-no-reassign |
        IAP/low & ID/eppn-unique-no-reassign |
        https://aai.egi.eu/LoA#Substantial |


  • Feudal features extensive logging (server and client)
  • Clients can send json dictionaries
    • Server displays key-value to the user
    • Useful for informing the user about
      • username
      • hostname


  • Clients can ask things back to the user
    • Primary group
    • Username already taken


  • Fully supported
  • If a use is removed from a group
    • Feudal sends deprovisioning requests to all clients (that we know should have the user)
  • Deprovisioning requires support by the SP-IdP-Proxy
    • Current work: Specification for supporting this
    • Works already with: Unity

Demo time

What you’ll see:

  • Log in to Feudal

  • Provision a user for a VO

  • Answer the questionnaire

  • Find username / hostname

  • Log in to the service

    • Witness the group memberships
  • Deprovision the user (sorry, by hand for now)

    • Can’t login anymore


Future work

  • Establish service in production at KIT
    • LSDF Storage Service
  • Adapt to other community needs
    • Features can be implemented on request:
      • Support for password transports can be added

Feudal Summary

  • Provisioning + Deprovisioning tool
  • Scalable approach
    • Virtual Organisation (VO) based
    • “Growing VO” supported
    • Fault tolerant provisioning
  • Realtime deployments
    • Rabbit-MQ / http sockets to push information
  • Full control for integration
    • Rich information sets available for sites
      • Assurance, Entitlements, Groups, …
    • Local administrators can filter users
  • Commandline Support
    • All features available via REST interface

Backup Slides

Message Content

  • All info from Userinfo Endpoint
  • FEUDAL adds:
    • List of ssh keys
    • Command (deploy / undeploy)
    • Answers to questions (adapters may ask questions to the users)
  • Messages to backend contain
    • Questions
    • Status (Success/Failure)
    • Login information for the user

Solved Problems

  • Site policy vs. user comfort:
    • Username can be suggested by user
      • Actual username will be generated by site and shown to the user
      • Questionnaire mechanism allows “username already taken” scenarios
  • UID/GID is completely site policy
    • Adapter is written / adjusted by local site admin
    • Can add filtering:
      • Blacklist users
      • Specific UID range for local users (KIT does that)