Single sign-on (SSO)/Identity and access management (IAM) for Nethserver

@danb35

Great “Report” you made here!

For people like me, Stephdl and others, PERL is something very positive!

PERL - as an Interpreter Language - is among the fastest language in ripping strings apart. And Big Data, or any database, is a collection of strings in PERL’s view! :slight_smile:

And with CPAN, Perl is capable of extending itself, and updating/compiling PERL modules - only using PERL! Something most languages can’t do!

My 2 cents
Andy

For me, it’s pretty much neutral, but I wouldn’t count myself as competent in anything past BASIC. I don’t know how important the underlying language is; I don’t expect any of us to be modifying any SSO application Neth might go with. But I recall a number of people on the SME side expressing the opinion that Perl was holding the project back, due to their perception of a limited pool of skilled Perl developers.

But regardless of language, Gluu, and Keycloak install their own container system, which then needs a reverse proxy to expose it to the admin and users. That’s a layer of complexity I’d rather avoid if possible.

1 Like

Overall from the observations made, it meets expectations in some aspects, now what’s more important to know and figure out is.

Can the SAML authenticator integrated be used by other third party app providers that make use of SAML for authentication. if the answer to this is yes, then that’s a Tick, and for any cloud services we might need to use that’s supports SAML, then we are good to go.
Essentially this removes the need for a service like Okta for SAML authentication. (based on nextcloud instruction, i am thinking it should be fine for that)

will try to se if we can build one of our internal softwares to authenticate using it. it will really save us alot of trouble. though i must admit, we have never built a software that authenticated with third party systems, just db mostly, especially SAML

The other thing that I am yet to figure out. Will all the users be created in Nethserver, but not able to Edit or Add information on LLNG, or does it have a two way sync of sorts, Not that this is a deal breaker, its just to understand how this platform works.

i ALSO SEE ON THEIR WEBSITE HERE: Applications — LemonLDAP::NG 2.0 documentation (lemonldap-ng.org)

a good number of applications, which we are already using are supported and with a way to integrate. a huge number of them are already modules On Nethserver, and really this would and should give us an upper hand in getting them up to speed on Nethserver.

I have to say that sounds promising even if not very simple to integrate.
I also took a look to Mattermost integration thanks to @oneitonitram link: very cool.

I agree with this approach: create some configuration files depending on the account provider configuration, but without template. Let’s the manager do its job.
Eventually, we can create a reset script that recreates a fresh configuration using cli tool.

1 Like

If those providers will let you specify your own SAML Identity Provider, it seems like it could.

I believe the users would need to be created in Nethserver, and for the most part edits would need to be there too–except for passwords. LLNG will handle password changes, and I’d expect that should work fine with Neth (I haven’t tested it, but as I wrote above, the same crew wrote Self-service Password, and it works fine).

Now, LLNG does support user registration, so I’m sure it could insert a user into the LDAP database–but that wouldn’t create a home directory or otherwise make Neth aware of that user. What we’d really want to do is have it call signal-event user-create with the appropriate parameters. And it would need to do that with root permissions, if I’m not mistaken. I haven’t looked into the registration feature to see if it’s possible to run arbitrary scripts on user registration. Though if that user didn’t need mail on the Neth server, inserting him into the LDAP database might be enough. Makes me wonder if such a user would work with Nextcloud…

I’m thinking that the CLI tool could be a good way to do this too. I’m going to have to think about this some more.

2 Likes

I think I’m getting a handle on how this works. It’s kind of similar, really, to our config database commands, though it operates directly on the config file rather than needing the separate steps of expanding the templates and reloading services. So here’s that I’m thinking…

I expect I’ll be able to create a module for LLNG. It’ll have templates for the virtual host .conf files for the portal and manager, and for the lemonldap-ng.ini file (the only real variables in those are the domain name, and the cert/chain/key files). It will also have templates for a script that will go in /root/lemon_config.sh.

That script will use the CLI tool to:

  • enforce HTTPS on the portal
  • enforce secure cookies
  • remove the sample applications from the portal menu
  • configure LLNG to connect to, and authenticate against, whatever accounts provider you’ve set up in Nethserver
  • configure the access rules for the manager to allow access by your admin user

The intent would be that you’d only run the script once, post-installation, and then any further configuration would be done through the manager. Though I suppose it could be used to reset the configuration, in case you’d borked it through the manager. Once that’s run, you’d log into the manager and configure your relying parties and such from there.

