Splitting the relying-party.xml

[Wessel, Keith]

One more question on this. Scott, you said that metadata filters can be defined in separate files now. So, circling back to a variant of the question from my first note in this thread, is it better to add a second metadata providers config file as a second resource in services.xml or via a <import> element in the default metadata-providers.xml? I'm assuming a second resource in services.xml, but I wanted to make sure I wasn't missing something.

Thanks,
Keith


-----Original Message-----
From: Wessel, Keith 
Sent: Tuesday, August 25, 2020 2:05 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Splitting the relying-party.xml

That sounds great! I'll be watching for more info.

Keith


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

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

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

By moving all of it to SAML metadata, basically, same as CAS. There's already an implementation built that can do much more than just tagging (eg. resolving client secrets with the attribute resolver). [1] We're reviewing the metadata profile internally right now, it's just not published in the wiki yet. Should be soon.

We can probably figure out ways of bridging the formats later, the priority is just making sure the functionality is there and we already have all of it done for this format without doing extra work.

-- Scott

[1] https://issues.shibboleth.net/jira/browse/JOIDC-5


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