[Call for Feedback] SSO portal in multi-domain context - how should it work?

Dear YunoHost users and community ?

working on the SSOwat “user portal” today, I’m wondering about a few things and wonder what the community thinks about the way this portal behaves in the context of multi-domain… So that’s sort of a quite specific use case, dunno how many people do multi domain stuff.

YunoHost handle multiple domains. Those can be related or unrelated … so for instance you may have stuff on

  • foo.tld
  • sub1.foo.tld
  • sub2.foo.tld

and in that case, we can expect that the stuff hosted on those 3 domains are related, e.g. an association hosting multiple services to be used by it’s members, and this is fine.

But you may also have :

  • foo.tld
  • bar.tld

And in that case, we can expect that foo.tld correspond to services for a given association … and bar.tld to another activity (another association, or a personal server, or …) … but users trying to access services or apps on bar.tld will have to authenticate on foo.tld and that is pretty weird !.. because they might not have anything to do with the association’s stuff hosted on foo.tld for example.

Instead, I naively find that it would be much more relevant if :

  • people trying to access stuff on foo.tld authenticate on foo.tld's portal…
  • people trying to access stuff on bar.tld authenticate on bar.tld's portal…

Do you agree with this in general ? Have you already found the current behavior confusing ? If you use YunoHost with multiple domains, could you provide some details on your user cases?

1 Like

Hi,

I agree with you, each domain should have its own portal. However, if there is a way to have more flexibility, I would let the user choose. Maybe we could have a SSO configuration page where we could create portals and assign domains and subdomains to them. (But I have a feeling it would be a scripting nightmare)

My reason is that I am a cheap guy with only one domain. I have the issue with three YNH instances sharing this same base domain, each with their own subdomain. See my previous thread where you helped me.

3 Likes

Hello,

Yes, i agree : if you access to foo.tld you ought to authenticate on foo.tld's portal.

I don’t confuse because i’m the only user and admin with some domains on the same instance, but i think it could be confusing for other users.

The authentication on bar.tld switch to foo.tld that is the main domain witch was the first one to be define during the installation process of the YunoHost instance.

ppr

I think we also need to think about this use case:

We have one main domain for the most app by example apps.domain.tld. And for some specific apps we use a specific domain for some reason. By example some apps need to be installed in the root of the domain so we can’t install more than one app on this domain. So by example you install an app in the root of social.domain.tld.

In this case it look like really strange to need to need to authenticate 2 time.

I also imagine it can be quite complicated to make, but I agree that it would be valuable to be able to configure how each domain’s authentication is handled.
I ran into the same issue that @TitusPiJean’s thread mentions and posted an issue about it some time ago.
It feels to me that there is still something a bit unclear with the multidomain thing.

Just an idea that might be stupid, but what if the SSO was like an app, and you can install it multiple time? Then when you install it you can choose on which domain+path to install it (like one on sso.domain.tld another on otherdomain.tld/ynhsso/).
Then in each app’s configuration, you could choose which SSO you want to use for this app. Each SSO would list apps that it handles, and you’d be redirected to the appropriate one for authentication.
Does that seem to make any sense?

Personally I would only use different domains for certain applications that or collegues access within the same organisation. But the different domain names could make it more convenient to tell certain applications apart.

I understand where the user would be confused. If the user is part of organisation Bar and not of organisation Foo, then getting to their apps only through surfing to foo.org would be weird.
So, users are presented with their own set applications they have access to after they log in, right? So having a login screen also hosted on bar.org would resolve the issue. Except if you want two instances of the same application, one for Bar employees and one for Foo employees (but I don’t know how easy that last thing is achieved currently, perhaps it’s no problem).

1 Like

I don’t manage multiple domains/orgs. I guess if I were using a single machine, I’d put one LXC container with YH inside for each organization, so there’s no bleeding possible. Of course YH aims to be simpler than that!

However I’m currently looking at SSO and admin sites on subdomains, i.e. not the main domain, and maybe there is a common solution for both problems. Currently the SSO redirection targets the main domain, although all domains serve both SSO and admin sites.

Here’s a proposition that I’d like to discuss on:

  1. Each domain would have a boolean property Serve portal, and if true, a string property Portal path.
  2. Each domain would have a boolean property Serve administration, and if true, a string property Administration path.
  3. Each domain would have a property Portal domain or SSO domain (I guess the former is more relevant for non-expert users) which only allows for domains serving portal, and can be itself.
  4. The post-install script would set the main domain as serving portal on /yunohost/sso and administration on /yunohost/admin, and itself as portal domain, in order to keep current behavior by default.
  5. The “Nginx conf writter” and “SSO conf writer” would be changed accordingly. Right now, the admin location conf is in a file which gets included in all server confs, as well as the SSO so that every request goes through the Lua script before reach the location confs. One way would be to only include the block include .../yunohost_admin.conf.inc; include .../yunohost_api.conf.inc; if serving admin respectively. Ssowat access.lua script would be split between the redirecting part and the serving part. In order to customize the SSO domain, it could be implemented by adding the line set $ssowat_url https://...; before access_by_lua_file .../redirect.lua; in the generated conf, the latter would use ngx.var.ssowat_url to retrieve it.

@chateau Maybe a portal domain per app would be overkill compared to a portal domain per domain?

@Koltes Thanks for your suggestions, I had never paid attention that admin panel is actually served on all domains, it’s a bit strange indeed. But it doesn’t seem to be the case of the SSO.
I think it would for sure make sense to have a simple control on which domain displays an SSO, which the administration interface.
Maybe one could even have the SSO and administration interface running under their own domain, for example: login.domain.tld and administration.domain.tld.

I think redesigning that maybe quite some work, and therefore it would make sense to implement it in a way that is really flexible.
Whether it’s by a specific interface in the admin panel (that’s what I understand from what you recommend). Or by making SSO an app and using the standard apps installation and configuration UI. I think anyway both can have pros and cons.

I don’t think the SSO can be per domain, because for example if you log in domain.tld you’re not logged into your cloud served under cloud.domain.tld so it’s not an SSO anymore (and many apps require their own domain to work).
The idea I was suggesting was that you could configure in each app’s settings which SSO allows to log on it (this is in case of a complex usage with more than one SSO, like some examples presented by Aleks), this would just add more possibilities than having a per domain+subdomains SSO like I think Aleks was suggesting.

As per https://github.com/YunoHost/SSOwat/blob/07e8a292f93557016d4720944ced9336b74bfbbf/access.lua#L68 the SSO dashboard shows up for any managed domain at portal_path (default /yunohost/sso/) when the user is logged in. This prevents changing the portal_path to a shorter path, as the SSO takes precedence over everything.

SSO and admin as apps is also a good solution, though it may introduce extra checks, like “there should be at least one app of this type” that’s why I preferred suggesting new properties at a higher level.

IMHO it makes sense that when a user logs into domain.tld she also logs into all subdomains as well (= all apps belonging to one organization). Another wording: I can’t imagine Alice being logged in foo.domain.tld and Bob in bar.domain.tld from the same machine. (Or do you have a use case in mind?) The Set-Cookie header allows for setting a domain, and the cookie is then valid for all subdomains as well.