3 Likes

i have a scenario where my current authentication server has a builtin hostname as : auth.domain.tld which is what i have been using to authenticate all other services.
Now if i am to add LLNG, can it work with another subdomain or would i be bale to define it on the servers default hostname.

or generally ill also need to change my current hostname.
i am not sure how much work ill have once i change the hostname but i am sure it will be a bumpy ride.

Wasn’t my plan, but I’ll see if I can put it in there. My plan was to leave the hardcoded hostnames of auth.domain for the portal, and manager.domain for the manager. But it should be something I could do.

1 Like

I think I have it taken care of, conceptually at least, for OpenLDAP–I can pull the relevant values from the config database (or they’re static), massage them as needed, and save them to the LLNG configuration. But having a little trouble with AD, specifically the Base DN.

For local OpenLDAP, the Base DN is a static value of “dc=directory,dc=nh”. For remote LDAP, it’s saved as {sssd}{BaseDN}. For AD, though, neither is the case; it seems to be constructed from the FQDN of the AD server. If the server is `ad.domain.tld`, the Base DN is `dc=ad,dc=domain,dc=tld`. But this value doesn't seem to be stored anywhere in the configuration databases. Do I need to hack this together myself (I guess by pulling apart {sssd}{Realm}), or is there somewhere else I can get this value?

Don’t know if it is correct for AD but take a look at perldoc NethServer::SSSD

{
    use NethServer::SSSD; 
    my $sssd = new NethServer::SSSD();
    my $baseDN = $sssd->baseDN();
}
2 Likes

I was about to reply that it looked like this would just take the value of the baseDN property from the sssd key in the config database–fortunately I tested it first. Yes, it looks like this will do just what I needed. Thanks.

I hope we can have something like that on the next version. Thanks for your job so far.

https://repo.familybrown.org/nethserver/7/repoview/nethserver-lemonldap-ng.html

Installation instructions at the GitHub repo:

It works with local OpenLDAP, at least to the point of being able to log in, and have it recognize the admin user and give him access to the manager. Something’s wrong with the connection for AD, though. Also, no doubt I’m missing something obvious, but the lemonldap config database key isn’t being created. More to follow, no doubt.

OK, simple typo in createlinks. New RPM in the repo to fix that.

6 Likes

Clap clap @danb35 if I can do review or help writing code please say it

2 Likes

The two big things that come to mind are:

  • I haven’t tested it at all with a remote LDAP server
  • The AD connection doesn’t work, and the errors I’m seeing at a quick glance don’t seem too descriptive.

A more minor point is that there’s something stuck in the configuration that’s looking for auth.example.com, and it’s causing errors in running the CLI tool. It’s still making the required changes, though, so I’m less concerned there.

For remote you use port 636 and encryption, starttls is an option

Need to check will play later

1 Like

What I’m doing is pulling the properties from the sssd key and using them to configure LemonLDAP. It should work, AFAIK, but I haven’t tested it as yet.

1 Like

indeed, check nethserver-phpldapadmin/root/etc/e-smith/templates/etc/phpldapadmin/config.php/08Settings_of_Ldap_server at ns7 · stephdl/nethserver-phpldapadmin · GitHub

you have an error in template expansion

Mar 22 20:01:24 ns7loc11 systemd: Reloading The Apache HTTP Server.
Mar 22 20:01:24 ns7loc11 httpd: AH00526: Syntax error on line 72 of /etc/httpd/conf.d/z-lemonldap-ng-manager.conf:
Mar 22 20:01:24 ns7loc11 httpd: SSLCertificateFile takes one argument, SSL Server Certificate file ('/path/to/file' - PEM or DER encoded)
Mar 22 20:01:24 ns7loc11 systemd: httpd.service: control process exited, code=exited status=1
Mar 22 20:01:24 ns7loc11 systemd: Reload failed for The Apache HTTP Server.

the default is $pki props are not set, if not set the template does a default to /etc/pki/tls/certs/NSRV.crt and /etc/pki/tls/private/NSRV.key

please check /etc/e-smith/templates/certificate/crt/00crt

why to not simply use use default certificate expansion with

/etc/pki/tls/certs/localhost.crt
/etc/pki/tls/private/localhost.key

I use it for my module, it follows the default certificate