CAS 6.6 problem with SAML and Liferay.

[Juan Fernando Rivera]

Hi, I'm following the guidelines of configuring a SAML service in CAS, but I'm having trouble connecting to Liferay portal.

In Liferay were created the certificates and imported in the idp-metadata file which was sent back to Liferay and imported. Everything runs fine, BUT after entering the credentials in CAS, this error (or similar) appears in Liferay logs:

2024-10-04 21:51:11.830 DEBUG [http-nio-0.0.0.0-9444-exec-4][ApacheSantuarioSignatureValidationProviderImpl:65] Validating signature with signature algorithm URI: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
2024-10-04 21:51:11.830 DEBUG [http-nio-0.0.0.0-9444-exec-4][ApacheSantuarioSignatureValidationProviderImpl:66] Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl'
2024-10-04 21:51:11.831 WARN  [http-nio-0.0.0.0-9444-exec-4][XMLSignature:891] Signature verification failed.
2024-10-04 21:51:11.831 DEBUG [http-nio-0.0.0.0-9444-exec-4][ApacheSantuarioSignatureValidationProviderImpl:78] Signature cryptographic validation not successful
2024-10-04 21:51:11.831 DEBUG [http-nio-0.0.0.0-9444-exec-4][BaseSignatureTrustEngine:244] Signature validation using candidate validation credential failed
org.opensaml.xmlsec.signature.support.SignatureException: Signature cryptographic validation not successful

.....

2024-10-04 21:51:11.832 DEBUG [http-nio-0.0.0.0-9444-exec-4][ExplicitKeySignatureTrustEngine:124] Failed to verify signature using either KeyInfo-derived or directly trusted credentials
2024-10-04 21:51:11.833 DEBUG [http-nio-0.0.0.0-9444-exec-4][SAMLProtocolMessageXMLSignatureSecurityHandler:142] Message Handler:  Validation of protocol message signature failed for context issuer 'ENTITY_ID', message type: {urn:oasis:names:tc:SAML:2.0:protocol}Response
2024-10-04 21:51:11.833 DEBUG [http-nio-0.0.0.0-9444-exec-4][WebSsoProfileImpl:210] Validation of protocol message signature failed

.....

According to the Liferay admin, the main issue may come from CAS, because is not using the right key to generate the values in the SAML Response. Other reason may be encryption or signature.

I have tried both encryption and signature options in service.json file, but no avail, the errors are th same.

How can I verify this suspicions of Liferay admin? how can I force CAS to use a certain private key to generate the data in SAML response?

Thanks in advance.

[Ray Bon]

Juan,

Can you clarify your description of the certificates and metadata?

Liferay will create SP metadata with encryption certificate (and maybe signing too); you will create IdP metadata (cas will do this if it does not exist) with signing and encryption certificates. You point cas config at the certificates that you (or cas) created. Liferay SP certificates should be different from your IdP certificates.

Ray

On Sun, 2024-10-06 at 14:53 -0700, Juan Fernando Rivera wrote:

You don't often get email from eljua...@gmail.com. Learn why this is important

[Juan Fernando Rivera]

Hi, reading your post I think the problem is that the files in "/etc/cas/saml" (idp-encryption.*, idp-signing.*) are created every time CAS is restarted. I know that in a production environment this won't be an issue, but right now it is.

Is there a way to prevent these files to recreating everytime my CAS container is restarted?

Thanks in advance.

[Juan Fernando Rivera]

Hi, sorry for the lateness, I was experimenting with the setup:

I have a service defined in "service.json" it has ID 1751, and serviceId is the entityId for SAML.

The service has the following definition:

