<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 1/21/14 8:24 PM, Tom Zeller wrote:<br>
</div>
<blockquote
cite="mid:CAMNmQDTgfYNQSdZDUJkAnNk-GnQwK4BhoSedCuaoEp+Xkoau+w@mail.gmail.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
In terms of *what* is actually happening, Scott already noted. <br>
<br>
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.<br>
<br>
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. :-)<br>
<br>
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.<br>
<br>
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>.<br>
<br>
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.<br>
<br>
<br>
</body>
</html>