Goal

• 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

Messaging

• 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

Technologies

• 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": [
                "urn:mace:egi.eu:group:covid19.eosc-synergy.eu:admins:role=member#aai.egi.eu",
                "urn:mace:egi.eu:group:eosc-synergy.eu:role=vm_operator#aai.egi.eu"],
            "eduperson_scoped_affiliation": [
                "faculty@KIT"
            ],
            "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

Authorisation

(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 |
      profile/cappuccino

Output

• 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

Questionnaire

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

Deprovisioning

• 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

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

Links

• Productive Instance: https://feudal.scc.kit.edu

  • Depending on your authorisation / assurance you can get a free ssh login!!

• Gitlab: https://git.scc.kit.edu/feudal

• Contact: m-contact@lists.kit.edu

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)