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

Discuss
1

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
2

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
3

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

4

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.

5

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?

6

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
7

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?

8

@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.

9

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.

10

Hi. any news about this?

1 Like
11

I have a question related to this topic.

e.g.:
YunoHost SSO is on login.domain.tld
My Django App is on app.domain.tld

In the Django App i need the domain name / URI of SSO: login.domain.tld to create login URLs with redirection to back to the app, e.g.: https://login.domain.tld/yunohost/sso/?r=<base64-app.domain.tld-URI>

Exists the YunoHost SSO URI in the scripts as a variables?!?

I didn’t find anything here: Scripts | Yunohost Documentation

12

I found /etc/yunohost/current_host it seems that this is what i need, the “main domain” isn’t it?

So i add this to my _common.sh:

current_host=$(cat /etc/yunohost/current_host)

I will do this:

image
image870×589 47.7 KB

Any better idea?

13

Eeeeh considering your settings.py is in python, I would simply have:

YNH_CURRENT_HOST = open("/etc/yunohost/current_host").read().strip()

?

14

/etc/yunohost/ is not readable by “normal” users. I don’t tested it with a “app-user”, yet.

EDIT: I tested it, and as an “app-user” it works:

root@yunohosttest:~# su - pyinventory
$ id
uid=997(pyinventory) gid=997(pyinventory) Gruppen=997(pyinventory)
$ cat /etc/yunohost/current_host 
testyunohost.fritz.box

Fine!

15

Hmyeah /etc/yunohost/current_host is one of the rare exception :stuck_out_tongue_winking_eye:

/etc/yunohost/ is not totally locked because some non-root users need to access to /etc/yunohost/certs/ where certs are located

An alternative to obtain the info of the “main domain” is to check the return of the command hostname, though this is slightly less reliable as some specific machine may have a different hostname than the main domain …

16

No hostname is not a good idea. In my case it’s the wrong value:

pyinventory@yunohosttest:~$ hostname
yunohosttest
pyinventory@yunohosttest:~$ cat /etc/yunohost/current_host 
testyunohost.fritz.box