The new SAML2 metadata aggregate not working in CAS 7.3.x
34 views
Skip to first unread message
Tomi Karlstedt
Dec 11, 2025, 9:02:44 AMDec 11
to CAS Community
Hi,
We are trying to figure out how to setup the new SAML2 IDP metadata aggregate in CAS 7.3.0 (i.e. property cas.authn.pac4j.saml[0].metadata.identity-provider-metadata-aggregate=true). There's no documentation on what needs to be configured and how so we're going here by hunch. So far we've found that there's two separate problems related to the auto-generated clients. All generated providers are given a client name that follows the pattern <original client name>-<random number>.
First of all this does not work in an environment with more than one server instance since the generated names are not deterministic. I.e. if you hit different nodes on your login page request and after you choose your IDP, you will get an error for missing delegated auth client. This can be mitigated with sticky sessions, but ultimately it would be good if this was fixed in CAS by generating a hash from the different entity IDs or something.
The second problem is that when returning from IDP authn request, CAS just can't find the chosen provider or at least we don't know how to configure CAS properly. This results in a error: "[org.apereo.cas.web.flow.actions.DelegatedClientAuthenticationAction] - <Unable to find client <original client name> to restore authentication context" and a terminated login flow.
The client name is normally given as a query parameter in the AssertionConsumerService location URL. There's a property called cas.authn.pac4j.saml[0].callback-url-type with the default value QUERY_PARAMETER. In the case of runtime generated client names this does not work. We can only set a static client name in the SAML2.0 federation SP metadata. Also CAS generates the SP metadata with the static client name.
However setting this callback-url-type to NONE, which is one of the defined values, the client name is omitted. CAS generates the SP metadata with AssertionConsumerService pointing to the login endpoint without parameters as expected. When returning from the IDP authn request, this results in a warning: "[org.apereo.cas.web.flow.login.InitializeLoginAction] - <No service authentication request is available at [<login url>]. CAS is configured to disable the flow.>" and an error page for the user. We disabled the mandatory service parameter and it looks like the authn request then results in a new authentication flow and the previous webflow state is lost.
I read through some CAS source code and I can only find one place that tries to fetch the client name (org.apereo.cas.pac4j.client.DelegatedClientNameExtractor). This implementation uses the URL (which does not work if aggregate metadata is used due to the autogenerated client names) and RelayState which makes sense in SAML2. However I don't think RelayState is populated with anything but the TGT id ever.
So, how is this supposed to work?
Tomi
We are trying to figure out how to setup the new SAML2 IDP metadata aggregate in CAS 7.3.0 (i.e. property cas.authn.pac4j.saml[0].metadata.identity-provider-metadata-aggregate=true). There's no documentation on what needs to be configured and how so we're going here by hunch. So far we've found that there's two separate problems related to the auto-generated clients. All generated providers are given a client name that follows the pattern <original client name>-<random number>.
First of all this does not work in an environment with more than one server instance since the generated names are not deterministic. I.e. if you hit different nodes on your login page request and after you choose your IDP, you will get an error for missing delegated auth client. This can be mitigated with sticky sessions, but ultimately it would be good if this was fixed in CAS by generating a hash from the different entity IDs or something.
The second problem is that when returning from IDP authn request, CAS just can't find the chosen provider or at least we don't know how to configure CAS properly. This results in a error: "[org.apereo.cas.web.flow.actions.DelegatedClientAuthenticationAction] - <Unable to find client <original client name> to restore authentication context" and a terminated login flow.
The client name is normally given as a query parameter in the AssertionConsumerService location URL. There's a property called cas.authn.pac4j.saml[0].callback-url-type with the default value QUERY_PARAMETER. In the case of runtime generated client names this does not work. We can only set a static client name in the SAML2.0 federation SP metadata. Also CAS generates the SP metadata with the static client name.
However setting this callback-url-type to NONE, which is one of the defined values, the client name is omitted. CAS generates the SP metadata with AssertionConsumerService pointing to the login endpoint without parameters as expected. When returning from the IDP authn request, this results in a warning: "[org.apereo.cas.web.flow.login.InitializeLoginAction] - <No service authentication request is available at [<login url>]. CAS is configured to disable the flow.>" and an error page for the user. We disabled the mandatory service parameter and it looks like the authn request then results in a new authentication flow and the previous webflow state is lost.
I read through some CAS source code and I can only find one place that tries to fetch the client name (org.apereo.cas.pac4j.client.DelegatedClientNameExtractor). This implementation uses the URL (which does not work if aggregate metadata is used due to the autogenerated client names) and RelayState which makes sense in SAML2. However I don't think RelayState is populated with anything but the TGT id ever.
So, how is this supposed to work?
Tomi
Reply all
Reply to author
Forward
0 new messages