# FEUDAL Client Adapter
This code implements the adapter for FEUDAL to communicate with various services, called "backends".
Distributed with the adapter are backends for [BWIDM](ldf_adapter/backend/bwidm.py) and [UNIX](ldf_adapter/backend/local_unix.py).
# Installation
## From PyPi
- `pip install feudalAdapter`
## From Source
- Git clone: `git clone git@codebase.helmholtz.cloud:m-team/feudal/feudalAdapterLdf.git`
- Build package: `cd feudalAdapterLDF; ./setup.py sdist`
- Install package: `pip install dist/feudalAdapter-$version.tar.gz`
# Configuration
The config file contains both the generic config, as well as for specific backends.
## Configuration Template
See [feudal_adapter_template.conf](feudal_adapter_template.conf)
## Config file search path
The config file feudal_adapter.conf will be searched in several places. Once
it is found no further config files will be considered:
- If the commandline argument `--config` is specified, that location is used.
- If the `feudal_globalconf` mechanism is used, it is used. In case there is
also a commandline argument specified, the `globaldconf` has precedence
- If those dont work: the environment variable `FEUDAL_ADAPTER_CONFIG` is used
- If that does not work, these files will be tried by default:
- `feudal_adapter.conf`
- `$HOME/.config/feudal_adapter.conf`
- `$HOME/.config/feudal/feudal_adapter.conf`
- `/etc/feudal/feudal_adapter.conf`
# Input and Output
The FeudalAdapter is designed to work with feudalClient and hence expects
specific json on stdin, and produces specific json on stdout.
The was initially defined [here (feudalScripts)](https://codebase.helmholtz.cloud/m-team/feudal/feudalScripts/)
An extension is implemented, to work with [Motley Cue](https://github.com/dianagudu/motley_cue),
therefore, we feudalAdapterLDF supports additional targets. Most of these
targets do not require the full userinfo to be passed along:
| Target | Description | Input required | Optional input |
|----------------|--------------------------------------------------------|----------------|----------------|
| `deployed` | Make sure the user exists on the system | Full userinfo | ssh-keys |
| `not_deployed` | Make sure the user is not on the system | sub+iss | |
| `get_status` | Get the current status of the user without changing it | | |
A more detailed view of all the supported user states, as well as actions leading to these states, can be found in [states.md](states.md).
# Development
## Debugging
For development you can use the included json files in the examples folder
and pass them on stdin:
```sh
cd [...]/feudalAdapterLDF
export PYTHONPATH=`pwd`
export LOG=DEBUG
cat examples/marcus-deploy.json | ./ldf_adapter/interface.py
```
## Debugging with FeudalClient:
For debugging, run the feudalClient with:
```sh
LOG=DEBUG feudalClient -c ~/.config/feudal/client.json --debug-scripts
```
## Development
feudalAdapter can also be used as a library; For that you can use the
feudal_globalconfig to keep it from parsing your commandline paramenters:
```python
from feudal_globalconfig import globalconfig
globalconfig.config['CONFIGFILE']="/etc/feudal/feudal_adapter_mailping.conf"
globalconfig.config['parse_commandline_args']=False
from ldf_adapter import User
```
# Supported Backends
Backends are simply python modules. The supported backends are in the
[backends](ldf_adapter/backend/) folder.
The backend is configured in the main config file, and may create and use
its own sections therein.
```conf
[ldf_adapter]
backend = my_backend
[backend.my_backend]
foo = bar
# Configuration for your backend goes here
```
Supported backends:
- local UNIX
- [LDAP](LDAP.md)
- bwIDM
## Development
To add a new backend:
- extend the `User` and `Group` classes in the [generic backend](ldf_adapter/backend/generic.py) by implementing all the required abstract methods
- the extended classes **must** also be named `User` and `Group`
- place the classes in a python file in [ldf_adapter/backend](ldf_adapter/backend) (e.g. `my_backend.py`)
- the name of the backend will be the name of the file, and it will be loaded dynamically when used (e.g. `my_backend`)
- use the new backend by setting the `backend` in the `[ldf_adapter]` section in the config file to your new backend name
```
[ldf_adapter]
backend = my_backend
```
- if you need to add any configuration for your backend, add a new section in the config file:
```
[backend.my_backend]
key1 = value1
key2 = value2
```
- define types and default values for the configuration in [ldf_adapter/config.py](ldf_adapter/config.py) (check out the comments on adding a new section)
- you will then be able to use these configuration values in your backend with:
```
from ldf_adapter.config import CONFIG
print("key1: ", CONFIG.backend.my_backend.key1)
print("key2: ", CONFIG.backend.my_backend.key2)
```
# Approval workflow
The `feudalAdapter` also supports a so-called *approval workflow*, which allows site admins to oversee all deployment requests from users, and accept or reject them manually. This workflow uses additional user states (`pending`, `rejected`), as well as a local database for storing deployment requests.
How it works:
- on a request to reach the `deployed` state, a local user (+ its groups) is "reserved" by storing this deployment request in the local database
- the response to this request is a "pending" user
- the site admin is notified of this request (currently supported notification systems: `email`)
- for local_unix backend, notification contains all necessary `useradd`, `usermod` commands
- for ldap backend, notification contains LDIF representation
- the site admin can then accept or reject this request by manually adding the user or, if supported, using "accepted"/"rejected" as state_target
- users are not notified of acceptance/rejection
- subsequent deployment requests for existing users check if there have been changes to the userinfo (e.g. group memberships) and notify the admin only when updates are necessary.
## Configuration
Enable and configure the approval in the config file:
```
[approval]
enabled = True
### 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/feudal/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
```
The `email` notifier will need to be configured, as it will not work out of the box. You'll need an SMTP server for sending emails. If your organisation does not provide one, you can use `gmail` (requires you to create and provide an app password).
A few more configs:
- `sent_from`: the address that the emails will be sent from
- `admin_email`: the email of the site admin that will approve the requests
- `templates_dir`: the folder where the email templates are located. Please make sure that the folder exists and contains all the files from [templates](templates). When installing `feudalAdapter` via pip, this folder is installed at `etc/feudal/templates`, relative to your python path. You are free to modify the content of the files.
To test that your email notification system works, run:
```
feudal-adapter --test
```
# Unit Tests
There are unit tests, located under [tests](tests) (The package structure in `tests` corresponds to
that of the main package). To run the tests, just do:
```sh
tox
```
# Integration with Feudal:
- Edit the FEUDAL Client config file (e.g. `~/.config/feudal/client.yaml`) to include:
```yaml
services:
"mclientservice":
"name": "Demo Adapter"
"description": "Works so well"
"command": "feudal-adapter --conf /etc/feudal/feudal_adapter.conf"
```
------------------------------------------------------------------------
# This goes away sooner or later
# RegApp REST Interface
The rest interface of the LDAP facade supports the calls documented here.
For configuration we use these environment variables
```
USER="username"
PASS="password"
ENDP="https://bwidm-test.scc.kit.edu/rest"
```
## Create user
```
curl --basic -u $USER:$PASS \
-H "Content-Type: application/json" \
-X POST -d '{"externalId":"marcus-test-1"}' \
$ENDP/external-user/create
Benutzer anlegen:
Zum Anlegen reicht eine externalId. Mehr Werte sind im Grunde nicht
notwendig. Allerdings kann man mit diesem Benutzer dann noch nicht viel
anstellen. Die externalId stellt immer das prim??re
Identifizierungsmerkmal dar. Sie ist nicht ??nderbar.
```
## Update user
Use this call to update the user object and to rewrite the generic store in the LDF.
```
curl --basic -u $USER:$PASS \
-H "Content-Type: application/json"
-X POST -d ' \
{"externalId":"test0002","eppn":"test0002@hdf.de","email":"test-diezweite@kit.edu","genericStore": { "ssh_key": "[{'value': 'ssh-rsa AA[..]0R', 'name': 'unity_key'}]" },"surName":"Testfamilie","givenName":"Hans","primaryGroup":{"id":1002637},"attributeStore":{"urn:oid:0.9.2342.19200300.100.1.1":"test0002","http://bw idm.de/bwidmOrgId":"hdf"}}
' \
$ENDP/external-user/update
```
The above, but reformatted:
```
curl --basic -u $USER:$PASS
-H "Content-Type: application/json"
-X POST -d '
{
"externalId": "test0002",
"eppn": "test0002@hdf.de",
"email": "test-diezweite@kit.edu",
"genericStore": {
"ssh_key": "[{'value': 'ssh-rsa AA[..]0R', 'name': 'unity_key'}]"
},
"surName": "Testfamilie",
"givenName": "Hans",
"primaryGroup": {
"id": 1002637
},
"attributeStore": {
"urn:oid:0.9.2342.19200300.100.1.1": "test0002",
"http://bw idm.de/bwidmOrgId": "hdf"
}
}
'
$ENDP/external-user/update
```
## register user for service
```
curl --basic -u $USER:$PASS\
$ENDP/external-reg/register/externalId/test0002/ssn/sshtest
```
Benutzer für einen Dienst registrieren:
curl --basic -u $USER:$PASS $ENDP/external-reg/register/externalId/test0002/ssn/sshtest
Dabei ist es notwendig, dass die vom Dienst geforderten Attribute gesetzt sind. Das ist bei LDAP basierten Diensten normalerweise:
* EPPN
* E-Mail-Adresse
* primaryGroup
* surName, givenName (optional)
* attributeStore:
** urn:oid:0.9.2342.19200300.100.1.1 (Unix UserId - Anmeldename)
** http://bwidm.de/bwidmOrgId (soll "hdf", bzw. konfigurierbar sein)
Der Anmeldename des Benutzers setzt sich nachher aus orgId und UserId zusammen. Also z.B. hdf_test0002
## Find user by unix user name
```
curl --basic -u $USER:$PASS $ENDP/external-user/find/attribute/urn:oid:0.9.2342.19200300.100.1.1/marcus
```
Will return multiple entries for different externalId . This is because multiple externalId can be
mapped to the same unix account.
### Example output
```
[
{
"id": 1007486,
"createdAt": 1531327592699,
"updatedAt": 1533732759215,
"version": 7,
"attributeStore": {
"urn:oid:0.9.2342.19200300.100.1.1": "marcus",
"http://bwidm.de/bwidmOrgId": "hdf"
},
"genericStore": {
"ssh_key": "[{'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4vjkJr6H6eXKE9+dj4epCrcSUQRFih1603/SjJKIA3cpWt0O5TC4qJCQwOcvFXdjCu0Y1YUKrUlmV0D9fezbqNrSEZ30gT5YLhawUT6LukMTKfNLxa5wM7jzAlmhJ4obadTE5G5qpAGz5SbgHRfPdTlctpqmmFeyN/Rw4lgzoJ8+zHFyp2VPB7rCaUdsS+48lkVhYtlIDBogdRLAZp8MpSeHZFjHfpq+XDhHXdKnEtETV2+IQfMxRBj6Bpw7wwWpIkSQuf4VDHTAhb6+KjcBg/TBc46CekKzF6gtKImZZNVIzEXuAW2prHmQRh72+oQFMqhVcnRmDOWGwBEvXzT0R marcus@tuna2013', 'name': 'unity_key'}]"
},
"eppn": "Hardt@unity-hdf",
"email": "no@email.provided",
"givenName": "Marcus",
"surName": "Hardt",
"uidNumber": 900094,
"emailAddresses": [],
"primaryGroup": {
"id": 1002637,
"createdAt": 1525327969976,
"updatedAt": 1525327969976,
"version": 0,
"name": "hdf-test",
"gidNumber": 500573,
"parents": [],
"users": null
},
"secondaryGroups": [],
"userStatus": "ACTIVE",
"externalId": "hdf_61230996-664f-4422-9caa-76cf086f0d6c@unity-hdf"
},
{
"id": 1013939,
"createdAt": 1536046109021,
"updatedAt": 1542101421071,
"version": 8,
"attributeStore": {
"urn:oid:0.9.2342.19200300.100.1.1": "marcus",
"http://bwidm.de/bwidmOrgId": "hdf"
},
"genericStore": {
"ssh_key": "[{'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4vjkJr6H6eXKE9+dj4epCrcSUQRFih1603/SjJKIA3cpWt0O5TC4qJCQwOcvFXdjCu0Y1YUKrUlmV0D9fezbqNrSEZ30gT5YLhawUT6LukMTKfNLxa5wM7jzAlmhJ4obadTE5G5qpAGz5SbgHRfPdTlctpqmmFeyN/Rw4lgzoJ8+zHFyp2VPB7rCaUdsS+48lkVhYtlIDBogdRLAZp8MpSeHZFjHfpq+XDhHXdKnEtETV2+IQfMxRBj6Bpw7wwWpIkSQuf4VDHTAhb6+KjcBg/TBc46CekKzF6gtKImZZNVIzEXuAW2prHmQRh72+oQFMqhVcnRmDOWGwBEvXzT0R marcus@tuna2013-unity', 'name': 'unity_key'}, {'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCh3jF9KUaJXqbnaqaHwGmgXIes0nQMqYFx1N3sa4nfbhyBipjSfCyv3yGHO8yciPIjWGTwPUD+HhczXSOJMGruBwwHCKq2vhrdsWJy/bsCs1iBQN9d0oUyPtn+48UcY6ceZfwGcM3KIOxxMu/nzvgZXme53TXSAWH6VASrCjBSSZ/9JvDaxrgVudOW6a3LE6AZMDsi4YEhdP7FTn4wpFVyCpkIttETX26qDAbD2UuR0KNa42yyDdbzu+3ZAoYmkyCcthgsesEm692r+F6TJnBLFVVAtGiQ21cwM8wKgYUDVMZknBo8QKiLvYhvs3zuCVVKBANYqMCOeO2Z3dQem00t root@tuna2013', 'name': 'marcus'}]"
},
"eppn": "hardt@unity-hdf",
"email": "marcus.hardt@kit.edu",
"givenName": "Marcus",
"surName": "Hardt",
"uidNumber": 900105,
"emailAddresses": [],
"primaryGroup": {
"id": 1009662,
"createdAt": 1533559253589,
"updatedAt": 1533559253589,
"version": 0,
"name": "mytestcollab",
"gidNumber": 500593,
"parents": [],
"users": null
},
"secondaryGroups": [],
"userStatus": "ACTIVE",
"externalId": "hdf_ec0c370f-39a6-4c15-a94e-cf56367e2414@unity-hdf"
}
]
```
## Find user by external id
```
curl --basic -u $USER:$PASS $ENDP/external-user/find/externalId/hdf_61230996-664f-4422-9caa-76cf086f0d6c@unity-hdf
```
### Example output
```
{
"id": 1007486,
"createdAt": 1531327592699,
"updatedAt": 1533732759215,
"version": 7,
"attributeStore": {
"urn:oid:0.9.2342.19200300.100.1.1": "marcus",
"http://bwidm.de/bwidmOrgId": "hdf"
},
"genericStore": {
"ssh_key": "[{'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4vjkJr6H6eXKE9+dj4epCrcSUQRFih1603/SjJKIA3cpWt0O5TC4qJCQwOcvFXdjCu0Y1YUKrUlmV0D9fezbqNrSEZ30gT5YLhawUT6LukMTKfNLxa5wM7jzAlmhJ4obadTE5G5qpAGz5SbgHRfPdTlctpqmmFeyN/Rw4lgzoJ8+zHFyp2VPB7rCaUdsS+48lkVhYtlIDBogdRLAZp8MpSeHZFjHfpq+XDhHXdKnEtETV2+IQfMxRBj6Bpw7wwWpIkSQuf4VDHTAhb6+KjcBg/TBc46CekKzF6gtKImZZNVIzEXuAW2prHmQRh72+oQFMqhVcnRmDOWGwBEvXzT0R marcus@tuna2013', 'name': 'unity_key'}]"
},
"eppn": "Hardt@unity-hdf",
"email": "no@email.provided",
"givenName": "Marcus",
"surName": "Hardt",
"uidNumber": 900094,
"emailAddresses": [],
"primaryGroup": {
"id": 1002637,
"createdAt": 1525327969976,
"updatedAt": 1525327969976,
"version": 0,
"name": "hdf-test",
"gidNumber": 500573,
"parents": [],
"users": null
},
"secondaryGroups": [],
"userStatus": "ACTIVE",
"externalId": "hdf_61230996-664f-4422-9caa-76cf086f0d6c@unity-hdf"
}
```
## Group Management:
In all shortness:
Gibt rudimentäre Infos über die Gruppe aus:
```
https://bwidm-test.scc.kit.edu/rest/group-admin/find/id/<id>
https://bwidm-test.scc.kit.edu/rest/group-admin/find/name/<name>
```
Gibt genauere Infos raus. Z.B. auch die Member und übergeordnete Gruppen:
```
https://bwidm-test.scc.kit.edu/rest/group-admin/find-detail/id/<id>
https://bwidm-test.scc.kit.edu/rest/group-admin/find-detail/name/<name>
```
Legt eine Gruppe an:
```
https://bwidm-test.scc.kit.edu/rest/group-admin/create/<ssn>/<name>
```
<ssn> - Der Service Short Name, des Dienstes, dem die Gruppe zugeordnet ist.
Fügt ein Benutzer einer Gruppe dazu, oder nimmt ihn raus:
```
https://bwidm-test.scc.kit.edu/rest/group-admin/add/groupId/<groupId>/userId/<userId>
https://bwidm-test.scc.kit.edu/rest/group-admin/add/groupId/<groupId>/userId/<userId>
```
<userId> - Datenbank Id des Benutzers
<groupId> - Datenbank Id der Gruppe
# LDAP Configuration
```
BindDN: uid=fileservice-read,ou=admin,ou=login-test,dc=bwidm-test,dc=de
BindPW: $PASS
Base: ou=login-test,dc=bwidm-test,dc=de
```
# Feudal systemd service
To enable a feudal service this might be helpful:
```
systemctl --user --now enable feudalClient@0
```
Raw data
{
"_id": null,
"home_page": "https://codebase.helmholtz.cloud/m-team/feudal/feudal_adapter_ldf",
"name": "feudalAdapter",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "",
"author": "Joshua Bachmeier",
"author_email": "joshua.bachmeier@student.kit.edu",
"download_url": "https://files.pythonhosted.org/packages/cb/2f/01ed55ae0763212831955f4c2eadcd07c0b4096bf2fc7992bac6f90f6006/feudalAdapter-0.7.3.tar.gz",
"platform": null,
"description": "# FEUDAL Client Adapter\n\n\n\nThis code implements the adapter for FEUDAL to communicate with various services, called \"backends\".\n\nDistributed with the adapter are backends for [BWIDM](ldf_adapter/backend/bwidm.py) and [UNIX](ldf_adapter/backend/local_unix.py).\n\n# Installation\n## From PyPi\n - `pip install feudalAdapter`\n\n## From Source\n- Git clone: `git clone git@codebase.helmholtz.cloud:m-team/feudal/feudalAdapterLdf.git`\n- Build package: `cd feudalAdapterLDF; ./setup.py sdist`\n- Install package: `pip install dist/feudalAdapter-$version.tar.gz`\n\n# Configuration\nThe config file contains both the generic config, as well as for specific backends.\n## Configuration Template\nSee [feudal_adapter_template.conf](feudal_adapter_template.conf)\n\n## Config file search path\nThe config file feudal_adapter.conf will be searched in several places. Once\nit is found no further config files will be considered:\n\n- If the commandline argument `--config` is specified, that location is used.\n\n- If the `feudal_globalconf` mechanism is used, it is used. In case there is\n also a commandline argument specified, the `globaldconf` has precedence\n\n- If those dont work: the environment variable `FEUDAL_ADAPTER_CONFIG` is used\n\n- If that does not work, these files will be tried by default:\n\n- `feudal_adapter.conf`\n- `$HOME/.config/feudal_adapter.conf`\n- `$HOME/.config/feudal/feudal_adapter.conf`\n- `/etc/feudal/feudal_adapter.conf`\n\n\n# Input and Output\n\nThe FeudalAdapter is designed to work with feudalClient and hence expects\nspecific json on stdin, and produces specific json on stdout. \n\nThe was initially defined [here (feudalScripts)](https://codebase.helmholtz.cloud/m-team/feudal/feudalScripts/)\n\nAn extension is implemented, to work with [Motley Cue](https://github.com/dianagudu/motley_cue), \ntherefore, we feudalAdapterLDF supports additional targets. Most of these\ntargets do not require the full userinfo to be passed along:\n\n| Target | Description | Input required | Optional input |\n|----------------|--------------------------------------------------------|----------------|----------------|\n| `deployed` | Make sure the user exists on the system | Full userinfo | ssh-keys |\n| `not_deployed` | Make sure the user is not on the system | sub+iss | |\n| `get_status` | Get the current status of the user without changing it | | |\n\nA more detailed view of all the supported user states, as well as actions leading to these states, can be found in [states.md](states.md).\n\n\n# Development\n\n## Debugging\n\nFor development you can use the included json files in the examples folder\nand pass them on stdin:\n```sh\ncd [...]/feudalAdapterLDF\nexport PYTHONPATH=`pwd`\nexport LOG=DEBUG\n\ncat examples/marcus-deploy.json | ./ldf_adapter/interface.py\n```\n\n## Debugging with FeudalClient:\n\nFor debugging, run the feudalClient with:\n\n```sh\nLOG=DEBUG feudalClient -c ~/.config/feudal/client.json --debug-scripts\n```\n\n## Development\n\nfeudalAdapter can also be used as a library; For that you can use the\nfeudal_globalconfig to keep it from parsing your commandline paramenters:\n\n```python\nfrom feudal_globalconfig import globalconfig\nglobalconfig.config['CONFIGFILE']=\"/etc/feudal/feudal_adapter_mailping.conf\"\nglobalconfig.config['parse_commandline_args']=False\nfrom ldf_adapter import User\n```\n\n\n# Supported Backends\nBackends are simply python modules. The supported backends are in the\n[backends](ldf_adapter/backend/) folder.\n\nThe backend is configured in the main config file, and may create and use\nits own sections therein.\n\n```conf\n[ldf_adapter]\nbackend = my_backend\n\n[backend.my_backend]\nfoo = bar\n# Configuration for your backend goes here\n```\n\nSupported backends:\n- local UNIX\n- [LDAP](LDAP.md)\n- bwIDM\n\n## Development\n\nTo add a new backend:\n- extend the `User` and `Group` classes in the [generic backend](ldf_adapter/backend/generic.py) by implementing all the required abstract methods\n- the extended classes **must** also be named `User` and `Group`\n- place the classes in a python file in [ldf_adapter/backend](ldf_adapter/backend) (e.g. `my_backend.py`)\n- the name of the backend will be the name of the file, and it will be loaded dynamically when used (e.g. `my_backend`)\n- use the new backend by setting the `backend` in the `[ldf_adapter]` section in the config file to your new backend name\n ```\n [ldf_adapter]\n backend = my_backend\n ```\n- if you need to add any configuration for your backend, add a new section in the config file:\n ```\n [backend.my_backend]\n key1 = value1\n key2 = value2\n ```\n- define types and default values for the configuration in [ldf_adapter/config.py](ldf_adapter/config.py) (check out the comments on adding a new section)\n- you will then be able to use these configuration values in your backend with:\n ```\n from ldf_adapter.config import CONFIG\n print(\"key1: \", CONFIG.backend.my_backend.key1)\n print(\"key2: \", CONFIG.backend.my_backend.key2)\n ```\n\n\n# Approval workflow\n\nThe `feudalAdapter` also supports a so-called *approval workflow*, which allows site admins to oversee all deployment requests from users, and accept or reject them manually. This workflow uses additional user states (`pending`, `rejected`), as well as a local database for storing deployment requests.\n\nHow it works:\n- on a request to reach the `deployed` state, a local user (+ its groups) is \"reserved\" by storing this deployment request in the local database\n- the response to this request is a \"pending\" user\n- the site admin is notified of this request (currently supported notification systems: `email`)\n - for local_unix backend, notification contains all necessary `useradd`, `usermod` commands\n - for ldap backend, notification contains LDIF representation\n- the site admin can then accept or reject this request by manually adding the user or, if supported, using \"accepted\"/\"rejected\" as state_target\n- users are not notified of acceptance/rejection\n- subsequent deployment requests for existing users check if there have been changes to the userinfo (e.g. group memberships) and notify the admin only when updates are necessary.\n\n\n## Configuration\n\nEnable and configure the approval in the config file:\n```\n[approval]\nenabled = True\n\n### user db location -- default: /var/lib/feudal/pending_users.db\n# currently, only sqlite is used as db for pending requests.\n# user_db_location = /var/lib/feudal/pending_users.db\n\n### notifier -- default: email\n# how to notify admins of incoming deployment requests; supported: email\n# to test that the configuration works, try `feudal-adapter --test`\nnotifier = email\n```\n\nThe `email` notifier will need to be configured, as it will not work out of the box. You'll need an SMTP server for sending emails. If your organisation does not provide one, you can use `gmail` (requires you to create and provide an app password).\n\nA few more configs:\n- `sent_from`: the address that the emails will be sent from\n- `admin_email`: the email of the site admin that will approve the requests\n- `templates_dir`: the folder where the email templates are located. Please make sure that the folder exists and contains all the files from [templates](templates). When installing `feudalAdapter` via pip, this folder is installed at `etc/feudal/templates`, relative to your python path. You are free to modify the content of the files.\n\nTo test that your email notification system works, run:\n```\nfeudal-adapter --test\n```\n\n\n# Unit Tests\nThere are unit tests, located under [tests](tests) (The package structure in `tests` corresponds to\nthat of the main package). To run the tests, just do:\n\n```sh\ntox\n```\n\n# Integration with Feudal:\n- Edit the FEUDAL Client config file (e.g. `~/.config/feudal/client.yaml`) to include:\n```yaml\n services:\n \"mclientservice\":\n \"name\": \"Demo Adapter\"\n \"description\": \"Works so well\"\n \"command\": \"feudal-adapter --conf /etc/feudal/feudal_adapter.conf\"\n```\n------------------------------------------------------------------------\n\n# This goes away sooner or later\n\n# RegApp REST Interface\nThe rest interface of the LDAP facade supports the calls documented here.\n\nFor configuration we use these environment variables\n\n```\nUSER=\"username\"\nPASS=\"password\"\nENDP=\"https://bwidm-test.scc.kit.edu/rest\"\n```\n\n## Create user\n```\ncurl --basic -u $USER:$PASS \\\n -H \"Content-Type: application/json\" \\\n -X POST -d '{\"externalId\":\"marcus-test-1\"}' \\\n $ENDP/external-user/create\n\nBenutzer anlegen:\n\nZum Anlegen reicht eine externalId. Mehr Werte sind im Grunde nicht\nnotwendig. Allerdings kann man mit diesem Benutzer dann noch nicht viel\nanstellen. Die externalId stellt immer das prim??re\nIdentifizierungsmerkmal dar. Sie ist nicht ??nderbar.\n\n```\n\n## Update user\nUse this call to update the user object and to rewrite the generic store in the LDF.\n\n```\ncurl --basic -u $USER:$PASS \\\n -H \"Content-Type: application/json\" \n -X POST -d ' \\\n{\"externalId\":\"test0002\",\"eppn\":\"test0002@hdf.de\",\"email\":\"test-diezweite@kit.edu\",\"genericStore\": { \"ssh_key\": \"[{'value': 'ssh-rsa AA[..]0R', 'name': 'unity_key'}]\" },\"surName\":\"Testfamilie\",\"givenName\":\"Hans\",\"primaryGroup\":{\"id\":1002637},\"attributeStore\":{\"urn:oid:0.9.2342.19200300.100.1.1\":\"test0002\",\"http://bw idm.de/bwidmOrgId\":\"hdf\"}}\n' \\\n $ENDP/external-user/update\n```\n\nThe above, but reformatted:\n```\ncurl --basic -u $USER:$PASS \n -H \"Content-Type: application/json\" \n -X POST -d ' \n {\n \"externalId\": \"test0002\",\n \"eppn\": \"test0002@hdf.de\",\n \"email\": \"test-diezweite@kit.edu\",\n \"genericStore\": {\n \"ssh_key\": \"[{'value': 'ssh-rsa AA[..]0R', 'name': 'unity_key'}]\"\n },\n \"surName\": \"Testfamilie\",\n \"givenName\": \"Hans\",\n \"primaryGroup\": {\n \"id\": 1002637\n },\n \"attributeStore\": {\n \"urn:oid:0.9.2342.19200300.100.1.1\": \"test0002\",\n \"http://bw idm.de/bwidmOrgId\": \"hdf\"\n }\n }\n ' \n $ENDP/external-user/update\n```\n\n\n## register user for service\n```\ncurl --basic -u $USER:$PASS\\\n $ENDP/external-reg/register/externalId/test0002/ssn/sshtest\n```\n\n\nBenutzer f\u00fcr einen Dienst registrieren:\ncurl --basic -u $USER:$PASS $ENDP/external-reg/register/externalId/test0002/ssn/sshtest\n\nDabei ist es notwendig, dass die vom Dienst geforderten Attribute gesetzt sind. Das ist bei LDAP basierten Diensten normalerweise:\n* EPPN\n* E-Mail-Adresse\n* primaryGroup\n* surName, givenName (optional)\n* attributeStore:\n** urn:oid:0.9.2342.19200300.100.1.1 (Unix UserId - Anmeldename)\n** http://bwidm.de/bwidmOrgId (soll \"hdf\", bzw. konfigurierbar sein)\n\nDer Anmeldename des Benutzers setzt sich nachher aus orgId und UserId zusammen. Also z.B. hdf_test0002\n\n## Find user by unix user name\n```\ncurl --basic -u $USER:$PASS $ENDP/external-user/find/attribute/urn:oid:0.9.2342.19200300.100.1.1/marcus\n```\n\nWill return multiple entries for different externalId . This is because multiple externalId can be\nmapped to the same unix account.\n### Example output\n```\n[\n {\n \"id\": 1007486,\n \"createdAt\": 1531327592699,\n \"updatedAt\": 1533732759215,\n \"version\": 7,\n \"attributeStore\": {\n \"urn:oid:0.9.2342.19200300.100.1.1\": \"marcus\",\n \"http://bwidm.de/bwidmOrgId\": \"hdf\"\n },\n \"genericStore\": {\n \"ssh_key\": \"[{'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4vjkJr6H6eXKE9+dj4epCrcSUQRFih1603/SjJKIA3cpWt0O5TC4qJCQwOcvFXdjCu0Y1YUKrUlmV0D9fezbqNrSEZ30gT5YLhawUT6LukMTKfNLxa5wM7jzAlmhJ4obadTE5G5qpAGz5SbgHRfPdTlctpqmmFeyN/Rw4lgzoJ8+zHFyp2VPB7rCaUdsS+48lkVhYtlIDBogdRLAZp8MpSeHZFjHfpq+XDhHXdKnEtETV2+IQfMxRBj6Bpw7wwWpIkSQuf4VDHTAhb6+KjcBg/TBc46CekKzF6gtKImZZNVIzEXuAW2prHmQRh72+oQFMqhVcnRmDOWGwBEvXzT0R marcus@tuna2013', 'name': 'unity_key'}]\"\n },\n \"eppn\": \"Hardt@unity-hdf\",\n \"email\": \"no@email.provided\",\n \"givenName\": \"Marcus\",\n \"surName\": \"Hardt\",\n \"uidNumber\": 900094,\n \"emailAddresses\": [],\n \"primaryGroup\": {\n \"id\": 1002637,\n \"createdAt\": 1525327969976,\n \"updatedAt\": 1525327969976,\n \"version\": 0,\n \"name\": \"hdf-test\",\n \"gidNumber\": 500573,\n \"parents\": [],\n \"users\": null\n },\n \"secondaryGroups\": [],\n \"userStatus\": \"ACTIVE\",\n \"externalId\": \"hdf_61230996-664f-4422-9caa-76cf086f0d6c@unity-hdf\"\n },\n {\n \"id\": 1013939,\n \"createdAt\": 1536046109021,\n \"updatedAt\": 1542101421071,\n \"version\": 8,\n \"attributeStore\": {\n \"urn:oid:0.9.2342.19200300.100.1.1\": \"marcus\",\n \"http://bwidm.de/bwidmOrgId\": \"hdf\"\n },\n \"genericStore\": {\n \"ssh_key\": \"[{'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4vjkJr6H6eXKE9+dj4epCrcSUQRFih1603/SjJKIA3cpWt0O5TC4qJCQwOcvFXdjCu0Y1YUKrUlmV0D9fezbqNrSEZ30gT5YLhawUT6LukMTKfNLxa5wM7jzAlmhJ4obadTE5G5qpAGz5SbgHRfPdTlctpqmmFeyN/Rw4lgzoJ8+zHFyp2VPB7rCaUdsS+48lkVhYtlIDBogdRLAZp8MpSeHZFjHfpq+XDhHXdKnEtETV2+IQfMxRBj6Bpw7wwWpIkSQuf4VDHTAhb6+KjcBg/TBc46CekKzF6gtKImZZNVIzEXuAW2prHmQRh72+oQFMqhVcnRmDOWGwBEvXzT0R marcus@tuna2013-unity', 'name': 'unity_key'}, {'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCh3jF9KUaJXqbnaqaHwGmgXIes0nQMqYFx1N3sa4nfbhyBipjSfCyv3yGHO8yciPIjWGTwPUD+HhczXSOJMGruBwwHCKq2vhrdsWJy/bsCs1iBQN9d0oUyPtn+48UcY6ceZfwGcM3KIOxxMu/nzvgZXme53TXSAWH6VASrCjBSSZ/9JvDaxrgVudOW6a3LE6AZMDsi4YEhdP7FTn4wpFVyCpkIttETX26qDAbD2UuR0KNa42yyDdbzu+3ZAoYmkyCcthgsesEm692r+F6TJnBLFVVAtGiQ21cwM8wKgYUDVMZknBo8QKiLvYhvs3zuCVVKBANYqMCOeO2Z3dQem00t root@tuna2013', 'name': 'marcus'}]\"\n },\n \"eppn\": \"hardt@unity-hdf\",\n \"email\": \"marcus.hardt@kit.edu\",\n \"givenName\": \"Marcus\",\n \"surName\": \"Hardt\",\n \"uidNumber\": 900105,\n \"emailAddresses\": [],\n \"primaryGroup\": {\n \"id\": 1009662,\n \"createdAt\": 1533559253589,\n \"updatedAt\": 1533559253589,\n \"version\": 0,\n \"name\": \"mytestcollab\",\n \"gidNumber\": 500593,\n \"parents\": [],\n \"users\": null\n },\n \"secondaryGroups\": [],\n \"userStatus\": \"ACTIVE\",\n \"externalId\": \"hdf_ec0c370f-39a6-4c15-a94e-cf56367e2414@unity-hdf\"\n }\n]\n```\n\n## Find user by external id\n\n```\ncurl --basic -u $USER:$PASS $ENDP/external-user/find/externalId/hdf_61230996-664f-4422-9caa-76cf086f0d6c@unity-hdf\n```\n### Example output\n```\n{\n \"id\": 1007486,\n \"createdAt\": 1531327592699,\n \"updatedAt\": 1533732759215,\n \"version\": 7,\n \"attributeStore\": {\n \"urn:oid:0.9.2342.19200300.100.1.1\": \"marcus\",\n \"http://bwidm.de/bwidmOrgId\": \"hdf\"\n },\n \"genericStore\": {\n \"ssh_key\": \"[{'value': 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4vjkJr6H6eXKE9+dj4epCrcSUQRFih1603/SjJKIA3cpWt0O5TC4qJCQwOcvFXdjCu0Y1YUKrUlmV0D9fezbqNrSEZ30gT5YLhawUT6LukMTKfNLxa5wM7jzAlmhJ4obadTE5G5qpAGz5SbgHRfPdTlctpqmmFeyN/Rw4lgzoJ8+zHFyp2VPB7rCaUdsS+48lkVhYtlIDBogdRLAZp8MpSeHZFjHfpq+XDhHXdKnEtETV2+IQfMxRBj6Bpw7wwWpIkSQuf4VDHTAhb6+KjcBg/TBc46CekKzF6gtKImZZNVIzEXuAW2prHmQRh72+oQFMqhVcnRmDOWGwBEvXzT0R marcus@tuna2013', 'name': 'unity_key'}]\"\n },\n \"eppn\": \"Hardt@unity-hdf\",\n \"email\": \"no@email.provided\",\n \"givenName\": \"Marcus\",\n \"surName\": \"Hardt\",\n \"uidNumber\": 900094,\n \"emailAddresses\": [],\n \"primaryGroup\": {\n \"id\": 1002637,\n \"createdAt\": 1525327969976,\n \"updatedAt\": 1525327969976,\n \"version\": 0,\n \"name\": \"hdf-test\",\n \"gidNumber\": 500573,\n \"parents\": [],\n \"users\": null\n },\n \"secondaryGroups\": [],\n \"userStatus\": \"ACTIVE\",\n \"externalId\": \"hdf_61230996-664f-4422-9caa-76cf086f0d6c@unity-hdf\"\n}\n```\n\n## Group Management:\nIn all shortness:\n\nGibt rudiment\u00e4re Infos \u00fcber die Gruppe aus:\n```\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/find/id/<id>\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/find/name/<name>\n```\n\n\nGibt genauere Infos raus. Z.B. auch die Member und \u00fcbergeordnete Gruppen:\n```\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/find-detail/id/<id>\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/find-detail/name/<name>\n```\n\n\nLegt eine Gruppe an:\n```\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/create/<ssn>/<name>\n```\n\n<ssn> - Der Service Short Name, des Dienstes, dem die Gruppe zugeordnet ist.\n\nF\u00fcgt ein Benutzer einer Gruppe dazu, oder nimmt ihn raus:\n```\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/add/groupId/<groupId>/userId/<userId>\nhttps://bwidm-test.scc.kit.edu/rest/group-admin/add/groupId/<groupId>/userId/<userId>\n```\n<userId> - Datenbank Id des Benutzers\n<groupId> - Datenbank Id der Gruppe\n\n\n# LDAP Configuration\n```\nBindDN: uid=fileservice-read,ou=admin,ou=login-test,dc=bwidm-test,dc=de\nBindPW: $PASS\nBase: ou=login-test,dc=bwidm-test,dc=de\n```\n# Feudal systemd service\n\nTo enable a feudal service this might be helpful:\n```\nsystemctl --user --now enable feudalClient@0\n```\n\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Adapter to connect provisioning events with a backend",
"version": "0.7.3",
"project_urls": {
"Bug Tracker": "https://codebase.helmholtz.cloud/m-team/feudal/feudal_adapter_ldf/issues",
"Documentation": "https://codebase.helmholtz.cloud/m-team/feudal/feudal_adapter_ldf",
"Homepage": "https://codebase.helmholtz.cloud/m-team/feudal/feudal_adapter_ldf"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "a04b7b98402e4d6ecd1518d820a3ab517ae9782a6c30549fa8024debb8150b45",
"md5": "040edd6e9979765da26ffc8f9ba6eb69",
"sha256": "81d149152bf539e6bd8e6b9e7e096154b14734188ed057064f1cce6355d22f20"
},
"downloads": -1,
"filename": "feudalAdapter-0.7.3-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "040edd6e9979765da26ffc8f9ba6eb69",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": null,
"size": 84447,
"upload_time": "2024-03-08T11:33:24",
"upload_time_iso_8601": "2024-03-08T11:33:24.436445Z",
"url": "https://files.pythonhosted.org/packages/a0/4b/7b98402e4d6ecd1518d820a3ab517ae9782a6c30549fa8024debb8150b45/feudalAdapter-0.7.3-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "cb2f01ed55ae0763212831955f4c2eadcd07c0b4096bf2fc7992bac6f90f6006",
"md5": "ad57cb4e85e889b2130a764e0912f194",
"sha256": "e547a7330cf6358d396b0d6de215ee9b25174972b4fe545e5b94bf0242378bc9"
},
"downloads": -1,
"filename": "feudalAdapter-0.7.3.tar.gz",
"has_sig": false,
"md5_digest": "ad57cb4e85e889b2130a764e0912f194",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 124178,
"upload_time": "2024-03-08T11:33:26",
"upload_time_iso_8601": "2024-03-08T11:33:26.356036Z",
"url": "https://files.pythonhosted.org/packages/cb/2f/01ed55ae0763212831955f4c2eadcd07c0b4096bf2fc7992bac6f90f6006/feudalAdapter-0.7.3.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-08 11:33:26",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "feudaladapter"
}
JSON