Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] Developing Entensions

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] Developing Entensions


Chronological Thread 
  • From: Deena Gurajala <>
  • To:
  • Subject: Re: [OpenSAML] Developing Entensions
  • Date: Tue, 3 Nov 2009 13:06:23 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=edN5mvpIpaQHbxfgAM2U3GwTJUITif3Lhn5v9AJQ08lk9ThnXxGZJPmp19S9SB1059 B9Den3lEdDMufWtEiJEtGs/c+My1MXgOyj1br4L2+GjbOiKha5LoMvbwKg+BdQFSj5fl 3kP0y9Bt8Fskmt55/DV/iAihXGqIZVUwi9q7c=

I figured out that I have to write a custom schema for my extensions. They way I did it is.

-write a custom schema.
- Use JAXB to marshal the JAVA to XML DOM.
-Then set it o Extensions using setDOM method.

However it is missing Extensions element as shown below.

<keyValuePair xmlns="http://www.test/extensions">
      <keyValue xmlns="http://www.test/extensions">
         <key xmlns="http://www.test/extensions">SP_ATTR</key>
         <value xmlns="http://www.test/extensions">SP_ATTR_VALUE</value>
      </keyValue>
      <keyValue xmlns="http://www.test/extensions">
         <key xmlns="http://www.test/extensions">SP_ATTR2</key>
         <value xmlns="http://www.test/extensions">SP_ATTR_VALUE2</value>
      </keyValue>
   </keyValuePair>

           Extensions extens=new ExtensionsBuilder().buildObject();       
            extens.setDOM(new DocumentGenerator().generate().getDocumentElement());   
            authzDecQry.setExtensions(extens);

Is it the proper way? Mean while I dig into the way you suggested.


On Tue, Nov 3, 2009 at 12:44 PM, Brent Putman <> wrote:
Ok, I see, your question is really about how to implement XMLObject
support for a custom schema, e.g. stuff from the "rac" namespace below.
Once you have those, you just add them to the AuthnRequest/Extensions as
I described earlier. You have 2 choices:

1) the right and best way is to implement XMLObjects for those custom
elements.  This will make it easier to both generate and process them.
You would write support for your custom elements by implementing
XMLObject interfaces and impls, marshallers and unmarshallers for each
element.  See the OpenSAML developer's guide for details:

https://spaces.internet2.edu/display/OpenSAML/OSTwoDeveloperManual

You can also look at any of the code in SAML for examples of how that is
done.  I would strongly urge you to implement this solution rather than
the next.


2) a quick and dirty way to generate such a structure is to use more
generic object provider support already in the library.  You can use the
XSAny XMLObject implementation for an element that has extensible
element and/or attribute content, and then marshall it as element with a
particular QName.  This would work for your RequestedAuthnContexts
element with its complex content type.  You could also use XSAny
provider for your AuthnContextClassRef element, as it supports text
content.  Or you could just use the XSString provider.  (I won't ask why
you aren't just reusing the similarly named element from the Assertion
schema).  There's an example at the bottom of the following wiki page of
using the XSString provider directly.  Just adjust the QName used for
your element name (instead of the example Attribute).

https://spaces.internet2.edu/display/OpenSAML/OSTwoUsrManJavaAnyTypes

Usage of XSAny is similar.  In both cases you'd want to omit the second
QName arg in the builder's buildObject method, as you probably don't
want to express the xsi:type on the element.


--Brent





Archive powered by MHonArc 2.6.16.

Top of Page