OpenSAML and Apache Santuario (xmlsec) 1.5.1

[Brent Putman]

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.