Splitting the relying-party.xml

[Wessel, Keith]

Ah, got it! That all makes sense and is definitely cleaner than the lists in the relying-party.xml and even slightly better than setting up a bunch of metadata tags that I then have to map to overrides manually. Thank you!

So, when might we see metadata-driven (or similar) overrides for the OIDC profiles? At present, the big limitation to the OIDC implementation is that we can't put tags in metadata that I know of, and there's no facility for tagging clients after the metadata is loaded. We've got a set of clients that have different constraints on token lifetime, and it'd be great to not have to manually maintain a list of them in a relying party override.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, August 25, 2020 1:09 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Splitting the relying-party.xml

On 8/25/20, 1:54 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    I'll work on converting my RelyingPartyByName configs to RelyingPartyByTag.

That much is certainly a given, but what I really meant was that you should simply add the settings themselves to the metadata and not use overrides at all. The .MDDriven parent beans automate all that. [1]

But there's no question...you shouldn't bother with updating lists of SPs in that file, that's definitely not the way to go. Custom tags is certainly better than that.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP4/MetadataDrivenConfiguration

-- 
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