Managing 1500 users and using nextcloud as authentication backend

Their contact information would also include stuff, like what different kind of services they offer (out of a long list). (Over REST that would be published to other sides). Depending on which section (nextcloud group) they belong to, they would have different options to choose from.
I guess nextcloud is not able to read groups from an authentication server, so groups would need to be allocated in nextcloud.
So I think they profile editing should happen inside of nextcloud, otherwise I would need to also teach the authentication server about those extra attributes.
If you see an easier way of doing that, just tell me :-).

Nextcloud does use groups from Nethserver ldap or AD and user admin is still available in Nextcloud, meaning any user and group created in user admin on Nethserver is available in Nextcloud and users and groups can be created and administered in Nextcloud but they are not added to the Nethserver users.

Interesting. I thought with LDAP there was a way to dynamically pull groups based on some LDAP attribute, but I could certainly be wrong (I’ve never attempted this).

I guess I would explore whether there’s a way to do this dynamically with any of the other authentication protocols. Either way, don’t you have to either teach Nextcloud all your custom attributes, or some other backend? Is it less work to do it in Nextcloud as opposed to something else?

Sorry I don’t have more experience with this, but I’m definitely interested in how this plays out for you. I’d like to implement some SSO stuff in the future.

Another system I was looking at was Gluu which looks promising. They even have a specific Gluu app in Nextcloud, so that might be worth exploring.

Yes that seems to be possible. But as you said, I’d need to teach an other authentication mechanism to do the same, otherwise the whole SSO thing wouldn’t be working (so that the user only needs to login once)… Since I’ve got no idea yet, if SAML, openid and similar stuff even supports something like that, it sounds like an awful amount of work :wink:

I think more and more it would be less work in Nextcloud, since we need to change parts of the interface of Nextcloud anyway, so it means we’d only need to learn one single framework. We also want to be able to Query the data over a REST-interface, and it seems to be very easy to implement that in Nextcloud.

After talking a while with a co-worker, we thing we will use an external authentication provider, it will ease the future integration of services, and even right now it would ease integration of services like dokuwiki and rocket chat.
The address information and additional attributes and editing profile will be done in Nextcloud, since like that, it will be the only interfaces end users get to see. And we don’t need to find out how to get address information and other attributes out of the external providers into nextcloud.
The only real problem I see so far, are again the groups.
Nextcloud will not know that a new user exists before that user logged in. So if an admin adds a new user to the external authentication provider, nextcloud doesn’t know about it, and therefore the admin wouldn’t be able to assign the right groups to that user… I’m still not sure what the best solution would be here…

1 Like

When looking through the code, I accidentaly noticed that there seems to be an integrated oauth2 provider in nextcloud 12…

just as it seems it is not working :frowning:

Yeah, a pity that the build in Oauth2 seems to not do SSO. It seems to work, just not provide any authentification services, which strictly speaking is probably the correct implementation of Oauth2 as the standard isn’t meant for it (but rather the “add-on” to it OpenID Connect). However there is also the “old” Oauth2 plug-in that might be a better starting point to implement a SSO for Nextcloud? https://github.com/soudis/oauth2

You saw this thread? Anyone got DokuWiki integrated with Nextcloud?
I have not really gotten around getting SAML2 to work, but at the end I linked to my repository that allows SimpleSAMLphp to authenticate against a Nextcloud12 database and pull the parameters such as groups etc. Totally untested, but maybe a starting point.

However I am starting to think LDAP might be after all the currently best solution (but my shared host OVH doesn’t have php-ldap enabled :frowning: ). I am just not so sure how advisable it is to use it in the public, i.e. not in an firewalled intranet as it seems to have been intended. Any advise on that?

However I came across these Nextcloud plugin that would allow administrating LDAP users from within Nextcloud:

Another alternative might be this:


Which allows among many other backends to authenticate against an IMAP email server and thus could allow easy integration with some groupware?

More interesting things :slight_smile:
I see that the min version is NC 13, so I wouldn’t expect anything working at this point, and that also explains the lack of documentation.
I wish I could contribute more, but I don’t know very much about single sign on as I haven’t used it before. Maybe as it matures in Nextcloud I’ll be looking into it more seriously.

