Well, the advantage of using ldap is, that nextcloud is able to get the groups, a user belongs to, directly out of the ldap directory. It doesn’t seem that the user_saml add on supports that (at least, a grep through all the add on files, didn’t bring up the string “group” anywhere). In general if keycloak also uses the ldap directory, it helps if you want to add applications which don’t support saml or openid. Almost every application will support ldap (especially if you want to tell smtp or imap servers to authenticate against keycloak, that will help a lot).
Telling opencloak to store the data also to a ldap directory, takes maybe 15 minutes to setup as you will see further down.
Here are the notes, how I got the whole thing working, it’s not beautiful, but you should be able to follow them.
keycloak:
download gz files, decompress it.
Start it up with (The offset is only necessary when your port 8080 is already used) (If you want it to listen on all interfaces, add the parameter “-b 0.0.0.0”):
./bin/standalone.sh -Djboss.socket.binding.port-offset=100
it should be available under http://localhost:8180 now
it will accept logins over http only from localhost.
for https, either setup a reverse proxy in apache or whatever webserver you use, or for testing purpose just build up an ssh tunnel (that’s how I did it).
login to keycloak as admin, add new realm. add new user “admin” to the group “admin” in the new realm.
setup of openldap (debian specific):
aptitude install slapd ldap-utils
edit /etc/default/slapd
to accept localhost connections only.
create file /tmp/test.ldif with content:
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnitdn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
execute:
ldapadd -x -D cn=admin,dc=example,dc=com -W -f /tmp/test.ldif
in keycloak:
add new user ferderation provider: ldap
import users: on
edit mode: writeable
sync registration: on
vendor: other
connection url: ldap://127.0.0.1
users dn: ou=People,dc=example,dc=com
bind dn: cn=admin,dc=example,dc=com
bind credential: password
then go to ldap mappers, create:
name: group
mapper type: group-ldap-mapper
ldap groups dn: ou=Group,dc=example,dc=com
in nextcloud:
• install ldap user add on
• settings ldap:
∘ server: 127.0.0.1
∘ port: 389
∘ user: cn=admin,dc=example,dc=com (don’t use admin, use one made only for nextcloud!!!)
∘ base dn dc=example,dc=com
∘ users: ldap query: (|(objectclass=inetOrgPerson))
∘ login attributes: username
∘ only these object classes: groupofnames
∘ advanced: directory settings: base user tree: ou=People,dc=example,dc=com
∘ group display name field: ou=Group,dc=example,dc=com
∘ Enable LDAP password changes per user: true (if we want to allow it)
∘ expert: UUID Attribute for Users: uid
∘ (setup user cleanup, see docu, not necessary for testing)
saml:
in nextcloud:
• activate plugin
follow the manual here, but if you use an ssh tunnel, change domain in urls to localhost.
there’s a small mistake in the manual: just change identifier of the idp entity: to
http://localhost:8180/auth/realms/realmname
(so without protocol/saml at the end)
Manual:
http://www.cloudforms-blog.com/2016/10/nextcloud-and-keycloak-saml.html
Then do:
There is written: I have commented out this code as some suggest for this problem on internet:
FILE: apps/user_saml/3rdparty/vendor/onelogin/php-saml/lib/Saml2/Response.php
/*
if (in_array($attributeName, array_keys($attributes))) {
throw new OneLogin_Saml2_ValidationError(
“Found an Attribute element with duplicated Name”,
OneLogin_Saml2_ValidationError::DUPLICATED_ATTRIBUTE_NAME_FOUND
);
}
*/
So now everything should be working.
Keycloak should still be setup to run as a service on boot, and also it should use a real database to store the user data, not the integrated hdb one (check out the keycloak docs). In openldap you maybe want to add some more indexes and stuff…
At the moment I’m checking out on the keycloak mailing list, why it is necessary to comment out that code in the saml add on. The add on developer states, i’ts a problem on the side of keycloak.