Keycloak instance

Interface available at localhost:8090 on the host machine.

By default, login credentials will be admin:admin

The Keycloak instance is automatically configured by a mounted realm.json file. This file contains configurations for a client in the "Master Realm" with appropriate permissions to perform actions such as creation of new realms, users and user federation connections.

In dev-settings.toml appropriate settings for the KEYCLOAK_BASE_URL, KEYCLOAK_ADMIN_CLIENT and KEYCLOAK_CLIENT_SECRET are set.

The purpose of the Keycloak instance is to use its User Federation support. When an LDAP configuration is set in OSdatascanner, we create a "User Federation" in Keycloak which imports data from e.g. Active Directory. Finally, we import this data to Django.

Note

We also use Keycloak for Single Sign-On. There's more on that in the Single Sign-On section

Setting up OpenLDAP

OSdatascanner's development environment incorporates the OpenLDAP server, which should be used to work with the system's organisational import functionality. Setting up OpenLDAP is a little complicated, though; even though the "L" stands for "lightweight", LDAP is an old technology that doesn't feel very lightweight.

We suggest two ways of defining an organisation in OpenLDAP:

  • through the phpLDAPadmin frontend, also included in the development environment. This is a fairly self-explanatory but clunky UI for much of LDAP's functionality; or

  • through an external LDAP client program, such as those provided by the Ubuntu/Debian package ldap-utils.

If you wish to access the phpLDAPadmin it will be accessible on the host machine at localhost:8100

Credentials will be cn=admin,dc=magenta,dc=test:testMAG

External LDAP clients

The development environment's OpenLDAP server is also exposed to the host system on port 387, the usual port for LDAP servers. That means it's fairly easy to interact with it from outside the Docker universe.

LDAP has a standard text format, known as the LDAP Data Interchange Format, for representing objects in the organisational hierarchy. We can define an organisation in this format and then give it to a tool like ldapadd in order to import it into the LDAP world:

$ cat <<END > organisation.ldif
dn: ou=Test Department,dc=magenta,dc=test
objectClass: organizationalUnit
ou: Test Department

dn: cn=Mikkel Testsen,ou=Test Department,dc=magenta,dc=test
objectClass: inetOrgPerson
cn: Mikkel Testsen
givenName: Mikkel
sn: Testsen
mail: mt@test.example

dn: cn=Hamish MacTester,ou=Test Department,dc=magenta,dc=test
objectClass: inetOrgPerson
cn: Hamish MacTester
givenName: Hamish
sn: MacTester
mail: hm@test.example
END
$ ldapadd -D cn=admin,dc=magenta,dc=test -w testMAG -f organisation.ldif 
adding new entry "ou=Test Department,dc=magenta,dc=test"

adding new entry "cn=Mikkel Testsen,ou=Test Department,dc=magenta,dc=test"

adding new entry "cn=Hamish MacTester,ou=Test Department,dc=magenta,dc=test"