Report of success with SP and IdP test servers, apache 1.3, nginx and SSL off-loading

[Gernot Hassenpflug]

"Cantor, Scott" <cantor.2 at osu.edu> writes:

> On 4/20/12 5:18 AM, "Gernot Hassenpflug" <ha4h-grnt at asahi-net.or.jp> wrote:
> >
> >- several shibboleth repository *-devel packages *must* be installed
> >  (else either the creation of SRPMs, or installation of some of the
> >  created shibboleth RPM packages will fail).

Thanks for the feedback.

> All you should have to do is install shibboleth-devel or whatever it's
> called. Most everything else will be installed by that. This isn't
> terribly well documented.

Interesting. I may be misunderstanding here, but perhaps the problem I
ran into is that some *-devel packages are created during the SRPM
rebuild, while others are not but are still needed.

I uninstalled all the shibboleth packages after I discovered I needed
the source install and that installing the source with some repository
packages (various opansaml, xml and xerces-c) related to shibboleth
did not work.

Then I discovered I needed the following *-devel packages during the
rebuilding and installing of the new RPMs:

libxerces-c-devel
libxml-security-c-devel
libxmltooling-devel
libxmltooling5
unixODBC-devel

As far as I can tell, those development files (presumably containing
the various header files) are also available in the source downloads at 
http://download.opensuse.org/repositories/security://shibboleth/RHEL_4/i386/

So I could have installed them by downloading them from there instead
of from the shibboleth repository.

However, the problem is that some of the devel packages are built
during the rebuild, and if one already has such a devel package
installed, there is a clash. Here devel packages are created during
the SRPM rebuilds, and must therefore not be installed separately:

liblog4shib-devel
libsaml-devel
shibboleth-devel

> >Changes from example-shibboleth2.xml:
> >
> >1. Site element additions:
> >   scheme="https"
> >   port="443"
> 
> That does not pertain to Apache. That should be clear from the
> documentation.

I did not realize that, so thanks, I searched the documentation and I
see in
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPNoSSL
that this is a setting specific to IIS. I've removed the entire
InProcess section from my configurations now.

> >2. Site element name, and RequestMap block Host element name changed.
> 
> You don't need to use the RequestMap with Apache in most cases. If there
> are no settings in it, it doesn't matter what the rest of the map contains.

OK, I reread the RequestMapper documentation at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapper
and while I was using it to map a request to a URL, apache would do
the same for me, so yes, I understand I do not need this section
(again, it seems it is important for IIS). I removed it from my
configurations now.

> >7. CredentialResolver element key and certificate values changed.
> 
> That shouldn't be necessary in most cases, it generates a keypair for you
> and puts them in the right files.

Understood. I've removed that step from my process now.

> You also missed a crucial step: fix your error templates. If people see a
> Shibboleth logo, your site looks bad, and so do we.

I don't get this yet. I followed the instructions at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPGettingStarted
at the time, thought the logo and stylesheet were meant to be set that
way, and changed the email address only. It seemed logical that the
shibboleth logo should appear if there is a misconfiguration, and that
shibboleth is generating the appropriate error page for me.

Although, reading
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPErrors
shows that apparently the error handling is a fairly complicated
setup, since "SP deployments are often expected to delegate a certain
amount of error handling to applications, particularly detection of
missing or unacceptable user/attribute information or violations of
local policy based on the information received", and while obviously
important, hard to do if one is still tring to come to grips with
getting a working shibboleth SP and IdP.

Comparing the examples, I'm not sure if you are recommending that
Errors section be rewritten with a redirectErrors element to specify a
completely new page, or if you are recommending that the logo be
customized but that shibboleth should generate the appropriate page?

Here is the complete section:

     <Errors supportContact="****@**********"
            logoLocation="/shibboleth-sp/logo.jpg"
            styleSheet="/shibboleth-sp/main.css"/>

-- 
Gernot Hassenpflug