Required assertionConsumerServiceUrl in SAML SP configuration?

60 views
Skip to first unread message

Petr Bodnár

unread,
Aug 27, 2024, 10:02:50 AM8/27/24
to CAS Community
Hi,

when registering a service provider (SP) to CAS via the JSON variant of configuration, one could historically fill in the assertionConsumerServiceUrl attribute, or leave it empty. The very same attribute comes in the SAML AuthnRequest and contains the URL where the SP wishes to send the SAML response.

So is it that the assertionConsumerServiceUrl in JSON configuration is just the default value for the case it is not present in the SAML AuthnRequest?

And if so, can somebody tell why this attribute was made required since some version of CAS 7.0.x (see commit ensure saml SLO/ACS objects have a valid location)? For our use case, we probably always want the SP to fill the URL in the request, but we are forced to also fill some value in the JSON configuration now, which doesn't seem to make sense?

Regards
Petr

Ray Bon

unread,
Aug 27, 2024, 2:37:01 PM8/27/24
to cas-...@apereo.org
Petr,

It is required in the service definition / saml metadata to prevent a malicious site from providing an ACS URL that does not match the entityId.

Ray

On Tue, 2024-08-27 at 06:16 -0700, Petr Bodnár wrote:
You don't often get email from p.bo...@centrum.cz. Learn why this is important
Hi,

when registering a service provider (SP) to CAS via the JSON variant of configuration, onecould historically fill in the assertionConsumerServiceUrl attribute, or leave it empty. The very same attribute comes in the SAML AuthnRequest and contains the URL where the SP wishes to send the SAML response.

So is it that the assertionConsumerServiceUrl in JSON configuration is just thedefault value for the case it is not present in the SAML AuthnRequest?

And if so, can somebody tell why this attribute was made required since some version of CAS 7.0.x (see commitensure saml SLO/ACS objects have a valid location)? For our use case, we probably always want the SP to fill the URL in the request, but we are forced to also fill some value in the JSON configuration now, which doesn't seem to make sense?

Regards
Petr


Petr Bodnár

unread,
Aug 28, 2024, 5:07:20 AM8/28/24
to CAS Community, Ray Bon
Hi Ray,

thanks for your answer. The problem is that the configured value doesn't seem to be checked against the incoming value at all. So we can fill in just a random string in the configuration. Tested with CAS 7.0.6.

Petr
Reply all
Reply to author
Forward
0 new messages