Can the MDA add entity attributes?

[Ian Young]

> On 19 Sep 2024, at 14:49, Wessel, Keith via users <users at shibboleth.net> wrote:
> 
> Our old metadata publishing process used to publish the entities in alphabetical order.

In alphabetical order of... entity ID? Some kind of display name?


> While, as long as each entity is unique, order doesn’t matter, I’m still curious how easy it would be for me to get the MDA to do this. Can I define a merge strategy on the merge stage? And are there any merge strategy beans available that do an alphabetical sort?


The EntitiesDescriptorAssemblerStage has a property called itemOrderingStrategy; by default, it uses a NoOpItemOrderingStrategy, which is the only one provided.

It's the only one provided because what individual deployers want has been so varied.

The UKf deployment, for example, has four levels of sorting:

/**
 * Implements an ordering strategy for UK federation aggregates.
 * 
 * UK registered entities (with {@link UKId} metadata) come first, in the
 * natural order of their {@link UKId}.  So, for example, <code>ID="uk000001"</code>
 * comes before <code>ID="uk000002"</code> which comes before any entity not
 * sporting a {@link UKId} at all.
 * 
 * Items with {@link ItemId} metadata come next, again in the natural ordering
 * for {@link ItemId}.  Items with neither {@link UKId} or {@link ItemId} come
 * last in the ordering.
 */

https://github.com/ukf/ukf-mda/blob/main/src/main/java/uk/org/ukfederation/mda/UKEntityOrderingStrategy.java


If that sounded like it might do the job, you could try it: for example, if you have already extracted IdemId metadata then it will just sort on that. The `ukf-meta` repository on GitHub has a ukf-mda.jar containing that class. Alternatively, the code is fairly generalisable so it could form a basis of your own implementation if you wanted to go that route.

(The InCommon deployment has a different custom ordering strategy, IIRC.)

Implementations of ItemOrderingStrategy do need to be Java, I'm afraid.


>  And second question: I’m currently using a demultiplexer stage to take all entities from an upstream aggregate, make two copies of them, and for one copy, retain a given list of SPs and tag them. The other copy throws away that same list of SPs. Those later get merged back together, resulting in all entities from the original aggregate with selected ones having an entity attribute applied to them. This would be much cleaner with the split merge stage since it would do all the work for me. Problem is I couldn’t figure out how to do a selection strategy that builds a predicate saying “the entity ID of this item matches one of the entityIDs in a list”. Is there an easy way to do this?

One option is to provide SplitMergeStage's selectionStrategy as a XPathItemSelectionStrategy bean, like this:

                    <!-- select entities with ExportOptIn label -->
                    <property name="selectionStrategy">
                        <bean parent="mda.XPathItemSelectionStrategy">
                            <constructor-arg value="/md:EntityDescriptor[md:Extensions/ukfedlabel:ExportOptIn]"/>
                            <constructor-arg ref="commonNamespaces"/>
                        </bean>
                    </property>

See https://github.com/ukf/ukf-meta/blob/master/mdx/uk/generate.xml#L693-L699

Any Java bean implementing the Predicate<Element> interface would work too, if you wanted to write code. For example, if you wanted to pick out entities matching one of 100 different entityIDs, then writing a class that implemented a Predicate based on the ItemId metadata would probably be more compact.


>  Both of these felt like they required extending the MDA with my own Java code rather than just something in Spring. But I could be missing something.

If something has been a common use case it tends to have been migrated into a provided bean for convenience. Neither of these are quite what I've seen before, though.


    -- Ian




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4151 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20240919/96c5d472/attachment.p7s>