OpenSAML SOAP WSFed: Create AppliesTo Object

[Brent Putman]

On 3/27/20 9:31 PM, Cantor, Scott wrote:
> On 3/27/20, 6:11 PM, "dev on behalf of Mark Jonsen" <dev-bounces at shibboleth.net on behalf of mark.jonsen.44 at outlook.de> wrote:
>
>> I think the problem is that the AppliesTo from wspolicy and wsfed have the same name.
> I would agree, that's broken, they're going to conflict at runtime.


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.)

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:

http://schemas.xmlsoap.org/ws/2005/02/trust

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.

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.

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:

       XSAny response = (XSAny) 
XMLObjectSupport.getBuilder(XSAny.TYPE_NAME).buildObject(RequestSecurityTokenResponse.DEFAULT_ELEMENT_NAME);

        AppliesTo appliesTo = .... // The wspolicy package one

        response.getUnknownXMLObjects().add(appliesTo);


And then same for any other elements and attributes you need in the RSTR.

I created in issue for this to fix in a future release:

https://issues.shibboleth.net/jira/browse/OSJ-306



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20200402/a1ab49c4/attachment.html>