Re: [cas-user] Re: Multiple SAML Federated SP

[atilling]

We're running cas 6.6.12 and we've tried "serviceId" : ".+" with that 
service id if we attempt to authenticate a service we don't have a specific 
service.json for we get errors in the log indicating the metadata can't be 
processed and the login fails with service not authorized response to the 
end user.
I documented the errors in a different email chain that received no replies 
but I can include the errors here if requested. 

On Friday, February 23, 2024 at 8:42:51 AM UTC-5 David Gelhar wrote:

> We've had good success with wildcard service definitions for a single 
> federation (InCommon), using a definition like:
>
> "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
> "serviceId" : ".+",
> "name" : "InCommon",
> "evaluationOrder" : ,
> "metadataLocation" : "https://mdq.incommon.org/entities/{0};,
>
> (This is with CAS 6.6)
> On Thursday, February 22, 2024 at 11:25:18 AM UTC-5 atilling wrote:
>
>> If the regex serviceId worked as explained in the blog it would be 
>> simple. 
>> However that ends up throwing errors that the metadata can't be parsed.
>>
>> On Wednesday, February 21, 2024 at 10:16:04 AM UTC-5 Kostas Kalevras 
>> wrote:
>>
>>> Or maybe implement the groupId feature present in Shibboleth?
>>>
>>> For example, the service definition could use the groupId as the 
>>> entityId (ie http://edugain.org/) and have an additional flag signaling 
>>> that we should use the service definition entityId to search if the SP 
>>> entityId has a  value equal to that value.
>>>
>>> Στις Τετάρτη 21 Φεβρουαρίου 2024 στις 4:54:52 μ.μ. UTC+2, ο χρήστης Ray 
>>> Bon έγραψε:
>>>
 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  in 
 attribute-filter.xml, one can use theInEntityGroup 
 
  
 policy rule to match the names of any of the   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:


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



 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 

Re: [cas-user] Re: Multiple SAML Federated SP

[Ray Bon]

David,

You are right. All services is too heavy weight.
In Shibboleth we create filters for the services we support, which does create 
on going work.
Our policies are very particular about the release of user attributes, 
providing only the minimum for each service and controlling user groups allowed 
to access.
I was thinking of a similar approach for cas.

Ray

On Fri, 2024-02-23 at 05:34 -0800, David Gelhar wrote:
Notice: This message was sent from outside the University of Victoria email 
system. Please be cautious with links and sensitive information.

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 agroup service definition with a URL metadata endpoint which is regularly 
updated automatically.

In the shibboleth case, when setting up an  in 
attribute-filter.xml, one can use 
theInEntityGroup
 policy rule to match the names of any of the   in the 
relevant metadata and make the rule apply toall of the SPs that are included in 
the metadata. As a result we can include something like the following:



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

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

Re: [cas-user] Re: Multiple SAML Federated SP

[Kostas Kalevras]

Στις Παρασκευή 23 Φεβρουαρίου 2024 στις 3:42:51 μ.μ. UTC+2, ο χρήστης David 
Gelhar έγραψε:

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?


Because we really do not want to have any part in administrating service 
definitions for individual SPs of a federation. On the contrary, we want 
out users to be able to access *all* SPs belonging to HEAL-Link, or eduGAIN 
(or other federations) with the bare minimum configuration from our part 
(just setup the metadata providers and a general attribute release policy). 
What is certain is that we *do not* want to have to add a service 
definition every time someone in a Federation (eduGAIN is a Europe wide 
federation) adds a new service.
 


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.


I tried a hack which seems to work. What I did is setup a service 
definition for each federation with a serviceId regular expression such as 
'.+' for the first, '..+' for the second and so on. EntityIDs are usually 
URLs so we can setup such regexps for a while. I also setup the 
evaluationOrder to be quite high.

For testing purposes I also setup a simpleSAMLPHP test SAML client with a 
service definition including a specific serviceId and an even higher 
evaluation order.

Example for eduGAIN:
{ "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService", 
"serviceId" : ".+", "name" : "EDUGAIN", "id" : 4001, "evaluationOrder" : 
1, "attributeReleasePolicy": { "@class": 
"org.apereo.cas.services.ReturnAllAttributeReleasePolicy", "consentPolicy": 
{ "@class": 
"org.apereo.cas.services.consent.DefaultRegisteredServiceConsentPolicy", 
"status": "FALSE" } }, "metadataLocation" : "
https://md.aai.grnet.gr/aggregates/edugain-metadata.xml; } 

Example for my specific SAML client:
{ "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService", 
"serviceId" : "http://:8080 ", "name" 
: "SimpleSAMLPHP", "id" : 4005, "evaluationOrder" : 5, 
"attributeReleasePolicy": { "@class": 
"org.apereo.cas.services.ReturnAllAttributeReleasePolicy", "consentPolicy": 
{ "@class": 
"org.apereo.cas.services.consent.DefaultRegisteredServiceConsentPolicy", 
"status": "FALSE" } }, "metadataLocation" : "
http://:8080/simplesaml/module.php/saml/sp/metadata.php/default-sp 
"
 
} 

When I tried logging in, CAS "on demand" downloaded the metadata for all 
federations and my service (4 federations, one service):
# ls -lh /etc/cas/saml/metadata-backups/ total 105M -rw-r- 1 root root 
1.3M Feb 23 14:33 33df1392ede2ae53cfbfda228c8c12795a487274.xml -rw-r- 1 
root root 98M Feb 23 14:33 5aaa33456c18415a547a69c229b042939b5a69ee.xml 
-rw-r- 1 root root 1.9M Feb 23 14:32 
cb375c9a62f6bfe288564021d6162a65d1a84137.xml -rw-r- 1 root root 3.9M 
Feb 23 14:33 f3394e69c8ae2f4476489e12d0309d11d21c4bfd.xml -rw-r- 1 root 
root 5.3K Feb 23 14:33 faca05ced5ea3197b309319bde338f587303682d.xml 

Using a regex in the serviceId is mandatory so that CAS will download the 
metadata on demand.

A login test was successful, although CAS matched the serviceId belonging 
to the *eduGAIN* service definition:

sso-cas-overlay-sso-1 | 2024-02-23 15:26:08,303 DEBUG 
[org.apereo.cas.support.saml.services.idp.metadata.SamlRegisteredServiceServiceProviderMetadataFacade]
 
- :8080 
] by attempting to run through the metadata 
chain...> sso-cas-overlay-sso-1 | 2024-02-23 15:26:08,303 DEBUG 
[org.apereo.cas.support.saml.services.idp.metadata.cache.SamlRegisteredServiceDefaultCachingMetadataResolver]
 
- https://md.aai.grnet.gr/aggregates/edugain-metadata.xml]> 
sso-cas-overlay-sso-1 | 2024-02-23 15:26:08,303 DEBUG 
[org.apereo.cas.support.saml.services.idp.metadata.SamlRegisteredServiceServiceProviderMetadataFacade]
 
- https://md.aai.grnet.gr/aggregates/edugain-metadata.xml] using 
[org.opensaml.saml.metadata.resolver.ChainingMetadataResolver]. Filtering 
the chain by entity ID [http://:8080 ]> 
sso-cas-overlay-sso-1 | 2024-02-23 15:26:08,303 DEBUG 
[org.apereo.cas.support.saml.services.idp.metadata.SamlRegisteredServiceServiceProviderMetadataFacade]
 
- :8080 
]. Metadata is valid until [forever]>  

So it seems that we can hack our way 

Re: [cas-user] Re: Multiple SAML Federated SP

[David Gelhar]

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  in 
> attribute-filter.xml, one can use theInEntityGroup 
> 
>  
> policy rule to match the names of any of the   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:
>
>
> 
> 
> 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  and this 
> . 
>
>
> 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 
> . 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 

Re: [cas-user] Re: Multiple SAML Federated SP

[David Gelhar]

We've had good success with wildcard service definitions for a single 
federation (InCommon), using a definition like:

"@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
"serviceId" : ".+",
"name" : "InCommon",
"evaluationOrder" : ,
"metadataLocation" : "https://mdq.incommon.org/entities/{0};,

(This is with CAS 6.6)
On Thursday, February 22, 2024 at 11:25:18 AM UTC-5 atilling wrote:

> If the regex serviceId worked as explained in the blog it would be simple. 
> However that ends up throwing errors that the metadata can't be parsed.
>
> On Wednesday, February 21, 2024 at 10:16:04 AM UTC-5 Kostas Kalevras wrote:
>
>> Or maybe implement the groupId feature present in Shibboleth?
>>
>> For example, the service definition could use the groupId as the entityId 
>> (ie http://edugain.org/) and have an additional flag signaling that we 
>> should use the service definition entityId to search if the SP entityId has 
>> a  value equal to that value.
>>
>> Στις Τετάρτη 21 Φεβρουαρίου 2024 στις 4:54:52 μ.μ. UTC+2, ο χρήστης Ray 
>> Bon έγραψε:
>>
>>> 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  in 
>>> attribute-filter.xml, one can use theInEntityGroup 
>>> 
>>>  
>>> policy rule to match the names of any of the   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:
>>>
>>>
>>> 
>>> 
>>> 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  
>>> and this . 
>>>
>>>
>>>
>>> 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 
>>> . 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: 

Re: [cas-user] Re: Multiple SAML Federated SP

[atilling]

If the regex serviceId worked as explained in the blog it would be simple. 
However that ends up throwing errors that the metadata can't be parsed.

On Wednesday, February 21, 2024 at 10:16:04 AM UTC-5 Kostas Kalevras wrote:

> Or maybe implement the groupId feature present in Shibboleth?
>
> For example, the service definition could use the groupId as the entityId 
> (ie http://edugain.org/) and have an additional flag signaling that we 
> should use the service definition entityId to search if the SP entityId has 
> a  value equal to that value.
>
> Στις Τετάρτη 21 Φεβρουαρίου 2024 στις 4:54:52 μ.μ. UTC+2, ο χρήστης Ray 
> Bon έγραψε:
>
>> 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  in 
>> attribute-filter.xml, one can use theInEntityGroup 
>> 
>>  
>> policy rule to match the names of any of the   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:
>>
>>
>> 
>> 
>> 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  and 
>> this . 
>>
>>
>> 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 
>> . 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/d9ddf59c-953d-4e32-8ab2-a4f86ec4c328n%40apereo.org.

Re: [cas-user] Re: Multiple SAML Federated SP

[Kostas Kalevras]

Or maybe implement the groupId feature present in Shibboleth?

For example, the service definition could use the groupId as the entityId 
(ie http://edugain.org/) and have an additional flag signaling that we 
should use the service definition entityId to search if the SP entityId has 
a  value equal to that value.

Στις Τετάρτη 21 Φεβρουαρίου 2024 στις 4:54:52 μ.μ. UTC+2, ο χρήστης Ray Bon 
έγραψε:

> 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  in 
> attribute-filter.xml, one can use theInEntityGroup 
> 
>  
> policy rule to match the names of any of the   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:
>
>
> 
> 
> 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  and this 
> . 
>
>
> 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 
> . 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/89ac0ecc-5113-42e7-acf6-36b4eb590311n%40apereo.org.

Re: [cas-user] Re: Multiple SAML Federated SP

[Ray Bon]

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 agroup service definition with a URL metadata endpoint which is regularly 
updated automatically.

In the shibboleth case, when setting up an  in 
attribute-filter.xml, one can use 
theInEntityGroup
 policy rule to match the names of any of the   in the 
relevant metadata and make the rule apply toall of the SPs that are included in 
the metadata. As a result we can include something like the following:



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

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. 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/d0775c7c24999b7327ab784ca66a61c130f4af91.camel%40uvic.ca.