Στις Παρασκευή 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" :
10000, "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://<my-site>:8080 <http://sso.edunet.gr:8080/>", "name"
: "SimpleSAMLPHP", "id" : 4005, "evaluationOrder" : 50000,
"attributeReleasePolicy": { "@class":
"org.apereo.cas.services.ReturnAllAttributeReleasePolicy", "consentPolicy":
{ "@class":
"org.apereo.cas.services.consent.DefaultRegisteredServiceConsentPolicy",
"status": "FALSE" } }, "metadataLocation" : "
http://<my-site>:8080/simplesaml/module.php/saml/sp/metadata.php/default-sp
<http://sso.edunet.gr: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]
- <Locating metadata for entityID [http://<my-site>:8080
<http://sso.edunet.gr: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]
- <Resolving metadata for [EDUGAIN] at [
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]
- <Resolved metadata chain from [
https://md.aai.grnet.gr/aggregates/edugain-metadata.xml] using
[org.opensaml.saml.metadata.resolver.ChainingMetadataResolver]. Filtering
the chain by entity ID [http://<my-site>:8080 <http://sso.edunet.gr:8080/>]>
sso-cas-overlay-sso-1 | 2024-02-23 15:26:08,303 DEBUG
[org.apereo.cas.support.saml.services.idp.metadata.SamlRegisteredServiceServiceProviderMetadataFacade]
- <Located SP SSODescriptor in metadata for [http://<my-site>:8080
<http://sso.edunet.gr:8080/>]. Metadata is valid until [forever]>
So it seems that we can hack our way through, with the caveat that all
federated services will end up to a single service definition and thus one
attribute release policy/MFA policy etc.
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 as
this <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/4ca4bdcc-7849-48f7-a61f-2697d3eb8d67n%40apereo.org.
