OpenSAML and Apache Santuario (xmlsec) 1.5.1

[Stephanie Stroka]

Thanks Brent!

I'm using SAML2 and the problem shows for both: Assertions and 
Responses. I tried manually setting the ID by using

xmlObj.getDOM().getDocumentElement().setIdAttribute("ID", true)

but this only helps partially (I fixed one of my tests with that).
It's strange because when I call the setIdAttribute(..) directly before 
doc.getElementById() it works. Maybe there are some modifications done 
on the DOM tree (copying or some such) so that it does not remember that 
"ID" is an id?

BTW:  The org.opensaml.security.SAMLSignatureProfileValidator still uses 
IdResolver.getElementById(doc, uriID) (line 150). I inherited this 
validator and basically dropped the check. I guess I should have used 
Document.getElementById(..) here as well.

Anyway, thanks a lot for your help!!
Steffi

On 04/12/12 19:12, Brent Putman wrote:
>
>
> On 4/12/12 11:38 AM, Stephanie Stroka wrote:
>> Hello everyone,
>>
>> I was trying to upgrade the xmlsec library from version 1.4.4 to 1.5.1
>> due to another library that depends on the new version.
>> There are some changes that have been made to the new version of xmlsec,
>> e.g. how Elements are resolved.
>>
>
> I have not tried running OpenSAML v2 with the newer Santuario yet.  I'll
> do some quick tests later today or tomorrow to see if I experience the
> same issue.
>
> However, based on what Colm says there, we are already nominally doing
> the right thing for the new id resolution in 1.5.x; if my memory serves,
> I believe we were even involved in the discussions that led to that
> change.  In particular, we are using Element setIdAttributeNode and
> setIdAttributeNS, in our unmarshallers and marshallers respectively, in
> the XMLObject provider code for elements with id-typed attributes.
>
> So, off-hand, I'm puzzled by why it's not working.
>
>
>> org.apache.xml.security.utils.resolver.ResourceResolverException: Cannot
>> resolve element with ID Response_0429a9ae645e7a9f06533443bf6d9e33bd4abeea
>
> Just to confirm: on exactly what were you validating a signature here?
> Was it SAML 1 or 2, and was it a Response or Assertion, etc?  It looks
> like a Response element based on the id value, but just wanted to confirm.
>
> It's possible there might be a bug on some specific element's object
> provider, versus a general problem with the whole approach.
>
>
>
>>
>>
>> I was wondering how elements were resolved in the previous version. Was
>> it enough to set the id for an assertion?
>
> Looking back at the svn history, we made the changes to set the
> DOM-level id-ness back on 2007/02/01, which means it's been there for
> all releases of OpenSAML v2.  The 1.4.x IdResolver uses DOM id-ness
> first, so I thought it should be using that, rather than falling back to
> the search of well-known id types.  I'll do some testing to confirm.
>
>> Is OpenSAML planning to migrate to xmlsec 1.5.1?
>
> OpenSAML v2 is not planned to have any more minor versions, only patch
> releases.  We probably wouldn't update to xmlsec 1.5.x in a patch
> release, unless a security vulnerability was discovered.
>
> In OpenSAML v3, we are planning at this point on switching the signing
> and validation code to use the JSR-105 API rather than the older
> Santuario/xmlsec API.  That's a Java security provider based API.  Not
> sure yet whether we will mandate use of Santuario there, or allow
> whatever is configured in the java.security provider set.  We will have
> to have a hard dependency on Santuario for XML Encryption support (since
> JSR-106 is dead), and I'm virtually certain we will ship with the
> (relatively) latest xmlsec 1.5.x (or newer), based on when OpenSAML and
> Shibboleth IdP v3 are done.
>
>
>> And: Do you have any suggestions on how to make it possible that
>> elements can be resolved without digging into the OpenSAML library?
>
> I'll investigate, it should be working already.  It's a mystery to me
> why it isn't.
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

-- 
AdNovum Informatik AG
Stephanie Stroka
Dipl. Informatik-Ing. FH

Roentgenstrasse 22, CH-8005 Zurich
mailto:stephanie.stroka at adnovum.ch
phone: +41 44 272 6111, fax: +41 44 272 6312

http://www.adnovum.ch  AdNovum Offices: Bern, Budapest, Singapore, 
Zurich (HQ)