I don't think auto-generating individual service definitions for every SP in a large federation is the right approach - why clutter CAS with thousands of (mostly) unused service definitions?
In any case, at least for InCommon, best practice is use the metadata query service to query individual SP entityId's as needed, so CAS never needs to download the full metadata file; setting up something to (periodically) download the entire file and build service definitions out of it seems like a bad idea resource-wise. Another approach (if we're thinking of new CAS features) might be to support multiple mdq URLs in the same (wildcard) service definition, so you could effectively say "for an unknown SP, first try InCommon, then eduGAIN, then ..." or whatever. On Wednesday, February 21, 2024 at 9:54:52 AM UTC-5 Ray Bon wrote: > What Kostas said! > > Perhaps what is needed is a feature to generate service definitions (in > memory) for each [SP] entry in federated metadata (during parsing of > metadata). With filters, allow and deny lists could be created, attributes > to release set, and other conditions (like MFA) could be added to the > service definition. > > This would be a good 4th year project. > > Ray > > On Tue, 2024-02-20 at 22:28 -0800, Kostas Kalevras wrote: > > Notice: This message was sent from outside the University of Victoria > email system. Please be cautious with links and sensitive information. > > That is actually negating the whole point. The point is that the federated > services registrar is the one maintaining the services metadata. The IdP on > the other hand does not have to worry about individual services but only > has to setup a*group* service definition with a URL metadata endpoint > which is regularly updated automatically. > > In the shibboleth case, when setting up an <AttributeFilterPolicy> in > attribute-filter.xml, one can use theInEntityGroup > <https://shibboleth.atlassian.net/wiki/spaces/IDP30/pages/2496987441/InEntityGroupConfiguration> > > policy rule to match the names of any of the <EntitiesDescriptor> in the > relevant metadata and make the rule apply to*all* of the SPs that are > included in the metadata. As a result we can include something like the > following: > > > <AttributeFilterPolicy id="edugain"> > <PolicyRequirementRule xsi:type="AND"> > <Rule xsi:type="InEntityGroup" groupID=" > http://edugain.org/"; /> > > I am not aware of a corresponding functionality in Apereo CAS which has > the result that we must maintain a Shibboleth installation only to handle > Federated services. > > Στις Τετάρτη 21 Φεβρουαρίου 2024 στις 7:28:56 π.μ. UTC+2, ο χρήστης > atilling έγραψε: > > We tried to follow the same posts you've linked, we were not able to get > the regular expression serviceId to function, always threw an error if we > tried to use that service. We did find we could add multiple services with > the same metadata (Like the almond and coco examples) and those are working > fine. It may be that you need to define each service you want to work with. > > On Tuesday, February 20, 2024 at 9:58:46 AM UTC-5 Kostas Kalevras wrote: > > Hello > > We 've been using CAS 6.6 with no problems as an IdP for multiple > protocols (CAS, OIDC, SAML) while using Shibboleth for federated SAML > services. We are using a MariaDB as our service definition data store. > > We are investigating the possibility of migrating federated SAML services > to CAS as well. > > There are a lot of quite helpful references on the fawnoos blog site such > asthis <https://fawnoos.com/2019/01/18/cas61-saml2-idp-incommon/> and this > <https://fawnoos.com/2021/03/02/cas64-saml2-metadata-caching/>. > > > Our main problem is the following: We need to setup *multiple *federated > metadata providers. More specifically: > > > - eduGAIN > - InCommon > - HEAL-Link > - Our own NRN federation > > From my understanding, the usual way to handle federated SAML services is > to setup a serviceId with a general regular expression and a very large > evaluation order as described in the InCommon blogpost > <https://fawnoos.com/2019/01/18/cas61-saml2-idp-incommon/>. Yet I am not > sure how someone could configure *multiple* different metadata providers > at the same time since the described setup will work if you only have one > federated metadata URL (and one corresponding service definition with a > general regex for the serviceId). > > > Has anyone configured such a setup or is aware of how we might proceed in > such a case? > > Thanks a lot > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/8e2b9620-4392-4b29-9aa9-38b4c7e2d035n%40apereo.org.
