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/24/12 3:50 AM, "Gernot Hassenpflug" <ha4h-grnt at asahi-net.or.jp> wrote:
> >
> >I don't think this works, since libsaml-devel wants to pull in
> >libsaml7 which I had to remove initially anyway.
> 
> I don't know what you're seeing, but you shouldn't have to remove anything
> old to do builds, the old libs coexist with the new ones.

/../

I'll have a chance check that on a new testing IdP in the next week.
 
> >If there is a chance for me to check this again---certainly with the
> >next release, but also before that, as I am setting up automated
> >shibboleth-enabled server setup scripts---I will post more information
> >if it turns out I can do things differently.
> 
> 
> Bigger problem: 2.5 will NOT support RH4. I have been totally clear on
> that. Not only is it not supported, it won't build. The boost version on
> RH4 is too old. If you want to use it, you'll have to build it yourself,
> and you'd have to install a custom version of boost.

Understood.

What we will do for next generation tests is use apache 2.2 on CentOS6
front end, with shibboleth. And the backend server will no longer need
shibboleth and can remain on CentOS4.8 (although we plan upgrading the
application to run on CentOS6 also).

(In my original post we were using nginx as front-end server, and
unfortunately I was not able yet to get FastCGI (path problems to
begin with) to run the .sso programs.)

> >I had trouble figuring out where the Errors section
> >/shibboleth-sp/{logo.jpg,main.css} files were on the SP
> >server. Located them in /usr/share/doc/shibboleth-2.4.3/ which
> >surprised me somewhat,
> 
> That's getting improved in 2.5, but those aren't really the files that
> need changing, it's the error templates. You aren't meant to modify files
> in /usr/share

OK, thank you for that pointer. I've modified the html templates and added that to our configuration process.

Further update:

I set up an LDAP server, and configured the IdP to fetch attributes
(currently using LDAP "uid" as the user identification), and pass them
on to the SP. REMOTE_USER is now populated perfectly.

(For some reason, when using the htpasswd file, even though login was
successful, REMOTE_USER had remained empty until I created static data
in the IdP attribute-resolver.xml.)

To the developers ansd users on the list/group from whom I have received
advice and feedback: Many thanks for your patience and help.
-- 
Gernot Hassenpflug