Forgot to add:


Which is probably what you would need to enable contact details from LDAP.

And likely this to avoid too much administrative hassles:

oh wow thanks a lot for all that information Krischan.

Did you manage to get the dokuwiki authentication working, in a way, that the users don’t need to enter their credentials again after already beeing logged in in nextcloud? So they get logged in "automatically?

ALso those ldap solutions look really interesting. Still the problem of beeing able to log in into dokuwiki (and others) without reentering the credentials. But at least I’d already have all the users in an addressbook…

@linucksrox: it’s also my first time that I fight my way through SSO ;-).

If you don’t believe that the ldap server is safe to setup without a firewall, you can always let it listen only on localhost (127.0.0.1) (assuming, that all the services which need it, are running on the same host). So it wouldn’t be accessible from outside that machine…

I have sort of given up on it for now, but I am also really not an expert on it. However with LDAP it should be easy as Dokuwiki comes with LDAP support bundled I think.

For SAML2… my impression is that with SimpleSAMLphp you would have the following scenario: in different web-apps people would still have to click on the ‘login’ button, but are then silently(?) redirected to the simpleSAMLphp IdP and if already logged-in directly linked back to the page they came from, but now logged in. So not 100% automatic, but quite close. This is also the behaviour with Oauth2/OpenID Connect/ Facebook connect etc.

So I’ve got the whole thing working.
As identity provider I used keycloak. Good documentation, fullfills what I need, it’s really easy to extend with event listeners, can synchronize it’s data easily to a ldap provider. I also looked at gluu, apereo cas, wso2, lemonldap. (mostly documentation is shitty, license somehow unclear, and in the case of apereo cas it looks like a life job only getting the installation working ;-)).
The users need to be setup in keycloak, an admin can do that.
In nextcloud using the ldap user and saml add on it is possible to login over saml, all the users and groups get pulled in over ldap. and it’s even possible to change passwords directly in nextcloud.
I didn’t had any time yet, checking out the addons krischan suggests.

if anybody’s interested I can share my notes on how to setup the whole thing (keycloak, ldap, saml connection etc.). But only next week, now I go home ;-).

2 Likes

Awesome. Thanks for sharing your solution. I’m definitely interested in more details about how you got it all set up, when you have time.

Hmm, maybe I should look again at Keycloak. I kind of overlooked it as it an Java app, but since I want to play with jitsi video bridge, maybe its time to bite that sour apple.

But is LDAP really needed then? What is it exactly that LDAP adds to Keycloak that you need?

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: organizationalUnit

dn: 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.

3 Likes

Ok, I see. So the problem is that the Nextcloud SAML app doesn’t support additional user attributes like full name and groups right? Because I was under the impression that Keycloak and SAML does in general (thus no need for Ldap).
I am currently thinking to have Nextcloud as the central storage of user data and implement SAML more as convenience for login and to link to other SAML/OpenID supporting apps on my server. So I guess if Nextcloud uses SAML only for login, and I let Keycloak fetch the Nextcloud user data out of the NC database via a SQL command, it should be possible to manage the user’s groups etc in Nextcloud and have other apps access it through Keycloak?
To keep the system simple, I want to avoid adding another layer like LDAP to the mix (besides some other technical issues I have with it in my specific setup).

Yes, at least as far as I could see, the Nextcloud saml app doesn’t support it. Saml and keycloak itself would support it.

The way you describe it should work.
I guess you will have to write a custom user storage provider for keycloak, what shouldn’t be too difficult. There’s an example here:


Or propably you could just change the database scheme of the user storage provider already used…

But personaly I think it would be easier to use the ldap solution ;-).

1 Like

About oauth2, I think that once this is solved, it will be usable:

ok now, it’s a while ago… But finally the client wanted to project, and I implemented it.
I documented here how to integrate Keycloak, SAML and nextcloud, without the need to patch user_saml (the above solution needs to patch it).

And here is described how to setup keycloak in a nicer way than above (docker and so on…)

Hopefully it will help somebody to save some hours of work ;-).

3 Likes

I need a dev for a freelance with authentication, if you guys know someone please let me know!