OpenSAML user discussion

[Brent Putman <>]

HiManuela,

Yes, the programmatic registration (as opposed to declarative in a 
provider config file) is fine.

But you still have the same fundamental problem, as Chad earlier 
outlined.  I wasn't replacing what he said about the XML.  You *can not* 
have the following in your metadata document:

<md:EntityDescriptor>
 <egmd:OnlineCADescriptor />
</md:EntityDescriptor>

You seem to still be doing that because of the first line of the 
validation error:
org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content 
was found starting with element 'egmd:OnlineCADescriptor'.

You *must* express your new RoleDescriptorType subtype in the XML like this.

<md:RoleDescriptor xsi:type="egmd:OnlineCADescriptorType" />


(I added the "-Type" on the end just to be consistent). That's because 
the SAML 2 schemas, including the metadata one, are blocked for 
substituion.  The only *element names* allowed are the ones enumerated 
in the EntityDescriptorType. Those are enumerated in the error message 
below.  Also see the metadata schema itself.

So what you are really trying to implement here (for the new role 
descriptor subtype, not the others) is a new complex type, not a new 
element.  And so, unless you have a need for it elsewhere (i.e. outside 
of a SAML 2 metadata document), you probably don't even need to declare 
an element called "OnlineCADescriptor" in your extension schema, only a 
new complex type called "OnlineCADescriptorType" (again I added -Type 
for consistency).

When you register the new provider, it should be by the *type* QName, 
not some element QName, so something like:

org.opensaml.xml.Configuration.registerObjectProvider(OnlineCADescriptorType.TYPE_NAME, 
new OnlineCADescriptorTypeBuilder(),
                                          new 
OnlineCADescriptorTypeMarshaller(),new 
OnlineCADescriptorTypeUnmarshaller(), null);

The various factories that look up the right builder, marshaller, 
unmarshaller first extract and do a lookup on the explicit xsi:type 
QName, if present.  If not present, or nothing is registered for that 
QName, then they lookup based on the element QName.  You are creating a 
new type (only), so you register it with that QName.

In your builder's buildObject(), you need to use one of the superclass 
builder methods that allows the explicit expression of the xsi:type 
QName, such as the 4-arg buildObject(String, String, String, QName) or 
the 2-arg buildObject(QName, QName).  Here is an example that I just 
checked in yesterday for the SAML 2 assertion namespace 
KeyInfoConfirmationDataType subtype of SubjectConfirmationDataType:

   public KeyInfoConfirmationDataType buildObject() {
       return buildObject(SAMLConstants.SAML20_NS, 
KeyInfoConfirmationDataType.DEFAULT_ELEMENT_LOCAL_NAME,
               SAMLConstants.SAML20_PREFIX, 
KeyInfoConfirmationDataType.TYPE_NAME);
   }

So that is going to get expressed as:
<saml:SubjectConfirmationData 
xsi:type="saml:KeyInfoConfirmationDataType"  />

All the above is only true for the role descriptor subtype.  For your 
OnlineCAService, that's a standard element-based provider, because 
that's (presumably?) what the content model defined by your new role 
descriptor type defines.

And of course, you probably already know this, if you actually want to 
do schema validation as you are doing, you actually need a schema 
document that defines your new types and elements, and that needs to be 
included in your schema validation process.

Also, I earlier suggested, based on Scott's comment, looking at the 
stuff in the org.opensaml.samlext.saml2mdquery, because it should be 
pretty much what you are trying to do.  I had not looked at that package 
closely before, but turns out that those providers are misimplemented, 
pretty much with the same mistakes that I believe you are making.  :-(  
I 'll try and fix them up soon.

--Brent


Manuela Stanica wrote:
> Hi Brent,
>
> thanks, I was happy to read your reply as it turns out what you 
> describe is exactly what I had already done, in detail (following the 
> model of how other RoleDescriptor implementations are constructed in 
> openSAML). The only thing I haven't done is implementing object 
> providers specifically as you said. What I'm doing is just registering 
> them in the main marschaller class in my project after the 
> bootstrap(), as in:
>        
> org.opensaml.xml.Configuration.registerObjectProvider(OnlineCADescriptor.DEFAULT_ELEMENT_NAME, 
> new OnlineCADescriptorBuilder(),
>                                            new 
> OnlineCADescriptorMarshaller(),new OnlineCADescriptorUnmarshaller(), 
> null);
>        
> org.opensaml.xml.Configuration.registerObjectProvider(OnlineCAService.DEFAULT_ELEMENT_NAME, 
> new OnlineCAServiceBuilder(),
>                                            new 
> OnlineCAServiceMarshaller(),new OnlineCAServiceUnmarshaller(), null);
>
> With that marshalling and unmarshalling the EntityDescriptor(s) 
> containing the new types works just fine. It's only when trying to 
> validate now the EntityDescriptor with a 
> SAMLSchemaBuilder.getSAML10Schema().newValidator() that I get the 
> error I mentioned:
>
> org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content 
> was found starting with element 'egmd:OnlineCADescriptor'. One of 
> '{"urn:oasis:names:tc:SAML:2.0:metadata":RoleDescriptor, 
> "urn:oasis:names:tc:SAML:2.0:metadata":IDPSSODescriptor, 
> "urn:oasis:names:tc:SAML:2.0:metadata":SPSSODescriptor, 
> "urn:oasis:names:tc:SAML:2.0:metadata":AuthnAuthorityDescriptor, 
> "urn:oasis:names:tc:SAML:2.0:metadata":AttributeAuthorityDescriptor, 
> "urn:oasis:names:tc:SAML:2.0:metadata":PDPDescriptor, 
> "urn:oasis:names:tc:SAML:2.0:metadata":Organization, 
> "urn:oasis:names:tc:SAML:2.0:metadata":ContactPerson, 
> "urn:oasis:names:tc:SAML:2.0:metadata":AdditionalMetadataLocation}' is 
> expected.
> ERROR net.geant.edugain.validation.Validator  - document does not 
> validate against SAML10 schema
>    at 
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
> Source)
>    at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
>    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>    at 
> org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(Unknown 
> Source)
> ......
>
> Is there something else that I would need to do in terms of 
> registering providers or so, the absence of which could cause the 
> problem with validation?
> I'll also take a look at the example you mentioned to see if it would 
> help me gain some clarity about what I'm missing..
>
> Manuela