We’ve got a national society of midwifes with several local society which would like to use nextcloud as their intranet. To share files, national calendars, profiles of members and stuff, chat, and also give the members the possibility to use nextcloud to organize their own work.
There would be about 1500 users. And there doesn’t exist any authentication backend or anything yet.
I was wondering, if anybody has experience, if it is feasible to manage 1500 users (in maybe 10-15 groups) only using nextcloud?
Is it easy to use nextcloud as authentication backend for other applications? I coudn’t really find any information about that in the documentation.
It seems like there already exists the posibility to let prosody (XMPP) authenticate against nextcloud.
We would also like to get Dokuwiki work with it (single sign on would be perfect) (We are able to program ;-)).
Maybe in further future also an imap (dovecot) and smtp (postfix) server which would need to authenticate against Nextcloud.
Or would you recommend do use an other authentication backend, and let nextcloud authenticate against that?
Which one? (It should be easy to manage users, preferably directly out of nextcloud).
I would lean toward a dedicated authentication backend which is designed for that purpose. I’m looking at Keycloak right now. Then you would install the appropriate Nextcloud app to connect to it like this: https://apps.nextcloud.com/apps/user_saml
There’s also the option of Nethserver to consider, it has two different choices for account management and Nextcloud is a supported, integrated module, in addition to a full suite of server modules for groupwork.
Thanks for your answers.
Keycloak looks interesting.
So in nethserver you can manage accounts, using nextcloud? And then you’d be able to use the same accounts for other services? (like dokuwiki)
Our main problem is, that we also want to connect the users with the corresponding contact, so that the user can edit in their profile settings directly their contact details (address, and so on). With an external authentication provider it gets more complicated, to things like, what happens when we delete that user (in the external provider), keep the connection between user and contact, and adding new users and directly enter their contact details.
I would think the user/contact information can be managed from the authentication server. Users would directly log into keycloak for example, and manage their profile settings there. Then you can easily pull any of those details from other applications that authenticate against it.
If having users manage profile details in Nextcloud is a requirement for you, I think you can still do it that way. In an instance I manage (not using single sign on, just Active Directory), you can set up Nextcloud to pull profile data and also write changes back to AD if you want to (we do read only). I would imagine you could do something similar with whatever auth backend you choose.
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
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…
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 ). 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
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.
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 ;-).
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”):
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
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)
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.
). 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?