Splitting the relying-party.xml
kwessel at illinois.edu
Tue Aug 25 18:47:47 UTC 2020
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.
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. 
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.
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
More information about the users