{

    "@class": "org.apereo.cas.support.saml.services.SamlRegisteredService",

    "id": 1751,

    "evaluationOrder": 1751,

    "serviceId": "SERVER/saml/liferay",

    "name": "pruebaSAML",

    "attributeReleasePolicy" : {

        "@class" : "org.apereo.cas.services.ReturnAllowedAttributeReleasePolicy",

        "allowedAttributes" : [ "java.util.ArrayList", [ "mail" ] ]

    },

   

    "usernameAttributeProvider": {

        "@class": "org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider",

        "usernameAttribute": "mail",

        "canonicalizationMode": "LOWER"

    },

    "metadataLocation": "file:///etc/cas/saml/sp-pruebaSAML-metadata.xml",

    "metadataSignatureLocation": "file:///etc/cas/saml/pruebaSAML-1751/idp-signing.crt"

}

The file sp-pruebaSAML-metadata.xml contains the certificate created at Liferay. Also that certificate is stored in the file specified at the metadataSignatureLocation property of the service.

I have the metadata in the dir "/etc/cas/saml/service-1751". That metadata was constructed from the URL "casServer/idp/metadata" changing the following:

• entityID (I changed it for the one defined in the service.json file)
• X509Certificate (using one created outside of CAS)

From what I read in your post 

"You point cas config at the certificates that you (or cas) created"

Surely this point is missing or misconfigured. How can I ensure that cas is pointing to the certificates I created, and put into the idp-metadata stored in the dir "/etc/cas/saml/service-1751" ?

Thanks in advance.

 

On Monday, October 7, 2024 at 12:43:28 PM UTC-6 Ray Bon wrote:

[Ray Bon]

Juan,

Cas will create IdP metadata and certificates if they do not exist (save them for future deploys). For your dev setup, you will have to add them to the directory before cas starts; either COPY into your container image or mount the volume when the container starts. If you use a traditional deployment (jenkins etc) let the tool install them.

Ray

On Wed, 2024-10-09 at 17:53 -0700, Juan Fernando Rivera wrote:

You don't often get email from eljua...@gmail.com. Learn why this is important

Hi, reading your post I think the problem is that the files in "/etc/cas/saml" (idp-encryption.*, idp-signing.*) are created every time CAS is restarted. I know that in a production environment this won't be an issue, but right now it is.

Is there a way to prevent these files to recreating everytime my CAS container is restarted?

Thanks in advance.

On Monday, October 7, 2024 at 12:43:28 PM UTC-6 Ray Bon wrote:

Juan,

Can you clarify your description of the certificates and metadata?

Liferay will create SP metadata with encryption certificate (and maybe signing too); you will create IdP metadata (cas will do this if it does not exist) with signing and encryption certificates. You point cas config at the certificates that you (or cas) created. Liferay SP certificates should be different from your IdP certificates.

Ray

On Sun, 2024-10-06 at 14:53 -0700, Juan Fernando Rivera wrote:

You don't often get email from eljua...@gmail.com.Learn why this is important

[Ray Bon]

Juan,

Is the liferay metadata signed?

i.e., does the SP metadata include:

<ds:SignedInfo>

<ds:SignatureValue>

sections?

metadataSignatureLocation

is for a certificate to verify the metadata is legitimate; so not idp-signing.crt. You would use this when you want to verify automatically downloaded metadata. Federations will sign but typical SP do not. Since you have the metadata file, you do not need to check the signature, since you already know its source. The certificate for metadata signature validation would be acquired out of band (i.e. not included in metadata).

You would create a directory 'pruebaSAML-1751' when you want to have custom IdP metadata for that single service, otherwise let cas use the metadata it (or you) created. Per service IdP metadata is an advanced config.

Let cas create the IdP metadata and certificates, then save them somewhere to be use with each deploy. This way you can be sure IdP metadata and certs are created the way cas needs them. Note: your ops team can go through the same process (letting cas create its own Idp metadata and certs) if that fits with your security policies.

Do not change the SP entityId. The serviceId will be the entityId provided by the SP. You do not need to muck about with SP certificates, cas will use the ones in the metadata, if they exist.

Hopefully all that makes sense.

Ray

You don't often get email from eljua...@gmail.com.Learn why this is important

[Juan Fernando Rivera]

