How to make it so my Nextcloud users only need one id / password for multiple services running on my Nextcloud server?

I am implementing Nextcloud for a Linux User Group on a donated VPS. A number of other services are likely to be installed as well, such as gnu social and xmpp. It seems appropriate to try and have all such services work off the same user base. The group is entirely free, donation / volunteer run. We don’t even have a bank account.

This is all new to me - where to start in trying to set up a common user base across multiple apps, starting with Nextcloud? There can be no additional actual monetary cost involved.

I could, for example, install the noted Gluu server. (Except I would also have to install an oxd server, which costs?)

I’m open to installing additional things, but it appears that terms have been shifting all over the place over time, be it SSO, OpenID, SAML (and many more) - it’s not at all clear as to what the latest / largest compatible / capable facility is. Frequently, each ‘app’ well describes itself, but the ‘install this’, ‘glue it to that’, sequence / starting point / step order to get users into Nextcloud is baffling / unclear.

Thanks for any thoughts, especially any ‘How To’ or ‘Getting Started’ links.


Nextcloud version (eg, 10.0.2):
Latest

Operating system and version (eg, Ubuntu 16.04):
$ uname -a ; lsb_release -a
Linux myhost 2.6.32-042stab120.19 #1 SMP Mon Feb 20 20:05:53 MSK 2017 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.8 (jessie)
Release: 8.8
Codename: jessie

  • donated OpenVZ VPS

Apache or nginx version (eg, Apache 2.4.25):
$ source /etc/apache2/envvars ; /usr/sbin/apache2 -V
Apache/2.4.10 (Debian)

PHP version (eg, 5.6):
$ php5 -v
PHP 5.6.30-0+deb8u1 (cli) (built: Feb 8 2017 08:50:21)

2 Likes

If it is just a plain login, LDAP? Do you want/need SSO?

@LukasReschke could perhaps recommend some solutions?

If it is just a plain login, LDAP?

A number of other services are likely to be installed as well,

So it doesn’t seem like plain LDAP is likely to do it - not sure I can count on all future additional apps being LDAP aware.

I’ve installed OpenLDAP / been playing with it / am successfully using it with Nextcloud, however - what isn’t immediately / intuitively apparent is … there’s no way to maintain it. e.g. Nextcloud won’t populate LDAP, only suck from it.

Therefore … ‘something else’ is also needed. And if ‘something else’, it may as well be a ‘current’ / ‘widest functionality’ ‘something else’ as currently makes sense. The question being … what is < that >?

[e.g. Reading the Gluu server links, Gluu has a registration service / front end. May not be pretty, but at least contains an OOB proof of concept / viable path.]

Do you want/need SSO?

Intuitively, it feels like only that (SSO) makes sense. However, any amount of reading reveals that SSO is a moving / ambiguous term. OpenID, OAuth, SAML, SSO, all start flying around - often with multiple possible solution paths, none of which are an obvious current: Step 1. Install < this >; Step 2. Install < that >; Step 3, populate < this > with < that >; Step 4. Configure nextcloud via < some > addon to ask < this > if < they > may enter.

e.g. The way Gluu is presented here it’s a magic bullet (just install it and you’re good to go - e.g. includes it’s own LDAP back end) … until you hit the ‘needs oxd server’ (which nobody has confirmed / that that part of the free Gluu server solution observation isn’t free). vs It feels like Gluu could be installed then accessed via the SAML addon - without oxd. [But have seen no mention that that’s possible / viable / reasonable / appropriate.]

@LukasReschke could perhaps recommend some solutions?

Would be appreciated.

LDAP is very old and supported by many applications. Sure, you would have to manage your user accounts within LDAP. But you could as well use your mail server to authenticate against LDAP, …

For other services it really depends what they support. Many large organisations (such as universities) rely on LDAP. So many products have this support but check all the other services you want to run.

@JasonBayton do you have some ideas?

2 Likes

SAML/OpenID and others you mention are much newer and lesser-supported than LDAP generally as far as I know.

SSO - Single Sign On - is an umbrella term for all means of authentication that can be centrally managed - it isn’t its own thing.

