New Shibboleth SP Handler using extension

[Cantor, Scott]

On 1/15/13 5:48 PM, "Daisuke Miyakawa" <d.miyakawa at gmail.com> wrote:
>
>I have a question about Shibboleth SP extension:
>  Can I introduce a new SP Handler implementation, using SP's extension
>mechanism?

Yes.

>After putting the shared object in a right directory and rebooting shibd,
>I successfully saw "(constructor): appId=default" log message in my
>shibd.log, which is
>embedded in my implementation of ExtraHandler (as you can see above).
>At this point, I assumed ExtraHandler was detected and loaded by the SP
>appropriately.

Your handler (in its simple form) is not a shibd extension. It can load
there, but won't do anything, it has to be loaded by the in-process half
to matter. My guess is you loaded it only out of process and your
native.log will show an error trying to install a plugin it can't find.

>After that, however, I couldn't access to the relevant URL,
>https://(myhost)/Shibboleth.sso/Extra.
>SP raises shibsp::ConfigurationException with saying "Shibboleth handler
>invoked at an unconfigured location."
>though SP already appears to know the Handler is there, according to the
>previous log message.

No. shibd does, but that's not the whole SP.

>No relevant error log was seen in shibd.log, while ideally I should be
>seeing "run" log message.

That isn't where such a message would appear unless your extension is
implemented with internal remoting to an out of process portion like many
of the built-in handlers are. The first "footprints" of any extension
operating as a handler are in native.log from within the web server.

-- Scott