One idp application serving as two idps (with different entityIDs)

[Tom Zeller]

On Thu, Aug 20, 2015 at 7:27 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 8/20/15, 6:53 PM, "dev on behalf of Tom Zeller" <dev-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:
>
>>
>>> On Aug 20, 2015, at 11:43 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>>
>>> On 8/20/15, 4:27 AM, "dev on behalf of Andrea Biancini" <dev-bounces at shibboleth.net on behalf of andrea.biancini at garr.it> wrote:
>>>
>>>> Hi all,
>>>> I am trying to figure out if there is a configuration (or code
>>>> extension) that could permit one single IdP to operate with two
>>>> different entityIDs.
>>>
>>> Yes, to a degree. The entityID used can be set on a per-RP, per-profile basis.
>>
>>With Scott’s caveats, and this is not exactly what was asked for, but here is some example relying-party.xml configuration which overrides the IdP (responder) entityID based on the RP entityID :
>>
>><bean
>> id=“MyDefaultRelyingPartyByName"
>> parent=“RelyingPartyByName"
>> abstract="true”>
>> <property name=“profileConfigurations"
>>  value="#{@'shibboleth.DefaultRelyingParty'.profileConfigurations.values()}" />
>></bean>
>
> Now that's a trick I haven't seen.

I thought I copied it from you ;-)

> We should put some examples like that into the wiki.

Well ... actually ... if we ever bump the major version we might
should consider renaming the 'shibboleth.' beans to something without
a literal "." that needs to be escaped in SPeL expressions, perhaps
just "default". The other thing is that we have some asymmetry in our
bean fields/properties, meaning that getFoo() and setFoo() produce and
accept different object types. Point being, reduce

 value="#{@'shibboleth.DefaultRelyingParty'.profileConfigurations.values()}"

to

 value="#defaultRelyingParty.profileConfigurations"