Corporate experience tells me LDAP is the way to go and user management is always managed independently to services that use it. Normally services will only ever get read access to an LDAP server anyway, so if NC had for some reason implemented a 2way sync it would go largely unused.

We can’t tell you which with method to go for, so I’d suggest rounding up all the services you want to implement and find out what they all support for authentication. Once you know, we can take it from there.

1 Like

Your note made me realize … if such things as, say, Gluu, also provide LDAP, and a registration method that populates that LDAP … Nextcloud could use its LDAP directly, rather than through a SAML or Gluu addon. D’oh!

In the mean time, it would be very useful to have confirmed that the ‘advertised’ Gluu free server + Nextcloud addon does/n’t require oxd server and is/n’t completely implementable without monthly cost.

[quote=“JasonBayton, post:5, topic:14010”]
… user management is always managed independently to services that use it.[/quote]

So, remembering that this is a VPS, and a Linux User Group (i.e. no corporate / organization here utilizing internal infrastructure, just multiple disparate members of the public) …

What would one use for such user management? Where the users would be managing themselves by connecting a service running on the same VPS.

Assume SSO.

What is the current best practice sequence of steps (Install < this > then < that > then < do this >.)?
[being a VPS, etc., etc.]

I know SSO, as I mentioned that’s the umbrella term :wink: I mean you need to find out what, under SSO, your other apps support. We know Nextcloud does LDAP​ (and I think others), but if the others don’t, LDAP would be a waste of time; we need to find a common auth method.

I know it’s one VPS and that’s fine. Managing it independently doesn’t mean another server, it just means you’ll use a different set of CLI commands to manage users to what you do for other stuff.

When we know what your other services support then an informed decision can be made. Until then we could say any number of authentication services without knowing if they’ll work.

Guys, these are not hard questions. I’m looking for yes || no || go here.

The users would self-manage via < what? >
[They will have no access to CLI, so I must add a < something > for them to access - this must be hands free for me / admins. What are you suggesting that < something > be, based on your prior comments?]

(1) Is the so called / advertised ‘free’ Gluu server actually free upon complete implementation per the Gluu addon notes / instructions?

(2) What is a link to step by step instructions for implementing what is ‘currently’ ‘considered’ to be ‘SSO’ besides Nextcloud on the same server? [I cannot know, e.g., what the users group will want to add tomorrow.]

- the point of ‘SSO’ is one stop shopping for users rather than YAHIPTR - Yet Another Hard Internet Password To Remember. What are the steps to getting there for my users?

The most recent related forum threads hint that the Gluu addon and installing the server per instructions there referenced make it seem that that is the way to go, but I have been unable to get dis/confirmation of (1). If not (1) [free], then (2) = what?

(2) would appear to be the SSO & SAML authentication addon, but what should be installed for it to talk to?

Alternately, am I reading correctly … Install Gluu server (being apparent latest / greatest / most current implementation of all reasonable possibilities for ‘one stop shopping for users’) for most current / capable / compatible < thunk >, and talk to its LDAP from Nextcloud, if no other free way in the mean time - and take advantage of whatever is free / comes later, later? Users can connect to whatever registration facilities Gluu has, do their thing, and when they get to Nextcloud or any other service, they will be known / be able to get in without any further manual intervention?

Please understand you’re asking for us to tell you which SSO method to implement for all of your services, not just Nextcloud. I’m not going to tell you that, because I don’t know what other services you will end up using nor their SSO compatibility. My suggestion for Nextcloud would be LDAP because it’s simple to setup, integrate and easy to manage as an admin, plus has universal compatibility, however since Nextcloud supports Gluu, you’re more than welcome to give that a whirl if the other services also support it.

Users don’t self-manage in the case of LDAP, rather you, the VPS admin, look after the local LDAP domain. You give users their accounts and they take it from there. LDAP doesn’t have a signup system… though Gluu or other solutions may hook into LDAP to be able to do that. But that is far out of scope for the Nextcloud system as it’s not an identity manager, it just ties into a few.

Gluu isn’t a Nextcloud product, but looking at their website they say:

