Functional design of the front page

[thijskh]

The current (in 2.0) front page of a SimpleSAMLphp installation presents just a list of available authsources which you can test-login to with no further context, explanation.

Probably this is a confusing landing page. For exising SimpleSAMLphp 1.x users who expected to find the admin interface here and do not see any reference or link to it. For new SimpleSAMLphp users because it's just a list of authsources without any way to know why they are there or what you are supposed to do with it.

I think we need to a new idea of what the root of the SimpleSAMLphp installation page should do and what to display there.

[tvdijen]

As discussed elsewhere this should probably be a list of hosted IDPs..
The current situation IMHO is a design flaw that leaves developers with situations like this; cirrusidentity/simplesamlphp-module-ratelimit#7

Showing hosted IDPs also makes much more sense from the IDP-first point-of-view.

[thijskh]

So if your installation is an SP, what will you display?

[tvdijen]

I'd say in case there are no IDPs configured, we could redirect to the admin-module if enabled...
Or maybe even better, a landing page with some links to our website, github repo, etc. that also has the link to the admin module (if enabled). There is nothing to see or to do for an end-user on an SP.

[jaimeperez]

Maybe we should completely stop assuming what the right thing to display is, and just delegate that to the deployment?

I was thinking we could just provide a configuration option so that you can tell SSP where to redirect in case someone reaches the landing page, which would then open up for any custom use you may want to do of it. This could be provided with web server configuration too, though, and then we would spare adding yet-another-configuration-option.

I'm not too convinced on the idea of redirecting to the admin module if enabled. Not like it's security should rely on obscurity, of course, but for an end-user that accidentally lands there, there's absolutely no reason why they should see any admin-related stuff. That also has the undesired side effect that if the end user lands there and gets redirected to the admin module, they will be prompted for their username and password, and they might type their own password there without realising where they are. In any case, not a huge fan of this alternative.

The reason why we were using auth sources was precisely because in that case you cover both deployment scenarios: IdPs and SPs. It also resonated as a good idea to have a place where the end users can see their data after logging in. However, I agree that this has its drawbacks, and may lead to exposing auth sources that we don't want to expose. Again, we could just offer a configurable list of auth sources to display there, defaulting to none (and an informative message telling the user they have no business to do in there).

[tvdijen]

I would be in favour of the config-setting with a default to some very basic landing page.. That gives implementors the choice to either change the url or override the landing page twig-template in their theme.

[thijskh]

An initial attempt at implementing Tim's suggestion is now done. Hope this brings this issue along so we can see if we're on the right path.

[tvdijen]

Was solved in #1554