# Configuration for the feudalAdapter (formally known as ldf_adapter)
[ldf_adapter]
### backend -- default: local_unix
# The Backend to use. Currently supported:
# - local_unix
# - bwidm
# - ldap
backend = local_unix
### backend_supports_preferring_existing_user -- default: False
# In case the backend can detect a username issued to a federated
# identifier, setting this to "True" will overwrite the incoming
# preferred_username.
#backend_supports_preferring_existing_user = False
### primary_grup
# Specify a primary group. If unset the user may be prompted to choose
# one, in case more than one are available
#
#primary_group = mytestcollab
### fallback_group
# Specify a group that is chosen, if the user does not come in without any
# group.
# NOTE: This may not be intended, because groups usually reflect the
# authorisation!
fallback_group = nogroup
### additional_groups
# Specify additional groups for the users to be added to.
# Multiple groups can be provided as a space-separated list.
# If the groups do not exist, they will be created by the backend.
#additional_groups =
### interactive -- default: false
# If true, user may be asked to choose a primary group or to
# specify a different username.
# If false, and not primary_group is specified in the config, the first
# available group will be chosen.
#
#interactive = false
[messages]
####################
### Messages section
# Here we select which information will be logged
### log_file -- default: /var/log/feudal/adapter.log
log_file = /var/log/motley_cue/feudal.log
### log_level -- default: WARNING
# INFO will show a few lines inidicating changes to users and groups
log_level = INFO
### log_to_console -- default: only when environment variable $LOG is set
# If set to False: don't log to console, even if $LOG is set.
# If set to True: log to console, regardless of $LOG.
#log_to_console = True
### log_name_changes -- default: yes
# names (of users, groups, issuers, ...) will be changed to conform to
# requirements we found with BWIDM. This is basically standard unix and
# string requirements.
# If set to yes, the name changes will be logged as warnings
log_name_changes = no
### log_primary_group_definition -- default: yes
# If no primary_group configured, and if the user has more than one group,
# we have to pick one group as the primary one. We currently cannot even
# guarantee this will be the same for each deployment
log_primary_group_definition = no
### log_username_creation -- default: no
# When the preferred_username cannot be used, feudalAdapter will try a
# couple of names. If set to yes, we will log all the names that will be
# tried
log_username_creation = no
[approval]
#####################
### Approval Section
# Here we configure the approval workflow for deploying local accounts
### enabled -- default: False
# whether approval is required from local admin to deploy local accounts
# enabled = False
### user db location -- default: /var/lib/feudal/pending_users.db
# currently, only sqlite is used as db for pending requests.
user_db_location = /var/lib/motley_cue/pending_users.db
### notifier -- default: email
# how to notify admins of incoming deployment requests; supported: email
# to test that the configuration works, try `feudal-adapter --test`
notifier = email
### [notifier.*] configurations specific to each notifier
[notifier.email]
################
### configure email notifier (via SMTP)
## smtp server for sending emails -- default: localhost
## examples: smarthost.kit.edu, smtp.gmail.com
# smtp_server = localhost
## port smtp server listens on -- default: 25
## gmail SSL port: 465
# smtp_port = 25
## use ssl -- default: False
# use_ssl = False
## email address to send the notification emails from -- default: admin@localhost
## can use a test gmail address
# sent_from = admin@localhost
## password of email the notification emails are sent from -- default: None (no login needed)
# required with test gmail address: create app password
# sent_from_password =
## email address of admin in charge of approving deployment requests -- default: admin@localhost
# admin_email = admin@localhost
## directory containing templates for notification emails -- default: /etc/feudal/templates
templates_dir = /etc/motley_cue/templates
# [notifier.courier]
################
### configure Courier notifier
## api key
# api_key =
[assurance]
#####################
### Assurance Section
# here we configure the assurance requirements that users must fulfill
### prefix
# The common prefix of the assurance claims used.
# This is prepended to every value that does not start with 'http[s]://'
#
prefix = https://refeds.org/assurance/
### require
# Specify the required assurance of a user to be let into the system.
# This can be an arbitrarly complex boolean expression of claims that need to be
# satisfied.
# Supported operatiors are:
# - '&' logical and
# - '|' logical or
# - '(' and ')' for parenthesis.
# Each terminal is a string(-suffix), which might be contained in the users
# eduperson_assurance.
# Special terminals are:
# - '+' any claim
# - '*' always satisfied.
#
# Examples for the REFEDS Assurance Framework: (for reference and details see https://refeds.org/assurance)
# require = profile/espresso -> Require that all users have the espresso profile
# require = * -> Allow any user, regargdless of their assurance
# require = + -> Allow any user, as long as they have an assurance claim
# require = profile/espresso | -> Photo-ID was verified against an up-to-date goverment database
# IAP/medium & -> Photo-ID was verified by a trained professional
# ID/eppn-unique-no-reassign | AND the eppn is unique and won't be reassigned
# IAP/low -> User has an account at a university
# ID/eppn-unique-no-reassign | AND the eppn is unique and won't be reassigned
# https://aai.egi.eu/LoA#Substantial | -> Photo-ID was verified by a trained professional
# profile/cappuccino -> Photo-ID was verified by a trained professional
# AND the eppn is unique and won't be reassigned
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
### verified_undeploy -- default: false
# Block undeployment for disallowed users. Useful to forbid a user removing an
# account after he lost authorisation for the service
#verified_undeploy = False
### skip -- default: no
# Skip assurance checking and assume assurance is sufficient.
# USE WITH CARE AND ONLY IF YOU KNOW WHAT YOU ARE DOING!!!
skip = Yes, do as I say!
###################################
### Username Generator
#
# The Username Generator is only used when ldf_adapter.interactive is
# false. This is because with ldf_adapter.interactive users can specify
# their own username.
#
# Username Generateor configures the way in which usernames are generated
# The name generator has different modes, each of which may require
# Additional configuration
[username_generator]
### mode -- default: friendly
# These modes are currently available:
# - friendly: Friendly implements a list of strategies that are tried one
# after another. The input is based on different claims of the
# incoming userinfo object:
# - preferred_username claim (if present)
# - combine a varying number of letters of given_name + family_name
# - email-address if all else fails
# - pooled: Pooled implements the pool-account behaviour known from "the grid"
# I.e. we use the primary group name and append the digits, in the
# order of incoming users.
# Unfortunately, with OIDC group names may be much longer.
# Therefore, a specific prefix may be configured.
#
#mode = friendly
mode = pooled
### pool_prefx -- default: primary group name of the user
#pool_prefix = pool
### pool_digits -- default: 3
# The number of digits to use
#pool_digits = 2
### strip_sub_groups -- default: no
# Federated group names may be unique, which can make them very long,
# while POSIX only allows 32 characters. We are truncating groups.
# Example:
# This entitlement: urn:mace:egi.eu:group:eosc-synergy.eu:admins:role=member#aai.egi.eu
# is mapped to : egi-eu_..-eosc-synergy-eu_admins
# As you can see, subgroups are used to form the POSIX group name.
# The strip_sub_groups can help, but you will loose the information about
# the subgroups.
# Use with care
#strip_sub_groups = no
##########
### GROUPS
# Define strategies for group creation
[groups]
### policy -- default: all
# The policy defines which (or how many) groups are created.
# These policies are currently supported
# - all: Create all available groups in user's metadata,
# automatically mapped to a unix-name
# - listed: Create only those groups that are specified in the
# config-variable "supported_entitlements"
#
policy = all
### supported_entitlements
# A list of the subset of entitlements that will actually be created. The
# entitlements will be mapped to groups, depending on the "method" and
# "map" parameters (see below).
# Regular expressions are supported.
#
# supported_entitlements =
# urn:mace:egi.eu:group:eosc-synergy.eu.*
# supported_entitlements =
# urn:mace:egi.eu:group:eosc-synergy.eu.*
# urn:mace:egi.eu::.*kit.edu.* # includes group and res entitlements!
# urn:mace:egi.eu:group:mswss.ui.savba.sk:admins:role=owner
### supported_groups
# A list of the subset of (incoming) groups that will actually be created.
# supported_groups = users
# Developers
# test.vo.*
# .*Example.*
# Helmholtz-member
# wlcg-test
### method -- default: classic
# The method used for mapping entitlement names to group names
# - classic: The default way until version v1 (Aug 2023)
# - regex: Define a list of regular expressions to map entitlements to
# group names using the configuration variable "mapping"
# - Comments are stripped before matching
# - regular expressions are supported (but may yield unexpected
# results.
# - CAUTION order matters: the regular expressions are applied
# one after another!
# - Additional replacements for making group names unix
# compatible are applied afterwards.
#
method = classic
# method = regex
# mapping =
# # ^.* -> group # map all entitlements to group "group"
# :role=(owner|member) -> # remove all role=member and role=owner entries
# :role=v.* -> :vmop # All groups starting with v map to vmop (for the sake of example)
# :role= -> : # all other roles: map to :
# # :vm_operator -> :vmop
# :admins -> :adm
# urn:mace:egi.eu:group:eosc-synergy.eu -> synergy
# urn:mace:egi.eu:group: -> egi_
# data.kit.edu: -> kit:
# eosc-synergy.eu: -> synergy:
# instruct-eric.eu: -> instruct:
# perfmon.m.d.k.e:adm -> perfmon:
# [\.:] -> - # convert . and : to - (for general unix compatibility)
# EOS -> eos # and to avoid warnings
[login_info]
# Static information displayed to the user when deployed to a service.
# Each key and value field will be shown to the user in the "Credentials"
# screen.
# ssh_host defaults to "localhost" when missing
# ssh_user is usually filled by the backend
# all other information is optional and can be extended with any desired information
#
description = Local SSH Test Service
login_help = Login via `mccli ssh {ssh_host}`.
ssh_host = test-host
###################################
### Backend specific configuration.
# You can find available backends in the
# feudalAdapter/ldf_adapter/backends folder.
#
# Each backend may have multiple sections.
[backend.local_unix]
# Configuration for the local_unix backend
### shell -- default: /bin/sh
# The unix shell to use
shell = /bin/bash
### home_base -- default: /home
# The base directory for users' home directories
# home_base = /home
# deploy_user_ssh_keys -- default: yes
# Allows using ssh keys, when they are found in the deployment request
deploy_user_ssh_keys = no
# punch4nfdi -- default: no
# If set to yes, we will use the punch4nfdi-specific method to translate group names
# punch4nfdi = no
## post_create_script -- default: None
## A script to be executed after a user has been created
# this script can be a shell script or a python script
# and will be run with root privileges
# the script will be called with the username as the first and only argument
# post_create_script = /path/to/script.sh
## shadow_compatibility_function -- default: default
# The methos used, to ensure user and group names are compatible with the
# /etc/shadow mechanism.
# WARNING: Changing this on an installation with existing users and groups
# will create new users according the new code, and re-create all
# groups with the new code. Moving existing users to the new
# groups needs to be done manually
# Possible values:
# - default: should work in all cases
# - v044: compatibility with older (0.44) releases. Use this if you
# installed before July 7 2022
# - punch: implemented for the PUNCH4NFDI project
# shadow_compatibility_function = default
[backend.bwidm]
# Configuration for the bwidm backend
### url
# The base URL of the bwidm API
url = https://bwidm-test.scc.kit.edu/rest
### org_id
# The ID for bwidm. This is used for prefixing user- and group names
org_id = fdl
### log_outgoing_http_requests -- default: false
#log_outgoing_http_requests = false
# HTTP basic auth to connect to BWIDM API
http_user = foo
http_pass = bar
# The name of the service the user should be added to on BWIDM:
service_name = sshtest
## post_create_script -- default: None
## A script to be executed after a user has been created
# this script can be a shell script or a python script
# and will be run with root privileges
# the script will be called with the username as the first and only argument
# post_create_script = /path/to/script.sh
[backend.ldap]
# Configuration for the ldap backend
# The ldap backend can function in 3 different modes:
# - read_only (default): there is read only access to the LDAP, therefore the local accounts
# need to already be created in the LDAP and mapped to the federated accounts;
# read the docs for more on how to map local <-> federated accounts.
# - pre_created: the local accounts already exist in the LDAP, but they are not mapped;
# the feudal adapter should have write access to the LDAP to modify entries in
# order to add the mapping to the federated OIDC account.
# - full_access: the feudal adapter has full access to the LDAP and can add/delete/update
# entries contianing local accounts and mappings.
mode = read_only
# host where ldap server is running, default: localhost
host = ldap_server
# port where server is listening, default: 1389 or 636 if TLS is enabled
# port = 1389
# OPTIONAL: admin credentials to authenticate to the ldap
# NEEDED for modifying the LDAP
# when not provided, anonymous bind is used
# admin user should be fully qualified
# admin_user = cn=admin,dc=cesga,dc=es
# admin_password = adminpassword
# set to true if tls is enabled; default: False
# if set to true, the protocol will be ldaps://
# if set to false, the protocol will be ldap://
# tls = False
# ldap base for user namespace; default: ou=users,dc=example
# can include any number of ou / o / dc entries separated by commas
# user_base = ou=users,dc=example
# user entry attributes containing uids for mapping a user; defaults: gecos & uid
# users have to be have (at least) the following objectClass: inetOrgPerson, posixAccount
# attribute_oidc_uid = gecos
# attribute_local_uid = uid
# ldap base for group namespace; default: ou=groups,dc=example
# can include any number of ou / o / dc entries separated by commas
# group_base = ou=groups,dc=example
#### Options only needed for full_access mode when accounts need to be created
## shell -- default: /bin/sh
## The unix shell to use
# shell = /bin/bash
## base directory for home directories -- default /home
# home_base = /home/curso/
## UID range -- default 1000 -> 60000
# uid_min = 1000
# uid_max = 60000
## GID range -- default 1000 -> 60000
# gid_min = 1000
# gid_max = 60000
## post_create_script -- default: None
## A script to be executed after a user has been created
# this script can be a shell script or a python script
# and will be run with root privileges
# the script will be called with the username as the first and only argument
# post_create_script = /path/to/script.sh
