Questions on initial install/configuration of Shibboleth

[Peter Schober]

* Michael Nesmith - NOAA Affiliate <michael.nesmith at noaa.gov> [2017-12-13 22:09]:
> My partner has recently installed Shibboleth on a Redhat 6 Linux server.
[...]
> [root at marlin ~]# rpm -qa | grep shib
> liblog4shib1-1.0.9-3.1.el6.x86_64
> shibboleth-2.6.1-3.1.el6.x86_64

So that's the Shibboleth SP ("Service Provider") software.
That part is used to protect resources running in a local webserver.

> The customer wants to use Shibboleth as a single sign-on provider.
> Not sure why they don't just use LDAP...we have a LDAP  server.

Many reasons. Mainly with SAML instead of LDAP the protected resource
(say, some web application) does not recieve (nor does it need to
recieve) the subjects credentials (as would be necessary with LDAP so
that your application can replay those credentials to the subject's
LDAP server trying to impersonate the subject).

SAML supports federation, meaning you can provision access for other
people that can securely authenticate at their own institution (think
/their/ LDAP server) but still be authorized to access your
resource/application. (I.e., they don't exist in /your/ LDAP server.)

Also you can have Web Single Sign-On with SAML.

> 1) import IdP (Identify Provider) metadata to shibboleth (this is what OCIO
> provided for us to connect) -
>   attached two files: sso-dev-noaaonline-idp.xml and sso-dev-cac-idp.xml
> 
> 2) generate our SP (Service Provider) metadata and attach here.

So you're running a SAML SP, meaning you're running a protected
resource that someone from another organization can be given access
to.
For that to work your SP needs SAML Metadata describing the other
party (the "Identity Provider" of those other people), the
cryptographic keys they'll be signing their SAML prococol messages
with. etc.

Here's as shallow an entry as the Shib docs currently have:
https://wiki.shibboleth.net/confluence/display/CONCEPT/Home

> The problem is that when I read the configuration documentation, I don't
> see any of the information that I need to do either of these tasks.
> 
> Step 1 on loading the IdP metadata refers to a file named
> relying-party.xml that I can't even find.

You're likely reading the documentation for another product, that for
the Shibboleth IDP ("Identity Provider").

The correct docs for your case are here:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAddIdP

For general first steps with the configuration see:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPGettingStarted

> The Shibboleth daemon seems to be running, but I can't access
> anything related to Shibboleth from the Apache web page.

Try `curl -k https://localhost/Shibboleth.sso/Status` to get some
indication that the SP is alive and working.

-peter