Questions on initial install/configuration of Shibboleth

[Michael Nesmith - NOAA Affiliate]

Thank you.

This information helped a lot.

I can now display the status page from

curl -k https://localhost/Shibboleth.sso/Status
<https://localhost/Shibboleth.sso/Status%60>

Just need to find out who is in charge of the Identity Provider...(smile).

Thanks,
Mike




On Wed, Dec 13, 2017 at 5:12 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * 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
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>


-- 
Michael NeSmith
Senior Linux Administrator
Earth Resources Technology, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171214/5c958760/attachment.html>