Matadata aggregator , federation named groupID for filters

[Jehan PROCACCIA]

Indeed MA 0.7 is quite old, so I followed your advice and upgradred to latest 0.9.2 
before going to my initial goal (descriptorName property  as you mentioned) 
I want to be able to aggregate and sign my federation Metadata (IDPs and SPs) 
I am afraid that my old MA aggregate-config.xml file is not compatible with 0.9.2 
So I took the sample https://wiki.shibboleth.net/confluence/display/MA1/Aggregate+and+Sign
and tried to adapt it to my purpose .
the main difference here is that I don't want to parse and sign a single MD file but aggregate a complete directory of IDPs and SPs MD files
So I took <bean id="metadataDirectory" from my old 0.7 config in place , but call to it (source-ref="metadataDirectory") from <bean id="source" class="net.shibboleth.metadata.dom.DomFilesystemSourceStage" fails on this error : 

[aggregator-cli]# ./mda.sh ../config-imt.xml main 
ERROR - Unable to initialize Spring context
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 14 in XML document from URL [file:/root/aggregator-cli-0.9.2/../config-imt.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 14; columnNumber: 141; cvc-complex-type.3.2.2 : L'attribut 'source-ref' n'est pas autorisé dans l'élément 'bean'.

indeed attribute "source-ref" is a patch from my old config to the sample one I took . 

here is my what I did : 

<!-- My ADD :  Configuration Options for the metadata aggregation process -->
    <bean id="metadataDirectory" class="java.io.File">
        <constructor-arg value="/root/xml/fede-imt-metadata-git/"/>
    </bean>

    <!-- First, we define the stages for our pipeline -->
    <!-- My COMMENT from initial sample  <bean id="source" class="net.shibboleth.metadata.dom.DOMFilesystemSourceStage"> -->
            <!-- MY ADD  the following line -->
        <bean id="source" class="net.shibboleth.metadata.dom.DomFilesystemSourceStage" source-ref="metadataDirectory" parserPool-ref="parserPool"/>
        <property name="id" value="source"/>
        <property name="parserPool">
            <bean class="net.shibboleth.utilities.java.support.xml.BasicParserPool" init-method="initialize"/>
        </property>
        <property name="source">
            <bean class="java.io.File">
                <constructor-arg value="/root/xml/fede-imt-metadata-git/"/>
            </bean>
        </property>
    </bean>

<!-- Configuration Options for the metadata aggregation process -->
    <bean id="metadataDirectory" class="java.io.File">
        <constructor-arg value="/root/xml/fede-imt-metadata-git/"/>
    </bean>

thanks for your help . 

jehan .

----- Mail original -----
De: "Ian Young" <ian at iay.org.uk>
À: "users" <users at shibboleth.net>
Envoyé: Jeudi 17 Juin 2021 10:43:04
Objet: Re: Matadata aggregator , federation named groupID for filters

> On 2021-06-16, at 17:05, Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu> wrote:
> 
> Hello,
> I've been using for a long time this tool :
> https://wiki.shibboleth.net/confluence/display/MA1
> to aggregate metadatas in my federation (an old 0.7 version ...)

I'm sure 0.7 is working great for you, but it's been a long time since it was obsoleted (by 0.8.0 in 2013) and you should really migrate to the latest version if you can. It's not that any of the code will stop working so much as it's impossible to support something that is that far in the rear-view mirror.


> but I cannot find a way to tell it to "name" the aggregated metadata so that this name can be used ultimately as a groupID  in attribute-filters as in 
> <PolicyRequirementRule xsi:type="InEntityGroup" groupID="https://federation.renater.fr/test/"/>
> 
> is MA1 capable to name aggregate ?

If you're using the EntitiesDescriptorAssemblerStage to assemble your aggregate, its descriptorName property (stage.setDescriptorName() method) allows you to set the Name attribute. I _think_ that was present in 0.7, but that version is not supported in any way.

If you're assembling your aggregate in some other way, you could probably use an XSLT stage. Again, I _think_ that was available in the version you're using.

Having said which, you probably want to be wary of relying on the EntitiesDescriptor/@Name as a group name, as it's obviously not applicable in any situation in which the aggregate isn't available, e.g. in an MDQ-style per-entity world.


> Regarding aggregate name convention, I see in Incommon Metadata this named for example
> ID="INC20210616T153332" Name="urn:mace:incommon" validUntil="2021-06-30T15:33:32Z"
> 
> and here in France (Renater) has
> Name="https://federation.renater.fr/test/" ID="_20210616T150017Z" validUntil="2021-06-25T15:00:17Z" cacheDuration="PT1H"
> 
> does the name has to be a URL and / or a URN ?


The specification just says "A string name that identifies a group of SAML entities in the context of some deployment." So there are really no standards-imposed constraints here. Most federations have used a URI of some form, and each federation that uses Name has chosen something they thought was sensible. It's often the same as the registrar URI given on individual entities, which is the modern replacement for this scheme and works just fine in a per-entity world.

In the UK federation, for example (highly edited):

<?xml version="1.0" encoding="UTF-8"?>
<EntitiesDescriptor ID="_" Name="http://ukfederation.org.uk" cacheDuration="PT6H0M0.000S" validUntil="2021-07-06T00:00:00Z">
    <Extensions>
        <mdrpi:PublicationInfo creationInstant="2021-06-15T00:00:00Z" publisher="http://ukfederation.org.uk"/>
    </Extensions>

<EntityDescriptor entityID="https://idp2.iay.org.uk/idp/shibboleth">
    <Extensions>
        <shibmd:Scope regexp="false">iay.org.uk</shibmd:Scope>

        <mdrpi:RegistrationInfo registrationAuthority="http://ukfederation.org.uk" registrationInstant="2007-03-30T16:36:00Z">
            <mdrpi:RegistrationPolicy xml:lang="en">http://ukfederation.org.uk/doc/mdrps-20130902</mdrpi:RegistrationPolicy>
        </mdrpi:RegistrationInfo>

Cheers,

    -- Ian





-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net