OpenSAML V3: Problems while marshaling encrypted assertion
Brent Putman
putmanb at georgetown.edu
Fri Apr 28 15:24:49 EDT 2017
On 4/28/17 9:42 AM, Locatelli da Silva, Thiago wrote:
>
> I found this old discussion from the
> list, http://shibboleth.1660669.n2.nabble.com/Error-on-signing-outbound-SAML-message-td7621620.html,
> in which the user is facing the same issue I am facing, even though I
> am programmatically signing and encrypting, the resulting exception
> is the same. At the end of the discussion Scott says something about
> xmlsec 2.x, and looking at my maven dependencies I see xmlsec 1.5.7,
> which is coming from this dependency
>
> <dependency>
>
> <groupId>org.opensaml</groupId>
>
> <artifactId>xmltooling</artifactId>
>
> <version>1.4.4</version>
>
> </dependency>
>
>
> I added an exclusion to this dependency so Maven could use the
> version declared by opensaml-security-api, which is xmlsec 2.0.5.
>
Ah. Well, you shouldn't have that xmltooling dependency at all. That's
OpenSAML v2. If you're doing OpenSAML v3 (and you should, since v2 is
dead and EOL), then you can't mix them. All of the v3 dependencies
have artifactIds like opensaml-*. You absolutely should not have
xmltooling, openws or opensaml in your declared or transitive
dependencies. That will definitely cause problems. I didn't even
think to ask about something like that before.
> By doing this my problem was fixed. I am now able to encrypt my
> signed assertions and marshall them.
>
Ok, that makes sense. The older Santuario (xmlsec) lib had a bug fixed
in the newer 2.x series.
>
> I am only running into a validation issue with my response, but I
> think the way I am doing is not valid anymore for OpenSAML V3.
>
>
> for(String suiteId : Arrays.asList(
>
> "saml2-core-schema-validator",
>
> "saml2-core-spec-validator",
>
> "saml2-metadata-schema-validator",
>
> "saml2-metadata-spec-validator")) {
>
> ValidatorSuite validatorSuide = new ValidatorSuite(suiteId);
>
> validatorSuide.validate((XMLObject) response.getDOM());
>
> }
>
>
> java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.ElementNSImpl cannot be cast
> to org.opensaml.xml.XMLObject
>
>
The ValidatorSuite is from v2, so that's not going to work once you
remove the xmltooling dependency. We removed all the XMLObject
Validator and ValidatorSuite stuff from v3, as it wasn't really used
and wasn't maintained.
In v3, if you want to validate the XML at parsing time against the SAML
schemas, we have a convenience class
org.opensaml.saml.common.xml.SAMLSchemaBuilder for building a
javax.xml.validation.Schema instance. Then you configure that on your
ParserPool instance (e.g.
net.shibboleth.utilities.java.support.xml.BasicParserPool). This is
the easiest way to do JAXP-level schema validation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170428/caee20eb/attachment.html>
More information about the dev
mailing list