So maybe carry on reading there for more information. That resource will also provide directions for implementing a Gluu server.

If integration between LDAP, Gluu or another identity manager isn’t listed in the docs, you’ll need to look for either a partner document, or a community guide. From what I can see Gluu is quite new on the scene with NC so the best resource for setting that up would likely be Gluu’s documentation. When setup, the plugin can be installed, activated and the Gluu server details populated.[quote=“b_s, post:9, topic:14010”]
Users can connect to whatever registration facilities Gluu has, do their thing, and when they get to Nextcloud or any other service, they will be known / be able to get in without any further manual intervention?
[/quote]

That is the intention and how it’ll work with Nextcloud. But I don’t know if it’ll work with your other services, so you’ll need to check with the community for the other respective services to ensure you can use Gluu, or at least LDAP which can be setup to integrate with Gluu from which other services that only support LDAP can still make use of SSO.

Absolutely, you won’t necessarily need the Gluu plugin if it’s talking directly to LDAP. Other services certainly won’t have the Gluu plugin but may still work in the same way.

Again, the issue here isn’t Nextcloud integration, it’s everything else. You opened the topic asking to have all services you’ll install communicating over SSO: we can only state with certainty what NC will support, just as the communities of other services wouldn’t tell you what NC supports.

Edit 1: The Nextcloud announcement actually points to Gluu for details on installing:

https://gluu.org/docs/deployment

Please understand you’re asking for us to tell you which SSO method to implement for all of your services

No, but I can see why you might say that.

Right now there is a lot of gas out there, result = nowhere to go. For those not in the know, there isn’t even a ‘consider path A, B, or C’ place to start.

OTOH, if I knew what the heck options A, B, or C, were, I could start reading up on them, and begin evaluating what might make the most sense for my particular circumstances. As it stands now, I’m stuck in neutral.

Thus my posing of the questions. Pick the ‘SSO’ topic, and one drowns. Thus posing this question.

My suggestion for Nextcloud would be LDAP

LDAP in and of itself is not a solution. It’s a database. A storage. It’s clear in Nextcloud how to connect to it. But it doesn’t update it. Missing is … how do users populate that LDAP.

however since Nextcloud supports Gluu,

But in and of itself, is it an entire solution, or does it need the for cost oxd server?

Users don’t self-manage in the case of LDAP

Yes, they do, they must, here in this VPS environment. LDAP is a facility I set up. (One of the problems with LDAP is a lack of a real schema from the get go. [Not actually true.] In the sense that “Here’s a user.” doesn’t initially have a landing point.) The user setup must include go to < this link >, ‘register’, get on with your day. This VPS non-corporate environment requires that.

You give users their accounts

No. Not a corporate environment. i.e. No HR wherein at hiring an automatic LDAP population mechanism is triggered. They go to a link, indicate their interest, register, and proceed. Optionally, but not necessarily, there might be an approval mechanism.

LDAP doesn’t have a signup system… though Gluu or other solutions may hook into LDAP

Exactly. But a signup system is a necessity / part of the criteria within the OP. (And goes back to which ones have < that > that people like.)

But that is far out of scope for the Nextcloud system

But not out of scope for the users of this Nextcloud forum, within which we are talking here, who have rich experience using Nextcloud in the real world. (I don’t disagree with your point, for the nextcloud system, wherein appropriate addons are available. And upon which specific questions could be asked.)

Note: You do not need a commercial license (or a support plan) to use the Gluu Server in production.

Which is part of my point - the contradictory information. e.g. They do not say there, a Nextcloud production involving their provided Nextcloud addon.

They do say OpenID Connect SSO by Gluu - Apps - App Store - Nextcloud “you can deploy the free open source Gluu Server.”, the link to which then goes on to say (Homepage link) “Simple Pricing $ 0.33 USD/day for each active oxd installation”, (User Documentation) “Requirements# In order to use the NextCloud APP you will need a standard OP (like Google or a Gluu Server) and the oxd server.” and say elsewhere ‘oxd server’ ‘pricing’.

[Thus my questions in this forum as to anyone’s use / experience of it - as I can’t tell from the contradictory information available whether or not this is snake oil.]

