[OpenSAML] Developing Entensions

[Deena Gurajala]

Hi,

Can some body throw some light on using Extensions with openSAML ? I want to use some thing similar to attribute statement in the Query?

[Brent Putman]

Do you mean software extensions to the library, or do you mean use of
the Extensions element of SAML 2 protocol message?

In terms of the latter, you just add what extension XMLObjects you want
to the protocol message Extensions object, by calling
Extensions#getUnknownXMLObjects(), and adding/processing what you want
to the List that is returned (just like other list return types in
OpenSAML).

Of course defining what extensions you use and what they mean and how
they are processed on the receiver side is all up to you, if there's not
an existing profile for that extension.

[Deena Gurajala]

I mean Extensions element of SAML 2 protocol message. We had a situation to support some extra attributes in Authorizations (We are not using XACML). Could you provide some sample code to build this one?

[Brent Putman]

You'll have to be much more specific in what you are trying to do. We
can give you guidance in using the OpenSAML library toolkit to
accomplish what you want to express in SAML, but you have not given much
detail as to what you are trying to accomplish.

If you are seeking some general guidance on how to solve some problem
using SAML - rather than how to implement a particular solution with
OpenSAML - this might not be the correct list.

[Deena Gurajala]

I am sorry. May be I am not clear in expressing what I wanted. I want to produce some thing similar to the following snippet.

<samlp:AuthnRequest>
.
  <samlp:Extensions>

    <rac:RequestedAuthnContexts>
        <rac:AuthnContextClassRef>
           ac:classes:Password              
        </rac:AuthnContextClassRef>
        <rac:AuthnContextClassRef>
           ac:classes:NonShared
        </rac:AuthnContextClassRef>
    </rac:RequestedAuthnContexts>

  </samlp:Extensions>

</samlp:AuthnRequest>


How can I achieve with openSAML 2.0?

[Brent Putman]

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

> > <mailto:put...@georgetown.edu <mailto:put...@georgetown.edu>>>

[Deena Gurajala]

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.

[Brent Putman]

Deena Gurajala wrote:
> I figured out that I have to write a custom schema for my extensions.
> They way I did it is.
>
> -write a custom schema.

Yes, you probably should have a schema for your custom stuff.

> - Use JAXB to marshal the JAVA to XML DOM.
> -Then set it o Extensions using setDOM method.
>

No, not really. JAXB is not really a complimentary technology to
OpenSAML. They are both Java-XML binding approaches. Use one or the
other, but probably not both.

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

No, definitely do not use the setDOM method on the XMLObjects. That is
used by other components withing the library (marshallers and
unmarshallers) to cache the DOM representation of the XMLObject, it is
not really intended for use via the public API. You'll get
unpredictable results doing that.

[Deena Gurajala]

 Extensions extens=new ExtensionsBuilder().buildObject();

Is it the correct way to build an extension. Because the prefix is coming as md and name space is pointing to Metadata Descriptor schema name space.

[Brent Putman]

Well, the builder has multiple buildObject methods. The object provider
support for extensions is a little atypical - in looking at it we
re-used the same provider for both the metadata and protocol schema
extensions, because the content model is the same. The buildObject()
builds the metadata one. Since you want the protocol schema one, just
use one of the other overloaded buildObject methods, specifying either
the protocol element QName or the triple of namespace, prefix and local
name Strings.

Honestly, we should probably at least have a custom builder for the
protocol Extensions so that people don't have to do that, but that's the
way it is right now.

And btw, you generally don't want to instantiate a builder (or
marshaller or unmarshaller) directly, it's better to obtain it via
Configuration.getBuilderFactory.getBuilder(QName).

--Brent

[Deena Gurajala]

Thanks for your support and time. I will try to get it work with godd way of implementation.