OpenSAML user discussion

[Andreas Vallen <>]

Hi,

I forward this off-list exchange with Scott, so it can be followed-up
on the list:

> We've run into the following problem with the design of the 
> MessageDecoder interface:
>
> The evalutation of the SecurityPolicy inside the 
> MessageDecoders makes the successfull 
> decoding of a binding dependent on the successfull evaluation 
> of the SecurityPolicy.

Usually when a policy fails, it normally just does nothing rather than throw
an error. The primary exception is message flow, but that also isn't a
problem.

There's a somewhat undocumented feature of most of the decoders. When an
exception is thrown, the decoder tries to locate the issuer itself, along
with any metadata it can find, and uses that to attach properties to the
exception. I'll try and get that documented better, but you'll see it in the
POST/Redirect decoder source in the catch block.

I think the SOAP decoders are an exception, but of course in that case you
have a connection back to the sender, so you can respond anyway.

Shibboleth used to do this to try and attach support contact info whenever
errors were caught, and I ported that code in. I think it will address your
concern. There should be an entityID property on the exception when it's
known, along with contactName, contactEmail, and errorURL, if they were
found in the metadata.

> This behaviour is problematic because we want to send a StatusResponse
> indicating the failure to the request issuer but the only way to get the 
> Issuer's EntityID and thus the response destination is to decode the
> message. A solution would be to make the evaluation 
> of the SecurityPolicy a seperate step from the Decoding.

If it were separate, that would break the unification of artifact with
POST/Redirect, which would effectively undermine the reason for having
decoders. It would also require passing a bunch of stuff into the decoder
instead of just the policy, which was the older API.

> Further I wonder whether there's some reasone why the signature algorithm
> that is declared in a XMLDSIG signature could not be determined
> automatically from the provided key. See 
> the attached patch to XMLSecSignatureImpl for a suggestion.

I'm not a fan of auto-detecting things that should be trivial for the caller
to know, but I don't care that much.

BTW, you can send stuff like this to the mailing list.

-- Scott




--
Andreas Vallen  Software Engineer
fun communications GmbH   Lorenzstrasse 29   D-76135 Karlsruhe
Tel: +49 721 96448-132   Fax: +49 721 96448-299

   www.fun.de