Ok, sorry, it wasn't assigned to me, so I didn't know you had already
filed.
No, I don't see anything wrong with your XML. That's pretty much the
standard usage of xsi:type, nothing unusual there. We support that
anywhere/everywhere automatically, that I can think of. Of course in
your application code that's processing the assertion, you'd need to
have conditional logic to check for the xsi:types you support and then
cast and handle the appropriate XMLObject impl (falling back to using
XSAny, which gets you access to the whole content model for "unknown"
types).
I just commited that fix, along with unit tests for the XSURI providers.
It works for me. I cut-and-pasted your exact provider config and
AttributeValue (on the latter just adding the namespace decl for saml2
assertion namespace. Didn't have any problems. I also verified that
the actual impl class that was getting unmarshalled was:
org.opensaml.xml.schema.impl.XSURIImpl, and not XSAny. Your trace log
pretty much indicates that, whatever you thought you were doing to add
the provider config, it wasn't there. Maybe you forgot to update your
jar or add the updated config file to that jar?
Try building from what I just checked in and see if that works.
--Brent
Kenny Pearce wrote:
I filed this bug two weeks ago (issue JXT-33). I am using a modified
xmltooling jar that contains this section in schema-config.xml:
<!-- XML Schema anyURI -->
<ObjectProvider qualifiedName="xs:anyURI">
<BuilderClass
className="org.opensaml.xml.schema.impl.XSURIBuilder" />
<MarshallingClass
className="org.opensaml.xml.schema.impl.XSURIMarshaller" />
<UnmarshallingClass
className="org.opensaml.xml.schema.impl.XSURIUnmarshaller" />
</ObjectProvider>
It still doesn't work. Any ideas? Is anything wrong with this XML?
On Fri, 2008-05-23 at 16:25 -0400, Brent Putman wrote:
Yes, it does support this. Looks like the problem here is simply that
the xmltooling provider config file (schema-config.xml) does not have
the providers registered for the xs:anyURI type QName. BTW, It's also
missing for xs:boolean. Please file a bug to track this and we can
easily add.
You can workaround in the interim by registering the
builder/marshaller/unmarshaller for that type manually (either
programatically or declaratively with a new config file). You want the
XSURI* classes in org.opensaml.xml.schema.impl package in xmltooling.
HTH,
Brent
Kenny Pearce wrote:
Hi,
I'm trying to use typed AttributeValues as suggested by saml-core sect.
2.7.3.1.1, but as far as I can tell OpenSAML is ignoring my xsi:type
element.
Here is the XML element in question I'm trying to unmarshall:
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:anyURI">urn:hxti:roles:hxti:super-user</saml:AttributeValue>
I get the following in the logger:
2008-05-23 15:27:03.217 TRACE - Unmarshalling other child nodes of DOM
Element {urn:oasis:names:tc:SAML:2.0:assertion}Attribute
2008-05-23 15:27:03.217 TRACE - Unmarshalling child elements of
XMLObject {urn:oasis:names:tc:SAML:2.0:assertion}Attribute
2008-05-23 15:27:03.217 TRACE - No unmarshaller was registered for
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue, child of
{urn:oasis:names:tc:SAML:2.0:assertion}Attribute. Using default
unmarshaller.
2008-05-23 15:27:03.217 TRACE - Unmarshalling child element
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValuewith unmarshaller
org.opensaml.xml.schema.impl.XSAnyUnmarshaller
2008-05-23 15:27:03.217 TRACE - Starting to unmarshall DOM element
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue
2008-05-23 15:27:03.217 TRACE - Targeted QName checking is not available
for this unmarshaller, DOM Element
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue was not verified
2008-05-23 15:27:03.217 TRACE - Building XMLObject for
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue
2008-05-23 15:27:03.217 TRACE - No builder was registered for
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue but the default
builder org.opensaml.xml.schema.impl.XSAnyBuilder was available, using
it.
2008-05-23 15:27:03.217 TRACE - Unmarshalling attributes of DOM Element
{urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue
2008-05-23 15:27:03.217 TRACE - Pre-processing attribute
{http://www.w3.org/2001/XMLSchema-instance}type
2008-05-23 15:27:03.217 TRACE - Unmarshalling other child nodes of DOM
Element {urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue
2008-05-23 15:27:03.217 TRACE - Releasing cached DOM reprsentation for
parent of {urn:oasis:names:tc:SAML:2.0:assertion}AttributeValue with
propagation set to true
Does OpenSAML support the use of xsi:type here? If yes, what am I doing
wrong?
Thanks,
|
