croit supports a couple of different login solutions, so it is easier to integrate in your existing environment.
All of them are set up inside the croit container, so you will have to edit /config/config.yml.
docker exec -it croit vi /config/config.yml
croit supports a couple of different login solutions, so it is easier to integrate in your existing environment.
All of them are set up inside the croit container, so you will have to edit /config/config.yml.
docker restart croit
LDAP / AD
For LDAP the relevant part of the config file looks like this:
# /config/config.yml ldap: # URL of your LDAP server url: ldap://ad.example.com # enable AD-specific query functionality for improved performance and support for nested groups isActiveDirectory: no # whether to use TLS, default is yes tls: yes # whether to validate certificates, default is yes verifyCertificateChain: yes # follow referrals referrals: IGNORE/FOLLOW # croit binds to this DN to look up users and group members bindDN: CN=croit-service-user,OU=service,OU=accounts,OU=example,DC=ad,DC=example,DC=com bindPassword: secretPassword # base for user lookups on login base: OU=users,OU=accounts,OU=example,DC=ad,DC=example,DC=com # name of the attribute used to search for users and the class name for users # defaults are sAMAccountName/user # the resulting ldap query looks like this: (&($uidAttributeName=$username)(objectClass=$userClassName)) uidAttributeName: sAMAccountName userClassName: user # name of the attribute for the group(s) a user belongs to memberOfAttributeName: memberOf # the full distinguished names of groups that are mapped to admin/viewer roles adminGroupDN: CN=ceph_admins,OU=groups,OU=example,DC=ad,DC=example,DC=com viewGroupDN: CN=ceph_viewers,OU=groups,OU=example,DC=ad,DC=example,DC=com
Open ID Connect (OIDC)
Configure croit at your OIDC provider
At your OIDC provider, you need to add a new client (sometimes called application) for croit.
You should get a client ID and optionally a client secret from that.
You also need to configure your redirect URIs for croit. croit’s redirect URI is /oidc.
Auth0
Configure OIDC on croit
You can configure OIDC providers under the Settings page in the croit UI. Go to Settings, then User Management, then click on the OpenID button at the bottom. Here, you can manage your OIDC providers.
Click on Create to add a new provider. The following fields are available:
-
Name: A human-readable name for this provider, this name will be displayed on croit’s login page.
-
Discovery URL: Discovery/configuration URL of your provider. For example, for Google this would be https://accounts.google.com/.well-known/openid-configuration.
-
Client ID: The client ID for the croit app as provided by your OIDC provider.
-
Client Secret: The client secret for the croit app as provided by your OIDC provider. This is optional, if you use None as client authentication method (see next field), you may omit this value.
-
Client authentication method: Choose what’s configured for croit at your OIDC provider. Basic is usually the default. With Basic, the client secret is passed using HTTP Basic authentication. With Post, the client secret is passed in the request body. With Post, no client secret is configured.
-
Default roles: These croit roles will be assigned to all users from this OIDC provider automatically.
-
Manual roles: If set, roles can be assigned to users manually (on top of the default roles) after they logged it once into croit. Alternatively, if not set, you can specify a role claim/pointer (see next field) to automatically find roles for users.
-
Role claim or JSON pointer: This can either be a claim (e.g. groups, effectively the same as a JSON pointer /groups), or a JSON pointer (e.g. /meta/groups) pointing to a list of roles or groups that the user belongs to, inside the list of claims for the user returned by the OIDC provider. It may also point to a string, which is interpreted as a single role. If you leave this field empty, only the default roles are used (see below). Otherwise, you need to provide a role map that maps the values from the role claim/pointer to croit roles.
For example, if the OIDC provider is configured to send the following claims for a user:
{
"sub": "248289761001",
"name": "Jane Doe",
...
"meta": {
"roles": ["siteadmin", "siteviewer"]
},
}You may configure /meta/roles as JSON pointer, and add role mappings for siteadmin to Admin and siteviewer to Viewer.
Here’s an example of these settings filled out for Google and Auth0 as OIDC provider:
Auth0 OIDC setup example
Google OIDC setup example
Click Create, and croit will attempt to discover the new OIDC provider. Once that succeeded, you can now log in with your new provider. Users logged in via OIDC will be listed on the User Management page.
Troubleshoot OpenID Connect configuration
OpenID Connect discovery fails or is not supported
When adding a new OIDC provider, if you get an error about the discovery request failing, please make sure you provided the correct discovery URL.
In your provider, this URL is typically named “discovery URL” or “configuration URL”, you can also try searching for it online.
If your provider doesn’t support OIDC discovery, you need to host the discovery information yourself somewhere.
You may even use your croit instance itself to do so: Simply put the OpenID configuration JSON into /config/extra-files/openid-configuration-example inside the docker croit container, and the configure your OIDC provider using the discovery URL https:///your.croit.server/api/extra-files/openid-configuration-example.
Role mapping isn’t working as expected
If your users don’t get the correct roles assigned, you can enable debug logging to verify that your role claim/JSON pointer is correct.
This will log your user’s info/claims in croit. This might contain GDPR relevant information.
Run the following command in the Ceph Admin Shell to enable debug logging:
curl -X POST localhost:8081/tasks/log-level -d "logger=io.croit.auth.OidcUserInfo&level=DEBUG"
Now, log in with your OIDC provider (ideally with a debugging/testing user), and check the docker logs with docker logs croit. You can run it inside the management container using:
curl --silent -XGET --unix-socket /var/run/docker.sock http://localhost/containers/croit/logs?stdout=true\&follow=true --output -
The user’s claims will be printed, and you can verify your role claim.
To disable debug logging again, run:
curl -X POST localhost:8081/tasks/log-level -d "logger=io.croit.auth.OidcUserInfo&level=INFO"
