Velocity in new installation of Shibboleth IDP

[Cantor, Scott]

On 6/6/17, 11:24 AM, "users on behalf of Brett Cave" <users-bounces at shibboleth.net on behalf of brettcave at gmail.com> wrote:

> I am busy with a new installation of Shibboleth IDP on Ubuntu 16.04 on Tomcat8 and am following the setup instructions from
> the wiki. I can't seem to get the full installation working, with what I was expecting to see returning errors - my understanding is
> that after an installation I should be able to go to https://my-host/idp/login  to test (thinking that the "login.vm" view will render
> this).

If you're following the documentation, I would hope nothing in it implies that, and it is definitely not true. The only way to invoke the IdP is with a request to it via a supported profile. For SAML, if you don't have an SP, then you need a mocked up metadata file for one and then you would have to run the Unsolicited SSO endpoint providing the mock entityID and that's enough to get the IdP to try and respond. It has no "stand alone" behavior you can test.

One option that's not really documented since it's a bit new is to configure the IdP to protect its own status page with the login configuration you have created. That's a new idea that feeds into a general plan that 3.4 may include something more along the lines you're describing to help people get started more easily. So we're aware of the need and the next version will hopefully improve this.

> URLs I can access: /idp, /idp/status and /idp/shibboleth (returns metadata XML).

That's about all you could do out of the box.

> I went with tomcat because the default Jetty 9.2 instructions I ran into an issue with xerces libraries and wasn't sure how to
> unendorse the libraries (was using apt to install and Jetty required the xerces that has an issue and didn't want to venture down
> breaking system packages).

I advise avoiding any use of system packages for any Java software. It serves no purpose and it adds risk rather than reducing it because you can't trust those packages and what nonsense has been done to them (like, for example, the exact case you ran into). That extends to Java itself, since OpenJDK is a mess that we will continue to advise against using.

Doesn't pertain to your problem, just a crusade I intend to keep waging.

-- Scott