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
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
Στις Παρασκευή 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
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
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" :
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
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
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
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
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
10 matches
Mail list logo
