SAML1 CheckRequestVersionHandler ClassCastException ?

[Brent Putman]

On 1/21/14 8:24 PM, Tom Zeller wrote:
> When wiring an inbound message handler chain, the SAML1
> CheckRequestVersionHandler throws a ClassCastException
> "net.shibboleth.idp.saml.impl.profile.IdPInitatedSSORequest cannot be
> cast to org.opensaml.saml.saml1.core.RequestAbstractType".
>
> The message decoder is
> net.shibboleth.idp.saml.impl.profile.saml1.IdPInitiatedSSORequestMessageDecoder.
>
> I will take a look, but I am confused. Maybe it will be obvious to someone else.

In terms of *what* is actually happening, Scott already noted. 

By way of more explanation on the "why": you conceptually
wouldn't/couldn't/shouldn't actually use this MessageHandler in this
flow because:  The generically parameterized message type of the decoder
and the handlers that operate on the produced MessageContext have to be
consistent.  This one is an AbstractMessageHandler<RequestAbstractType>,
so it fundamentally can't operate on the output of the
IdPInitiatedSSORequestMessageDecoder, which produces an
IdPInitatedSSORequest.  If we need any message handlers to operate on
this inbound flow (off-hand I don't even know), we'd need special
MessageHandler variants that we designed to operate on an
IdPInitatedSSORequest.

This one is a weird one because of the non-SAML Shibboleth protocol and
I think it's the only one for SAML where the message isn't a subtype of
SAMLObject.  In v2 the code is similarly weird, if you go and look at
it.  It's unfortunate that you were starting out with this one.  :-)

The SAML 2 ones for IdP-initiated don't have this issue because that
message decoder impl is generically paramed to produce a SAMLObject -
which is what most/all the "standard" SAML MessageHandlers operate on.

And so, if we were to ever to say implement OpenID, we might have
something like an OpenIDMessage type and then impls paramed like:
MessageDecoder<OpenIDMessage> and MessageHandler<OpenIDMessage>.

Btw, on the CheckRequestVersionHandlers themselves: I don't recall every
doing any MessageHandlers for SAML that were paramed more specifically
than SAMLObject, like Scott did there.  As long as we're careful not to
wire the wrong one on the wrong flow, it's fine.  But I probably would
have done this differently, by just having a single impl that processed
messages of type SAMLObject, had a property slot for the acceptable
SAMLVersion(s) and then a "smart" property on one of the contexts (e.g.
SAMLMessageInfoContext) that knew how to pluck SAMLVersion out of the
inbound message.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140122/fc166b33/attachment.html