[RFC] Single Sign On

[lasley]

Another thing we need to knock out in this is Single Sign On, which will allow us to maintain users at one central point instead of needing to build out specific application connectors.

I feel that LDAP (Active Directory) via Samba 4 would be the best approach here.

It isn't as fancy as some of the other SSO solutions that exist, but it's compatible with essentially everything out of the box & is the only thing that will also allow users to login to computers with the same credentials.

Another advantage would be that we could use the same authentication backends for server maintenance using SSSD.

This would also allow us to have a product comparative to Amazon Domain Services, which is quite appealing to most small / medium scale businesses.

Assuming we do choose LDAP, we would need the following (WIP):

• Samba 4 Domain Controller template
  • A one-way trust relationship is required between Clouder admin's domain and Clouder customer's domain in order to allow super-admin
• Determine default AD groups for applications (gitlab-admin, gitlab-user, some-other-application-user)
  • These groups would likely be just the container name as a prefix, then -user or -admin
  • Maybe define these via data files & allow for application-specific context. Will need to come up with more examples of all the permissions structures before determining this.
• Code LDAP authentication to all existing templates, base on aforementioned groups
  • Disable default authentication backend if possible
    • E.g. in Odoo we would need to create/edit any non-public/portal users directly onto the LDAP domain
• Base user/application thresholds on the amount of domain users in application groups
• Add a beat to Elasticsearch to obtain LDAP data
  • https://github.com/elastic/beats/issues/184
  • https://github.com/ManUnix/ldapbeat
• LDAP connector for Odoo to manage users, groups, domains, and forests (future thinking, not required initially)
  • A lot of the read logic exists for the basic stuff, but definitely no write
  • It should not cache data

Anyone have any thoughts?

[YannickB]

Hello Dave,

The good old subject of SSO. I think I already say it but according to me it's one of the most important one we have to address and I think we start to have enough global vision to figure the good direction.

I also believe most authentication shall be made through LDAP. Most software have LDAP connector, it's clearly the standard no doubt about it.

In #139 @KaloyanNaumov suggested Gluu as SSO/IDP and it seriously got my attention. It believe it shall be our main SSO component. As you can see in unfinished folder I tried to work on LDAP and CAS before. It was hell, I really think a software which integrate all SSO components (not only LDAP, but CAS, double factor authentication, authorization, SAML and plenty of other stuff) is the way to go so it's easier to maintain. It include an OpenDJ LDAP but it can be replaced, I don't know yet if we shall use it or use Samba 4 as suggested. I suggest working on Gluu template first, and then see from this point if something is missing, I heard your argument for desktop authentication it shall be in our requirement.

The most complex case I think we will need to manage with SSO : Let's say a company want to provide with Clouder a webmail service for individual customers.

• The customer go on the website and subscribe. This create an account on Clouder (res.partner or res.users ?) and an invoice.
• The customer is exported to the LDAP. When the bill is paid, the authorization for webmail access is added on LDAP. If next bill are not paid, the authorization is removed on LDAP but not the account.
• Then the customer try to connect to webmail, webmail check credential and authorization with LDAP, then create account and grant access.

This will allow us to have one base - several paying users, which is the only hosting case Clouder can't handle right now.

Another use case is for gitlab. Clouder create one gitlab project for each deployed Odoo service, customers must have access to theirs service projects but not others. This shall be done through SSO authorization, hence one authorization per service.

I see why you want to think about SSO now, this is because of number of user metric for billing. I agree, it's best to base this metric on the LDAP directly.

Last feature is the Portal feature, this shall be the central access, where the customer login and see a link to all applications he has access. Maybe Clouder itself shall be the portal, I don't know yet it depends if some software already exist for this purpose. This is not a priority, let's first have SSO and LDAP working.

Finally one thing we have to be aware : most opencore project consider LDAP authentication as Enterprise feature. We will often need to redevelop LDAP connector for theses software.

[lasley]

I don't know yet if we shall use it or use Samba 4 as suggested

AFAIK Samba4 just sits on top of an LDAP implementation, and allows for the Active Directory Domain Controller type operation for cleaner integration into Windows environments (Kerberos, GPO, etc).

It include an OpenDJ LDAP

I think we use OpenLDAP internally. Was there any reason you chose OpenDJ?

Where is the Dockerfile for the builds you have already worked on?

Last feature is the Portal feature,