If integration between LDAP, Gluu or another identity manager isn’t listed in the docs, you’ll need to look for either a partner document, or a community guide.

Which is what I have asked for in this thread.

But I don’t know if it’ll work with your other services

Let me worry about that. At the moment I can’t even discern the Nextcloud solution pathways. (Thus the OP.) [From which, the presumably multiple choices to be read up on, the most compatible one could take step 1 … if I knew which solutions’s step 1’s were candidates.]

Absolutely, you won’t necessarily need the Gluu plugin if it’s talking directly to LDAP.

Which only (finally) occurred to me through the process of posing and thinking through this thread. (Talking it out, as it were.)

we can only state with certainty what NC will support

Of course, that’s a given. Except … this is a community, whom’s experiences we all lean on. (I’ve yet to meet an admin that doesn’t have horror stories that they are keen on helping others avoid.)

The Nextcloud announcement actually points to Gluu for details on installing:

Yes, however I’ve not actually asked any installation questions - merely, Nextcloud users … have you found this viable? (And truly free.)

So, back to the original point:

What are people using for SSO solutions installed on the same server as their Nextcloud?

e.g. ‘Shibboleth’ is not an answer. From my going in circles, Shibboleth may be part of ‘a’ solution, but it’s not a starting point. vs ‘X’ implements a Shibboleth server < blah blah blah >. And it was found/not useful.

It’s knowing what ‘X’ is, to go there and start reading to determine efficacy per my environment, that’s the problem.

Put another way …

Through initial experimentation with Nextcloud, and installing OpenLDAP, it -eventually- became apparent that Nextcloud won’t populate LDAP (so users need another registration mechanism, but what), and OpenLDAP does not itself contain a schema (really), nor an interface to which users can get to to insert themselves. [e.g. A stock OpenLDAP schema may permit a person to be added, but as a Unix user, no e-mail field. So < secret sauce > must be added … and then the going up and down the technical facility chain begins. Figuring out which connects to what, and where the ultimate start and step one points are … are what this OP is all about.]

So … given my public Linux user group, how do I get my users into Nextcloud most easily and globally internet happilly way? The answer appears to be OpenID related. But … thus the purpose of the OP.

What is used to implement SSO (that Nextcloud can take advantage of)? ‘LDAP’ is not an answer, it’s a storage mechanism, a back end. The answer may be ‘includes’ or ‘talks to’ an LDAP server, but LDAP is not itself an answer.

What is?

1 Like

@b_s you 'll have to do some research yourself, but I’m happy using openldap for storage and fusiondirectory for managing the directory. If you want to go that route, I’d recommend to start using fusiondirectory from the start, as it is very strict on some of the required structures. It can install all of these structures for you if your directory is empty.

This would of course only bring a ‘centralized account management’ to your domain, which some already consider to be SSO (but I don’t)

Openldap can optionally be mixed with kerberos and maybe also other layers to connect to apps or services to have a real SSO solution (login on your device unlocks all of the required apps/services).

HTH.

1 Like

Thanks for this.

using openldap for storage and fusiondirectory for managing the directory.

This is actually the combination I ended up starting with … the result of which led me to here / the ask of the OP.

‘centralized account management’ to your domain

And that is exactly what is -not- present with this vps install. In essence, the domain is ‘the public’. (In actuality, the majority of the public will have no interest in our Linux User Group vps, though.) Thus, in a large sense, there is no centralized account management. LUG users need to be able to do what they need to, on their own / without my involvement, to get in and avail themselves of whatever facilities the vps ultimately facilitates. [Granted, they will probably need to be approved, but this is after the fact.]

as it is very strict on some of the required structures

Yep. As it should be, adhering to a schema, and all. No complaints there … except, it is inherently oriented towards domains of Linux users - as makes sense. However, it doesn’t even out of the box come with an email address field for a person - as is needed for this use case. [There are messages around this in their forum.]

This would of course only bring a ‘centralized account management’ to your domain, which some already consider to be SSO (but I don’t)

I hear you / can (begin) to take your point.

