shibboleth.Conditions.RelyingPartyId regex?

[Cantor, Scott]

On 7/17/15, 3:50 PM, "users on behalf of Liam Hoekenga" <users-bounces at shibboleth.net on behalf of liamr at umich.edu> wrote:

>The next bean I create is
>
>    <bean id="RelyingPartyIdRegex"
>        class="net.shibboleth.idp.profile.logic.RelyingPartyIdPredicate" abstract="true"
>        c:pred-ref="exampleOrgRegexPredicate" />

There's no point in making that abstract. That's the entire bean, there's nothing else you can do to it that would make it less abstract. The only argument you can give RelyingPartyIdPredicate if you're using that constructor argument name is what you already gave it, a Predicate object. There's nothing else that can be done to it.

You can probably make it abstract and not break Spring, but as a bean, it's done. Making it abstract would let you create multiple versions of it with different names, but there are other ways to do that with aliases, and I'm pretty sure that's not what you're trying to do here.

The main mistake is later on....

>...which looks really similar to on from system/conf/utilities.xml...
>
>    <bean id="shibboleth.Conditions.RelyingPartyId"
>        class="net.shibboleth.idp.profile.logic.RelyingPartyIdPredicate" abstract="true" />

That's an abstract bean with no constructor arguments. Yours is an abstract bean that essentially has all the possible arguments provided.

>Using this version of "RelyingPartyIdRegex", I get the errors about constructor resolution failures / ambiguity.

Because of what you're doing to it in the child. By itself it's fine, if pointless.

>I try this instead..
>
>    <bean id="RelyingPartyIdRegex"
>        class="net.shibboleth.idp.profile.logic.RelyingPartyIdPredicate" abstract="true">

Which is pointless, obviously, that's just a copy of the same base bean.

>...effectively making a copy of "shibboleth.Conditions.RelyingPartyId", that I try feeding the appropriate arguments to the multiple constructors..
>
><bean parent="RelyingPartyIdRegex" c:pred-ref="exampleOrgRegexPredicate" c:candidates="#{ 'https://sp.example.org' }" />

That's not possible. I guess I was assuming more Java knowledge than you have, sorry for that. You're calling two different constructors there. That's not physically possible. You're combining two different variants of that class in one object.

I think what you want to do, but I'm guessing only, is that you're trying to say you want to support an explicit list of SPs OR check for a regex. Assuming that's the case, you're trying to consolidate that into one bean, but that isn't possible. You have to build up a whole Boolean mess of objects to do this kind of advanced condition.

Or you just write a script...

Doing and/or logic is ugly, but I provided some parents for that also. I believe there are examples scattered around, but if that's what you're trying to do, I can find an example. I won't waste the time if it's not.

Doing functional programming like this is not fun, and using a script is probably a better answer in the majority of cases unless you use the Spring stuff a lot. It isn't what we're expecting most people would do, for obvious reasons.

>... but since there isn't a single constructor that takes both candidates /and/ predicates, this fails and I get the message about constructor resolution failures / ambiguity.

Right.

>I'm guessing this works in Francesco's example because "RelyingPartyIdRegex" is invoked via a property instead of being instantiated?

No, it works I assume because all he's trying to do is that one condition alone, not multiple conditions. Or he did the AND/OR wiring I'm talking about in addition.

-- Scott