CAS 7.0.x to 7.2.x SAML 1.1 Issue

[Phil Hale]

I have an older CAS client that is using SAML 1.1 protocol.  I'm able to get a successful login to the client application initially, but when navigating to a sub-menu of the app I get a "Couldn't access remote service" error on the app and in the logs I see the following log error:

WARN [org.apereo.cas.util.function.FunctionUtils] - <Invalid key for dir with A256CBC-HS512, expected a 512 bit key but a 256 bit key was provided.

I've done some google searches and not found an answer to this issue. Anyone have an idea what's causing this and what we might do to resolve it?

Thanks,

Phil

[Richard Frovarp]

You have two different problems.

Your CAS IdP needs to have its keys properly configured. There should be something more in that warning to indicate which key is 256 bit instead of the 512 bit. Follow documentation once you find that to update the key or specify the length as 256. This is breaking SSO probably?

The second problem is your CAS client isn't configured correctly. Once you authenticate through the first time, it is up to the application to maintain session state. The fact that you get an error when clicking on a different link in the app means that the app doesn't have you logged in, and is depending on continually using SSO logins, which breaks some HTTP methods.

--
- Website: https://apereo.github.io/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+u...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/0a464edd-9d87-47b8-aad3-859151f937a2n%40apereo.org.

[Phil Hale]

Thanks for the response Richard,

The funny thing is that the same configuration and options do work under CAS 7.0 and stopped working on the upgrade to 7.2. I've also sent the information to the client side admin since it's a very old client application and I feel it might be something they may need to look at.  The CAS service is working just fine for all other clients, including SSO service.

Just hoping someone might have encountered this error and give me some places to look at.

Phil

[Ocean Liu]

Hi Phil,

I think Richard was on the right track.

When we upgraded to CAS 7.2.x, we had the same problem.

We solved it by updating the `cas.tgc.crypto.encryption.key` to a 512 bit key.

If you are not sure, you can delete `cas.tgc.crypto.encryption.key` attribute from your configuration, and then CAS will generated a new one when you start the app, check the logs, copy the new generated key to the config.

And it is strange that the sub domain of the app does not retain the authenticated session, I am not sure why it needs to authenticate again.

Best,

Ocean

[Phil Hale]

Hello Ocean,

That did the trick!  Thanks for the assist. I've requested more thorough testing from the service provider team, but in my testing it seems to be working.  The SP is a very old Ellucian Banner application that uses the SAML 1.1 protocol for SSO.  I think that team is looking at upgrading to Azure SSO at some point, so I just need to keep this working for a little longer.

Thanks,

Phil

[Ocean Liu]

Glad it worked! 

--

Ocean Liu | Enterprise Web Developer | Whitman College

WCTS Building 105F - 509.527.4973