<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/27/20 9:31 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:75813342-9D2A-4F0C-8497-D311882437E5@osu.edu">
<pre class="moz-quote-pre" wrap="">On 3/27/20, 6:11 PM, "dev on behalf of Mark Jonsen" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofmark.jonsen.44@outlook.de"><dev-bounces@shibboleth.net on behalf of mark.jonsen.44@outlook.de></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I think the problem is that the AppliesTo from wspolicy and wsfed have the same name.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I would agree, that's broken, they're going to conflict at runtime.
</pre>
</blockquote>
<p><br>
</p>
<p>I think it's not exactly that they have the same Java name
("AppliesTo"). I think the issue is really that the wsfed.RequestSecurityTokenResponse
has a member wsfed.AppliesTo, whose namespace conflicts with the
like-named wspolicy.AppliesTo. Only 1 XMLObject provider can be
registered under a given QName. And AFAICT there's no reason for
the wsfed.AppliesTo to exist at all, since it's exactly the same
XML element per the schema. (Unlike some of the other WS-* stuff
in wsfed, which use different namespaces than other like-named
packages.)</p>
<p>But it's worse than that. The stuff in the wsfed package seems
totally incomplete and broken to me. Both the request and
response types defined there in the schema:</p>
<p><a class="moz-txt-link-freetext" href="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust</a></p>
<p>have completely open, wildcard content models. Neither the
request nor the response there implement that support (our
ElementExtensibleXMLObject interface), and so they are missing
90%+ of support for what is documented as the "expected" content
model. The RSTR only has explicit support for the AppliesTo and
List<RequestedSecurityToken> members. So if you needed
anything else in there, it would be completely unusable.<br>
</p>
<p>This was a third-party contribution, as was most/all of the WS-*
stuff. We apparently did not catch any of this wsfed package
brokenness at the time, since we use nothing of the wsfed for
Shibboleth. We do use some of the other WS-* stuff, and that has
been ok in my experience.</p>
<p>I think there's probably a decent immediate workaround for you
here. Since the content model is basically completely open
anyway, you could use the XSAny provider for your
RequestSecurityTokenResponse object, similar to this:</p>
<p> <tt> XSAny response = (XSAny)
XMLObjectSupport.getBuilder(XSAny.TYPE_NAME).buildObject(RequestSecurityTokenResponse.DEFAULT_ELEMENT_NAME);</tt><tt><br>
</tt><tt> </tt><tt><br>
</tt><tt> AppliesTo appliesTo = .... // The wspolicy package
one</tt><tt><br>
</tt><tt> </tt><tt><br>
</tt><tt> response.getUnknownXMLObjects().add(appliesTo);</tt></p>
<p><br>
</p>
<p>And then same for any other elements and attributes you need in
the RSTR.</p>
<p>I created in issue for this to fix in a future release:</p>
<p><a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/OSJ-306">https://issues.shibboleth.net/jira/browse/OSJ-306</a></p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>