Yeah so this is something I've been thinking of as well. We basically just need an "Active Directory Users and Computers", but for the web. A more basic and contextual form of Adaxes web UI I'm thinking.

Maybe Clouder itself shall be the portal, I don't know yet it depends if some software already exist for this purpose.

We're in uncharted territory for the most part, so I doubt there's something we can just use. I need all of this centralized into a Customer panel, so end game (IMO) everything statistics and management should be avail in the central Clouder controller server.

most opencore project consider LDAP authentication as Enterprise feature

There's typically open source ways allowing this, but is obviously incredibly dependent on the service itself. We can guarantee that if LDAP / SASL / SAML isn't supported, whatever other SSO/IDP won't be either.

[YannickB]

OpenDJ is included inside Gluu, I didn't chose it it's just there : https://www.gluu.org/gluu-server/overview/ My tests were with OpenLDAP, I never moved them under Docker Hub so you can find them in template files : https://github.com/clouder-community/clouder/blob/0.9.0/unfinished/clouder_template_ldap/clouder_template_ldap_data.xml

I don't know yet if Portal and interface to manage user list shall be in Clouder itself, but why not it make sense. We'll see in the end, let's first make work the system under the interface.

[lasley]

Ahhh dunno how I missed that. Ok so as I'm looking deeper at Gluu, this is pretty sexy. They've got some solid Docker docs too.

I think maybe I'll setup a test instance and see what this looks like in action. I think we'll probably need Samba4 in order to cover some uses that I have for Windows stuff, but this nails a lot of the other birds with one stone (like the Web UI).

[YannickB]

Exactly the same reaction than me when I first read it on the roadmap ticket, dunno how I missed it until now

[KaloyanNaumov]

LDAP for user repository is great, but an SSO adds the benefit of passing authentication tokens, so the user is not asked to re-enter credentials over and over.

Oauth2 is supported by most open source apps, and Gluu provides it. SAML is more Enterprise and may not be part of the GPL versions of the applications, but most have the Oauth part of the free versions.

[lasley]

I see the OAuth being complementary to the LDAP because neither SAML nor OAuth provide the means of managing users, they only allow for the authentication and transfer of passport-type info to the underlying application.

I believe we'll still need the LDAP integrations in the applications in order to provide the planned use of group permissions as the central gate for user thresholds. Otherwise, we will have to build out a user management interface definition, an adapter for each service that requires management, and a scheduled task to enforce the users.

Maybe I'm missing something?

[YannickB]

No I think we all agree. SAML, OAuth and LDAP are all complementary.

There are all integrated in Gluu from what I see, with the possibility to be able to use external LDAP if we want.

[KaloyanNaumov]

True, true.

The good is that most Oauth enabled software has automatic enrollment of users. This is beneficial for the apps that don't support LDAP, but only local user DBs ... just saying ...

[lasley]

Dropping this here to remind for later - Odoo OAuth Provider.

Edit Oops although I think I put this in the wrong ticket. Too late now! This will be great with the Clouder sales form though.

[lasley]

@YannickB how often do we see ourselves needing into the Docker containers at a system level? Do we need SSSD on the base Linux image in order to link to the LDAP auth? Or are we good just locking out access altogether on them?

I feel like we might need SSSD, but I'm not entirely sure the architecture of all this at the lower level yet.

[YannickB]

I don't we'll need sssd.

If we need to grant system level access, we have ssh container for this. For example the ssh container in Odoo template, which is linked to data/files/exec containers, useful for giving access to the customers.

Maybe SSSD will be useful in this ssh container but I don't think we'll need it in all containers. In the other containers, we can only connect through the node and then docker exec anyway.

[lasley]

Alright yeah that makes sense, thanks.

Curious - what is the use case for a container with just SSH on it? I think this is a concept I'm missing. You say we would link it to a data or exec, but through what protocol? Or is this literally a FROM whatever_exec in the Dockerfile of the SSH container?

[YannickB]

The SSH give access to data and exec containers, through the filesystem (volume_from argument in docker run command). It's in the container level, not the image level so not FROM whatever

[lasley]

Ahh sweet, thanks for the elaboration!

[KaloyanNaumov]

FYI, there's another IDP/SSO solution, which we are using in a project, i'm involved with:

http://www.keycloak.org/

It's the JBoss/RH IDP. Somewhat easier to deploy, than the Gluu server.

Hope This Helps!