Thanks for answering, with your help I've been able to pinpoint the exact cause of my issues with Liferay. 

BUT copying the keys prior to start CAS is not working, you see, I'm developing using Docker containers, and before starting the image I copy a lot of files, including the keys, and I've found these messages in CAS log (most relevant in yellow). The main reason is that the testing environment is a Docker container. It's CAS 6.6.

-------8<------

[org.apereo.cas.support.saml.idp.metadata.generator.BaseSamlIdPMetadataGenerator] - <Preparing to generate metadata for entity id [ENTITY]>
2024-10-10 16:14:52 2024-10-10 10:14:52,315 INFO [org.apereo.cas.support.saml.idp.metadata.generator.BaseSamlIdPMetadataGenerator] - <Creating self-signed certificate for signing...>
2024-10-10 16:14:52 2024-10-10 10:14:52,316 INFO [org.apereo.cas.support.saml.idp.metadata.generator.FileSystemSamlIdPMetadataGenerator] - <Certificate file [/etc/cas/saml/idp-signing.crt] already exists, and will be deleted>
2024-10-10 16:14:52 2024-10-10 10:14:52,422 INFO [org.apereo.cas.support.saml.idp.metadata.generator.FileSystemSamlIdPMetadataGenerator] - <Key file [/etc/cas/saml/idp-signing.key] already exists, and will be deleted>
2024-10-10 16:14:54 2024-10-10 10:14:54,032 INFO [org.apereo.cas.support.saml.idp.metadata.generator.BaseSamlIdPMetadataGenerator] - <Creating self-signed certificate for encryption...>
2024-10-10 16:14:54 2024-10-10 10:14:54,033 INFO [org.apereo.cas.support.saml.idp.metadata.generator.FileSystemSamlIdPMetadataGenerator] - <Certificate file [/etc/cas/saml/idp-encryption.crt] already exists, and will be deleted>
2024-10-10 16:14:54 2024-10-10 10:14:54,033 INFO [org.apereo.cas.support.saml.idp.metadata.generator.FileSystemSamlIdPMetadataGenerator] - <Key file [/etc/cas/saml/idp-encryption.key] already exists, and will be deleted>
------->8------

So, every time the container starts, because at 1800 it's stopped every day, even when the keys are copied to the image prior to start CAS, they are deleted and re-created by CAS. Confirmed when inspecting the files in the container. And the prior idp-metadata imported by Liferay is not valid anymore. Until re-imported.

Is there a property to override this behaviour?

So far, the workaround is re-creating the idp-metadata using CAS endpoint "/idp/metadata", and re-importing it in Liferay, it takes no longer than 2 minutes, but the client is worried that in the production environment, where is known that docker container restart with no reason, this can be troublesome.

Thanks again.

[Ray Bon]

Juan,

Those log lines are generated on line 114 in this file https://github.com/apereo/cas/blob/c4c45442a5abef69c05fdb5fc94c88068241d8df/support/cas-server-support-saml-idp-core/src/main/java/org/apereo/cas/support/saml/idp/metadata/generator/FileSystemSamlIdPMetadataGenerator.java

Not sure why certs are being recreated; could be something higher up the call stack or a config setting.

That class makes use of a registered service.

I too run cas in docker on my local. My docker-compose.yml mounts my local files; cas does not recreate them.

I run version 7.0. I wonder if something changed between the versions.

You can add this logger to get more details:

<Logger name="org.apereo.cas.support.saml" level="trace">

abstract class AbstractSamlIdPMetadataLocator

has a number of trace logging lines that could help.

Ray

[Juan Fernando Rivera]

Thanks. For some strange reason, it does not happen in the client testing environment.... Don't ask me why, but in case it happens, he told me there is no problem in implementing the workaround.

Other errors appeared, but the initial diagnosis are different configurations between the testing Liferay portal and the one I used for development, so far, apparently there is no futhermore CAS issue, but in case I need help, I'll ask again here.

Again, many thanks for your valuable input.