Alfresco community 5.0.d with Jasig CAS

Does anyone here managed to get similar setup running? I can get the CAS screen for logging in but after authentication the call to Share keeps sending me back to Share's login form. I do not get any errors whatsoever in catalina.out or alfresco.log regarding this issue.

I've had similar setup working with Alfresco 4.2.e and didn't have this problem.

Hi, I've somewhat managed to check and my results are very similar to yours but unfortunately my knowledge of Alfresco is so limited I've not been able to find a solution for this yet. Can you please elaborate on how you setup the debugging? I managed to debug some classes but not all that you have on your post.

Please let me know if you make any progress on this matter and I will do the same.

Btw, do you know any place where the share-config-custom.xml changes are documented?

P.S - After debugging some more I've noticed that in my case the SSO header is not included in the call to /alfresco/wcs/touch which might explain the HTTP 401. The reason why this headers is not included is totally beyond my knowledge.

The only docs I'm aware of are the comments in the sample file, there may be more elsewhere…I'm a bit suspicious about the comments wrt the alfresco endpoint connector in share-config-custom.xml - previously CAS was working with alfrescoCookie and I think that's probably right but am trying it with alfrescoHeader as well anyway

I've managed to get Alfresco 5 running on 5.0.c (note the C not D) with all the same settings on a different server. So I've just changed my primary server down to 5.0.c release and everything is working as expected.

I'm assuming something has changed in 5.0.d release with SSOAuthenticationFilter or any other class that is part of the External SSO mechanism.

Now it's off to get the Solr4 working (broken after I replaced the keystore with my own certificates).

I think this has been broken in the latest release it looks like the header is supposed to be set in SlingshotAlfrescoConnector.applyRequestHeaders

In the old version it got the username from the credentials and set it as the header (Old version from googling SlingshotAlfrescoConnector)<blockcode> // Proxy the authenticated user name if we have password-less credentials (indicates SSO auth over a secure // connection) if (getCredentials() != null) { String user = (String) getCredentials().getProperty(Credentials.CREDENTIAL_USERNAME); String pass = (String) getCredentials().getProperty(Credentials.CREDENTIAL_PASSWORD); if (pass == null) { headers.put("X-Alfresco-Remote-User", user); } String userHeader = getUserHeader(); if (userHeader != null) { headers.put(userHeader, user); } }</blockcode>

In the new version (from svn) it looks like it is trying to copy the header information from the incoming request but as the username is in this.credentials not the request header it's never going to work

It also means that it's (potentially) using completely different credentials - surely if it needs to use the username from the request then that should have been loaded into the credentials object already…

<blockcode> // Proxy the authenticated user name if we have password-less credentials (indicates SSO auth over a secure connection) if (getCredentials() != null) { String userHeader = getUserHeader(); if (userHeader != null) { // TODO: This is not ideal - for scenarios where the request has come through a Spring Dispatcher servlet // the request will be available in the ServletUtil helper, else if it has come through another route // it will be available on the MTAuthenticationFilter - this should be resolved. HttpServletRequest req = ServletUtil.getRequest(); if (req == null) { req = MTAuthenticationFilter.getCurrentServletRequest(); } String user = req.getHeader(userHeader); if (user != null) { // MNT-11041 Share SSOAuthenticationFilter and non-ascii username strings if (!org.apache.commons.codec.binary.Base64.isBase64(user)) { try { user = org.apache.commons.codec.binary.Base64.encodeBase64String((new String(user.getBytes("ISO-8859-1"), "UTF-8")).getBytes("UTF-8")); } catch (UnsupportedEncodingException e) { //TODO } headers.put("Remote-User-Encode", Boolean.TRUE.toString()); } headers.put(userHeader, user); } } }</blockcode>

That's an awesome work! I think I need to start thinking about setting up an Alfresco development environment for tackling these situations. It's pretty difficult to find the causes (and eventually solutions or workarounds) for these situations just by traversing the logs.

Do you by any chance have any resource on setting up such a development environment for Alfresco?

Thank you so much for your valuable help and big congratulations of solving this!