Issue with xmltooling and attribute namespace

Wed Feb 26 10:48:11 EST 2014

Hi,

I somehow fixed it. I was using as a reference for my class the
RequestSecurityToken. By using the saml2's Attribute class as a template,
it works properly. Thus, my classes do not extend AbstractWSTrustObject,
but AbstractSAMLObject. The same for the marshaller and unmarshaller.
For each attribute I used the prepareForAssignment instead of adding it as
unkownAttribute.add().

I used getters and setters instead of the AbstractWSTrustObject
getUnknownXMLElements().add().

Thanks,

       Massi
ᐧ

On Wed, Feb 26, 2014 at 10:55 AM, Massimiliano Masi <
massimiliano.masi at gmail.com> wrote:

> Hello,
>
> Everything is handled using XMLTooling and DOM. In my marshaller, I have
>
> public class ClaimTypeMarshaller extends AbstractWSTrustObjectMarshaller {
>
> @Override
>
> protected void marshallAttributes(XMLObject xmlObject, Element
> domElement) throws MarshallingException {
>
>
>  String out1 = XMLHelper.prettyPrintXML(domElement);
>
> System.out.println(out1);
>
> ClaimTypeImpl cvi = (ClaimTypeImpl)xmlObject;
>
> // XMLHelper.marshallAttributeMap(cvi.getUnknownAttributes(), domElement);
>
> AttributeMap attributeMap = cvi.getUnknownAttributes();
>
> Document document = domElement.getOwnerDocument();
>
> Attr attribute = null;
>
> for (Entry<QName, String> entry : attributeMap.entrySet()) {
>
> attribute = XMLHelper.constructAttribute(document, entry.getKey());
>
> attribute.setValue(entry.getValue());
>
> domElement.setAttributeNodeNS(attribute);
>
> if (Configuration.isIDAttribute(entry.getKey()) ||
> attributeMap.isIDAttribute(entry.getKey())) {
>
> domElement.setIdAttributeNode(attribute, true);
>
> }
>
> }
>
> String out = XMLHelper.prettyPrintXML(domElement);
>
> System.out.println(out);
>
>
> ᐧ
> The first System.out gives the following:
>
> <?xml version="1.0" encoding="UTF-8"?><ts:ClaimType
> xmlns:ts="urn:tiani-spirit:ts" xmlns="urn:tiani-spirit:ts"/>
>
>
> The second gives the following (correct):
>
> <?xml version="1.0" encoding="UTF-8"?><ts:ClaimType
> xmlns:ts="urn:tiani-spirit:ts" ts:DataType="
> http://www.w3.org/2001/XMLSchema#dateTime"
> ts:name="urn:tiani-spirit:bes:2013:claims:tr-date"
> xmlns="urn:tiani-spirit:ts"/>
>
> Unfortuntaly, the resulted XML is as follows:
>
>    <ts:ClaimType xmlns:ts="urn:tiani-spirit:ts"
> xmlns="urn:tiani-spirit:ts" DataType="
> http://www.w3.org/2001/XMLSchema#dateTime"
> name="urn:tiani-spirit:bes:2013:claims:tr-date">
>
>             <ts:ClaimValue>2014-02-26T09:45:58.430Z</ts:ClaimValue>
>
>         </ts:ClaimType>
>
>
>
> So, something must happen during marshalling of the ancestors, perhaps in
> the marshallInto of AbstractWSTrustObjectMarshaller?
> Moreover, who is qualifying such attributes? I created the schema with
> qualified attributes because of the result of the marhsalling.
>
> I can't access the source code now, the whole shibboleth.net is down.
>
> Any other ideas?
>
>
>
> On Tue, Feb 25, 2014 at 6:55 PM, Brent Putman <putmanb at georgetown.edu>wrote:
>
>>
>> On 2/25/14 9:13 AM, Massimiliano Masi wrote:
>>
>> Hi All,
>>
>>
>>
>>  In project A, my XMLObject is unmarshalled as:
>>
>>
>> My question would be: Unmarshalled from where?  Coming in over the wire
>> from a WS service or WS client of some kind (e.g. see below re: Apache
>> Axis).  OpenSAML doesn't change a DOM when it unmarshalls an XMLObject tree
>> around it, so my guess would be that the XML already looks that way before
>> it gets to your OpenSAML.  Or else, it's being mutated in some way by
>> whatever DOM serialization you are applying.  But either way I don't think
>> OpenSAML is directly involved.
>>
>> If you're pulling this off the wire, I'd try serializing and logging it
>> before you hand it to OpenSAML for unmarshalling, just to confirm exactly
>> what you are receiving.
>>
>>
>>
>>
>>  Project A is good, since it declares a namespace for the attributes
>> DataType and Name, while in project B such attribtues are not set. This
>> violates this schema definition:
>>
>>    <xs:element name="ClaimType" type="ts:ClaimTypeType"/>
>>
>>     <xs:complexType name="ClaimTypeType">
>>
>>         <xs:attribute name="DataType" type="xs:anyURI" use="required"  />
>>
>>         <xs:attribute name="name" type="xs:anyURI" use="required" />
>>
>>     </xs:complexType>
>>
>>
>>
>> Actually, that's not really clear just from that schema snippet.  Whether
>> the attributes in an instance document are namespace-qualified or not
>> depends (in part) on the <xs:schema> element's  ' attributeFormDefault'
>> attribute. If it's absent, it defaults to 'unqualified'.  Unless the schema
>> is explicitly setting 'attributeFormDefault=qualified', then based on that
>> schema snippet, I believe the unqualified forms in your B example would be
>> the correct schema-valid ones.   See also ' elementFormDefault' , which
>> does the same for elements.
>>
>> Note that a lot of schemas, including SAML and WS-Trust, set (and/or
>> effectively default) 'elementFormDefault=qualified' and
>> 'attributeFormDefault=unqualified', meaning elements will be
>> namespace-qualified, but attributes are not.
>>
>> (That doesn't really have anything to do with why you're seeing 2
>> different outputs, though).
>>
>>
>>
>>
>>
>>  Since the code (from project A) is the same, it must be a problem of
>> libraries. Do you have suggestions?
>>
>>
>> Not specifically, but that ns0, ns1, etc stuff looks suspiciously like
>> what Apache Axis does when it generates Java code to handle a particular
>> schema (the "contract driven" way).  So perhaps that is relevant somewhere
>> in what you are doing, or at least you are somehow using some of the same
>> libraries that they do.
>>
>>
>> --Brent
>>
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> dev-unsubscribe at shibboleth.net
>>
>
>
>
> --
> Massimiliano Masi
>
> http://www.mascanc.net/~max
>

-- 
Massimiliano Masi

http://www.mascanc.net/~max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140226/c49c94f2/attachment-0001.html 