hostname only from entityID URL

[Peter Schober]

* Szerb, Tamas <toma at rulez.org> [2015-10-13 21:43]:
> I understand this intention, but breaks the standard, since eg:
> 
> http://sp.example.org:800/sp
> and
> https://sp.example.org:4430/sp
> 
> will be considered the same SP as I understand.

You're mistaken. The IDP uses entityID values verbatim, without adding
or removing anything, otherwise it wouldn't interop with anything
else. So besides the fact that you shouldn't put port numbers into
entityID vales (because entityIDs are /names/ not locations) and that
the above are therefore bad choices for entityIDs the IDP will be
perfecly capable to treat those as differently (even if the scheme
were the same).

The exception to this (which you're seemingly hung up about for some
reason) is /not/ for SAML protocol or technical reasons (so refernces
to standards do not apply), but for UX reasons: On the login page the
Shibboleth IDP allows to implement co-branding, i.e., making it clear
to the subject what SP they are in the process of logging in by
showing human-palatable information about the SP. Including -- if all
else fails, i.e., if no mdui:DisplayName, md:ServiceName, etc. can be
found -- a "cleaned-up" version of the entityID.
(Contrary to our implicit assumption the vast majority of SP entityIDs
do not only differ from other entityIDs in port number or scheme.)

But all this is an example config only and you should change that to
what you want and what you think is "correct" for your deployment.

Most ordinary computer users I know couldn't care (or understand) less
when shown the two URLs above.  I.e., they wouldn't know about
differences and what these signify. OTOH, a mdui:DisplayName of "Wiki
Example.org" vs. "HR System Example Org" is very likely to be
meaningful to those same subjects. Which is why people (SAML
deployers, Trust Framework Providers managing SAML metadata for
Circles of Trust) are populating mdui:DisplayName in SAML Metadata,
for example.

> I recommend to remove that line, the standard allows full qualified
> URLs, so the shib IdP should does.

This has nothing to do with standards.  The Shib IDP also
interoperates with SPs including those 99.99% whose entityID values
are in fact URLs (or ugly as the ones given above).

As Rod has pointed out what you're complaining about is meant as (1)
an example configuration that will (2) try several methods to generate
a suitable string for human consumption, based on UX studies.
Cf. https://discovery.refeds.org

Any deployer (including yourself) is free to put whatever they want
into their login.jsp, including the entityID value verbatim!
The documentation already shows how to display the actual entityID
there. If you decide not to follow documentation and advise given here
there's nothing anyone can do for you.

But since I think I and others have explained all of this before that
probably won't answer your quesition (whatever that may be).
-peter