Apache 2.4 producing 500 error when serving DirectoryIndex page from Shib SP protected areas

[Cantor, Scott]

On 10/3/12 8:31 AM, "Paul Beckett (ITCS)" <P.Beckett at uea.ac.uk> wrote:
>
>I couldn't manage to checkout the updated file from SVN, so applied the
>patch of diffs between 3765 and 4643.
>http://svn.shibboleth.net/view/cpp-sp/branches/REL_2/apache/mod_shib.cpp?r
>1=3643&r2=3765&pathrev=3765
>I assume r3643 is the same as 2.5.0, as 2.5.0's release date seems to be
>newer than r3643's commit date?

I don¹t know the rev, but the 2.5.0 tag would tell you what the exact one
was.

If you want to check out, it's just svn co
https://svn.shibboleth.net/cpp-sp/branches/REL_2

>Applying this patch has resulted in different behaviour .... but it's
>still not working for me. I'm not entirely sure if this is my
>configuration, or an issue with the Apache 2.4 module.

I think it's you, but I don't have enough to go on. All I can say is that
it worked ok for me, and the bug was nothing that involves routine
processing of handler requests. I'll double check that I have the
sessionHook configured, I don't know if I did or not.

>When requesting a page, I'm redirected to the IDP, successfully
>authenticate there, and get redirected back to my Apache 2.4 server
>running the SP, but instead of receiving the page all I see is the
>message:
>" Please wait while we transfer you to
>https://ueacisr6test.uea.ac.uk/Shibboleth.sso/Metadata..."

That's your IdP I think. You used that as an entityID, so it's hung up on
something at the SP end.

>If I replace the sessionHook="/Shibboleth.sso/AttrChecker" in Application
>defaults with sessionHook="/Shibboleth.sso/Session" , I can see I'm
>receiving attributes back from the IDP.

I'd start without the sessionHook, but it sounds to me like the problem is
with the attribute checker handler. Are you expecting it to pass you on,
or display the error template?

>In the apache access log all I see is:

There'd have to be additional logging of the /Session request or the
/AttrChecker request, those are full redirects back to the client.

>In the shibd.log all I see is:
>2012-10-03 13:16:23 INFO Shibboleth.AttributeExtractor.XML [1]: skipping
>unmapped SAML 2.0 Attribute with Name: eduPersonTargetedID
>2012-10-03 13:16:23 INFO Shibboleth.SessionCache [1]: new session
>created: ID (_9599c0fa5d154f3bcb351131a2bc01e5) IdP
>(https://testlogin.uea.ac.uk/entity)
>Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (139.222.120.221)

That's pretty much the SP finishing.

-- Scott