Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] XACML providers not correctly registered by DefaultBootstrap?

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] XACML providers not correctly registered by DefaultBootstrap?


Chronological Thread 
  • From: Kenny Pearce <>
  • To:
  • Subject: Re: [OpenSAML] XACML providers not correctly registered by DefaultBootstrap?
  • Date: Wed, 30 Apr 2008 09:42:19 -0400
  • Organization: Hx Technologies

So, I got the previous problem fixed, but now marshalling is failing
with:

org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a
different document than the one that created it.
at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown
Source)
at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source)
at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source)
at
org.opensaml.xml.util.XMLHelper.appendChildElement(XMLHelper.java:468)
at
org.opensaml.xml.io.AbstractXMLObjectMarshaller.marshall(AbstractXMLObjectMarshaller.java:162)
at
org.opensaml.xml.io.AbstractXMLObjectMarshaller.marshallChildElements(AbstractXMLObjectMarshaller.java:317)
etc.

I only have this problem when XACML elements are used. Any ideas?

On Tue, 2008-04-29 at 17:30 -0400, Brent Putman wrote:
>
> Kenny Pearce wrote:
> > Hi,
> > I am using the latest OpenSAML binary release (2.1.0) and trying to
> > construct an XACMLPolicyStatement. The XMLObjectBuilderFactory cannot
> > find a builder for it.
>
>
> I'm not sure why that is, it is there in the provider config file
> xacml2-saml2-profile-config.xml:
>
> <!-- XACMLPolicyStatement -->
> <ObjectProvider qualifiedName="xacml-saml:XACMLPolicyStatement">
> <BuilderClass
> className="org.opensaml.xacml.profile.saml.impl.XACMLPolicyStatementTypeImplBuilder"
>
> />
> <MarshallingClass
> className="org.opensaml.xacml.profile.saml.impl.XACMLPolicyStatementTypeMarshaller"
>
> />
> <UnmarshallingClass
> className="org.opensaml.xacml.profile.saml.impl.XACMLPolicyStatementTypeUnmarshaller"
>
> />
> </ObjectProvider>
>
> <ObjectProvider qualifiedName="xacml-saml:XACMLPolicyStatementType">
> <BuilderClass
> className="org.opensaml.xacml.profile.saml.impl.XACMLPolicyStatementTypeImplBuilder"
>
> />
> <MarshallingClass
> className="org.opensaml.xacml.profile.saml.impl.XACMLPolicyStatementTypeMarshaller"
>
> />
> <UnmarshallingClass
> className="org.opensaml.xacml.profile.saml.impl.XACMLPolicyStatementTypeUnmarshaller"
>
> />
> </ObjectProvider>
>
>
>
> Are you trying to lookup by the type or element QName?
>
> Also, don't know for what purpose you are using the XACML policy
> statement, but just pointing out that if this is intended to go as a
> statement in a saml:Assertion, you have to use a Statement element with
> an xsi:type, becuase of the way the SAML schema is defined.
>
>
> > If I manually instantiate an
> > XACMLPolicyStatementTypeImplBuilder, then it crashes later on because it
> > can't find the marshaller and tries to use the XSAnyMarshaller. I have
> > double-checked that I have an OpenSAML jar version with the relevant XML
> > files. The only thing I can think of is that it may have to do with my
> > version of xmltooling - I have built that from the latest SVN because I
> > need my XSDateTime patch.
>
> FYI, I don't think xmltooling is relevant to your problem, but I would
> say in general:
> 1) you probably do want to keep your version of xmltooling (openws) in
> sync with what's released with a particular version of opensaml2, just
> to avoid problems
> 2) if you have your own object provider impls, you might want to keep
> and package those separate from our libraries, for the above reason. Or
> submit this as a feature request/patch via Jira, and we could include it
> with the distribution, subject to whatever contributer agreements, etc
> that might be neccesary. I'd have to check on that, or maybe Chad or
> Scott knows more.
>
> > However, it doesn't seem that there is an
> > xacml-integration branch on xmltooling or anything like that.
>
> No, there's not. FYI, again not necessarily related to your problem:
> all development in these projects is being done on the REL_X branch that
> corresponds to the current major release, *not* on the trunk, so if
> you want the latest "current" code, that's what you should be pulling.
>
> > Besides,
> > it seems to me that as long as DefaultBootstrap is right it shouldn't
> > matter. Any idea why this would not work?
> >
>
> Correct it should work as long as DefaultBootstrap is right, which it
> appears to be. See my followup on your next message.
>




Archive powered by MHonArc 2.6.16.

Top of Page