Interfederation

[Ian Young <>]

On 9 Apr 2013, at 06:55, Scott Koranda 
<>
 wrote:

> By that I mean that I spent 15 minutes picking through the middle of the 
> file,
> where my cursor happened to be, looking at perfectly valid <Extension> 
> elements
> before scrolling to the top and seeing an empty one immediately...

OK, I think I know how that might have happened.  Mostly everyone can tune 
out here, but the explanation should help Steven fix it fairly simply.

Steven't aggregator is a mutated clone of the UKf machinery.  One thing I do 
a fair bit is composite together a number of operations and apply them as a 
group.  It looks like the path that InCommon metadata is taking through 
Steven't aggregator is invoking this stage, one way or another, probably 
unintentionally:

   <ref bean="stripMdattrNamespace"/>

That's defined as follows:

    <!--
        stripMdattrNamespace
        
        Remove the namespace used by the entity attributes extension.
    -->
    <bean id="stripMdattrNamespace" parent="stripNamespace_parent"
        p:id="stripMdattrNamespace"
        p:namespace="urn:oasis:names:tc:SAML:metadata:attribute"/>

I apply this in contexts where I don't trust the source's entity attributes 
policy (usually because they don't have one).  These days, I apply it 
selectively to import channels; I think at the time Steven got his original 
snapshot it was also part of the standardImportActions composite stage.

Anyway, the *right* way to fix that is to make sure that stripMdattrNamespace 
isn't included on the path that the InCommon metadata goes through.  You 
probably do want to make sure that it's on the path the UK metadata goes 
through though, even though we aren't exporting any entity attributes right 
now you want to be defensive about that.

A couple of other observations.  In the UK metadata, we never publish 
schema-invalid metadata because every path to an output document includes 
these stages:

   <ref bean="checkSchemas"/> 
   <ref bean="errorTerminatingFilter"/> 

I think that's a wise precaution for any aggregator configuration; it's 
better not to generate output than to generate output that someone might 
choke on.  Usually they will be able to continue using the old version while 
you fix things.

The other thing I'd note is that "filter out some extensions" is something 
one does quite often during imports from "elsewhere", and there is always the 
possibility that you end up with an empty <Extensions> element as a result.  
Unfortunately, that element is defined to always have at least one child 
element; while that's not how I would have defined it myself (I spent way too 
much time in the 80s trying to force machine-generated Pascal through a 
compiler we were working on not to have a healthy dislike of forcing an empty 
container to be a special case) it's what we have to work with.

So, whenever I filter any extensions, I include an instance of this bean:

   <ref bean="removeEmptyExtensions"/>

That's also defined in the common beans file, as follows:

    <!--
        Remove any empty Extensions elements.
    -->
    <bean id="removeEmptyExtensions" parent="stripContainer_parent"
        p:id="removeEmptyExtensions"
        p:elementName="Extensions"
        p:elementNamespace="urn:oasis:names:tc:SAML:2.0:metadata"/>
    
As long as there's one of those reasonably close to the end of the output 
pipeline, this kind of thing shouldn't come up again.  Not stripping the 
extension in question is probably the better answer in this case, though.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature