Velocity in new installation of Shibboleth IDP

[Brett Cave]

Thanks Scott. I was hoping to get a nice login page to test the LDAP
authentication I configured - I thought (not misled by the docs, but just
an assumption) that Shib IDP would provide a UI to authenticate into the
app and then kick off some a SAML.  So good to know that I have an
installation working as expected. If we move past the POC with shib, I'll
definitely build a more robust environment (we have recipes for this in our
provisioning tooling, this was a quick "let's get it up and see what it can
do" effort).

So on to the next issue - I found TestShib which seemed like a great place
to start testing SAML. My understanding is that I can use the IDP metadata
in testshib.org to generate some SP metadata, add it to the Shib host and
then reference it from metadata-providers. Is this the correct sort of next
step? Am guessing I could also use the shib app and drop in my own
login.jsp to test authentication and then test SAML through to the SP...
TestShib is coming back to me with an error that the idp-metadata.xml is
not valid, so I'm trying to figure out how to fix that (any guidance or
samples would be a great help).




On Tue, Jun 6, 2017 at 5:34 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
twitter: @brettcave
Blog: http://brett.cave.za.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170606/9df77e44/attachment-0001.html>