Openldap can optionally be mixed with kerberos

I notice ApacheDS includes kerberos - perhaps simplifying things.

Regardless, neither FusionDirectory nor ApacheDS are going to fly as a front end for users requesting access.

and maybe also other layers to connect to apps or services to have a real SSO solution (login on your device unlocks all of the required apps/services).

I (have come to) believe that you have that backwards. (As this thread has made me come to understand …) in the end, every ‘app’ has to ask ‘something’ (often itself) ‘is this guy allowed in’? [Let alone, when in, each ‘app’ has settings unique to itself, per user. e.g. ‘Display Name’. Which is to say there is no way around every app needing a per user ‘profile’. So all SSO is saving is the user not having to have yet another userid / password to remember - it’s not the entirety of all user information across all spectrums. (I hadn’t quite grok’ked that at time of OP.)] So, for your statement, it probably should be ‘required apps/services asks the device if it may unlock itself for this person, which triggers that device to ask for a login.’

Although, I take your point, that that device may be willing to accept whom this guy is from other facilities. e.g. Google / OpenID.

@b_s you 'll have to do some research yourself,

And -that- is the question of the OP, still unanswered: research … step one where / what?!?
[That forum participants are using / know works with their Nextcloud installs for one stop shopping on an SSO implementation.]

For me LDAP is widely supported technique and therefor should be preferred.

That’s why the challenge for me is “How to self-manage LDAP users with a web frontend?”

A quick web-search lead me to pwm which is a project licenced GPLv2.


@b_s What’s your opinion on this? Is it worth testing?

[quote=“Hollerauer, post:14, topic:14010”]For me LDAP is widely supported technique and therefor should be preferred.

That’s why the challenge for me is “How to self-manage LDAP users with a web frontend?”[/quote]

I think you have well captured the consensus of this thread - LDAP is the preferred storage backend, the conundrum is what to use for the front end.

I have no experience with this, so can’t speak to it.

TL;DR

In contemplating one’s search for a solution that best fits their use case, two thoughts do occur to me, though:

(1) What / is the schema the back end is happy with, and does it suit your use case. I can’t remember the correct terms off the top of my head, but for example, my initial test installation of OpenLDAP seems inclined towards unix accounts, which lacks a field for email address, instead of inetperson, which has it. [Not to say OpenLDAP requires it, merely that documentation seems to come from that premise, inclining one to think that that’s the perspective to come from.] It can take some grokking to understand and appreciate that inetperson may make more sense for your use case, and is still possible with OpenLDAP. Remembering that LDAP is LDAP, so all such implementations have a great deal of commonality, ApacheDS, on the other hand, seems similarly LDAP inclined, yet ‘tastes’ slightly different. I expect the same is true for most any back end LDAP implementation.

- as one is inclined towards the back end corresponding front end to which the back end seems more inclined (if only within the corresponding documentation, as one is more likely to trust the association rather than venturing off into undocumented variations, risking brokenness and time wastage in discovering so), choosing the front end that most closely matches your use case (and using its corresponding back end [as LDAP is LDAP]) seems more difficult to discern. [Which is the question / challenge / quest of the OP.]

(2) Given LDAP is LDAP, is seems more crucial to choose / find a front end that best matches your use case [and, likely, implementing its correspondingly documented LDAP back end - see brokenness risking, above]. So, for example, if one is looking for self-managed / hands off user registration / maintenance, and users able to leverage their id’s elsewhere, then the Gluu server feels like it may be a more viable option / place to start. [Implementing its LDAP back end as part of the ride - see brokenness risking, above.] However, the Gluu documentation notes it has only a rudimentary front end, and notes expectations that implementers will fashion their own custom front end. [If rudimentary is insufficient for your use case.]

So, if pwm entirely satisfies your use case, both now and your guessed future, and seems more aligned to your use case than anything else, go with it.

However, a quick glance at the documentation shows no reference to SSO or OpenID, so I don’t suspect it will entirely satisfy my use case as described in my OP.

Hey @b_s did you end up anywhere? My head is boiling with the same kind of “reseach”. Any share of experience is welcome.

2 Likes