topic Re: Alfresco community 5.0.d with Jasig CAS in Alfresco Archive

Alfresco community 5.0.d with Jasig CAS

alexpaes — Thu, 28 May 2015 17:39:28 GMT

Hi everyone,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

Re: Alfresco community 5.0.d with Jasig CAS

idwright — Tue, 16 Jun 2015 10:28:00 GMT

I'm also trying to do this - I know things have changed in this area for 5.0.d…

In my localhost_access_log I'm seeing some 401 (permission denied):
127.0.0.1 - - [16/Jun/2015:13:36:54 +0000] "GET /alfresco/wcs/touch HTTP/1.1" 401 162

I've increased the logging a bit and see:
2015-06-16 09:18:24,870 DEBUG [site.servlet.SSOAuthenticationFilter] [localhost-startStop-1] Initializing the SSOAuthenticationFilter.
2015-06-16 09:18:24,874 DEBUG [site.servlet.SSOAuthenticationFilter] [localhost-startStop-1] Endpoint is alfresco
2015-06-16 09:18:24,875 DEBUG [site.servlet.SSOAuthenticationFilter] [localhost-startStop-1] userHeader is X-Alfresco-Remote-User
2015-06-16 09:18:24,876 DEBUG [site.servlet.SSOAuthenticationFilter] [localhost-startStop-1] userIdPattern is null
2015-06-16 09:18:24,876 INFO [site.servlet.SSOAuthenticationFilter] [localhost-startStop-1] SSOAuthenticationFilter initialised.

2015-06-16 13:25:50,091 DEBUG [site.servlet.SSOAuthenticationFilter] [http-bio-8080-exec-5] Initial login from externally authenticated user myuser
2015-06-16 13:25:50,092 DEBUG [site.servlet.SSOAuthenticationFilter] [http-bio-8080-exec-5] Accept-Language header present: en-GB,en;q=0.5
2015-06-16 13:25:50,106 DEBUG [app.servlet.WebScriptSSOAuthenticationFilter] [http-bio-8080-exec-9] Processing request: /alfresco/wcs/touch SID:null
2015-06-16 13:25:50,119 DEBUG [authentication.external.DefaultRemoteUserMapper] [http-bio-8080-exec-9] Getting RemoteUser from http request.
2015-06-16 13:25:50,119 DEBUG [authentication.external.DefaultRemoteUserMapper] [http-bio-8080-exec-9] The remote user id is: null
2015-06-16 13:25:50,120 DEBUG [authentication.external.DefaultRemoteUserMapper] [http-bio-8080-exec-9] The header user id is: null
2015-06-16 13:25:50,120 DEBUG [authentication.external.DefaultRemoteUserMapper] [http-bio-8080-exec-9] The proxy user name is: null
2015-06-16 13:25:50,120 DEBUG [authentication.external.DefaultRemoteUserMapper] [http-bio-8080-exec-9] Returning null
2015-06-16 13:25:50,126 DEBUG [site.servlet.SSOAuthenticationFilter] [http-bio-8080-exec-5] Repository session timed out - restarting auth process…

Note that share-config-custom.xml has changed since earlier versions

Re: Alfresco community 5.0.d with Jasig CAS

alexpaes — Wed, 17 Jun 2015 20:24:00 GMT

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.

Re: Alfresco community 5.0.d with Jasig CAS

idwright — Thu, 18 Jun 2015 09:37:28 GMT

Hi,
I've come to the same conclusion - that share is recognising the CAS user but not setting the SSO header on the calls to the repo

For logging I've added to the log4j.properties in the expanded WAR i.e. in /var/lib/tomcat7/webapps/share/WEB-INF/classes


log4j.logger.org.alfresco.web.site.servlet.SSOAuthenticationFilter=debug
‍‍‍

I've also tried logging the header in the localhost_access_log i.e. in …tomcat7/conf/server.xml
(It's never set)


        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log." suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %{X-Alfresco-Remote-User}i %b %{X-Alfresco-Remote-User}o" />
‍‍‍‍‍

I haven't yet managed to set up debugging with 5.0.d

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

Re: Alfresco community 5.0.d with Jasig CAS

alexpaes — Fri, 19 Jun 2015 08:50:19 GMT

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).

Re: Alfresco community 5.0.d with Jasig CAS

idwright — Fri, 19 Jun 2015 09:01:04 GMT

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>

So the major change is to SlingshotAlfrescoConnector.applyRequestHeaders
patch below
<blockcode>
09:33:50.018520440 +0100
@@ -25,13 +25,13 @@
import javax.servlet.http.HttpServletRequest;

import org.springframework.extensions.config.RemoteConfigElement.ConnectorDescriptor;
-import org.springframework.extensions.surf.ServletUtil;
import org.springframework.extensions.webscripts.RequestCachingConnector;
import org.springframework.extensions.webscripts.connector.AlfrescoConnector;
import org.springframework.extensions.webscripts.connector.Connector;
import org.springframework.extensions.webscripts.connector.ConnectorContext;
import org.springframework.extensions.webscripts.connector.ConnectorService;
import org.springframework.extensions.webscripts.connector.ConnectorSession;
+import org.springframework.extensions.webscripts.connector.Credentials;
import org.springframework.extensions.webscripts.connector.RemoteClient;

/**
@@ -185,15 +185,7 @@
             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);
+               String user = (String) getCredentials().getProperty(Credentials.CREDENTIAL_USERNAME);
                 if (user != null)
                 {
                     // MNT-11041 Share SSOAuthenticationFilter and non-ascii username strings

</blockcode>

Working share-config-custom.xml section with above

<blockcode>
   <config evaluator="string-compare" condition="Remote">
      <remote>
         <keystore>
            <path>alfresco/web-extension/alfresco-system.p12</path>
            <type>pkcs12</type>
            <password>alfresco-system</password>
         </keystore>

         <connector>
            <id>alfrescoCookie</id>
            <name>Alfresco Connector</name>
            <description>Connects to an Alfresco instance using cookie-based authentication</description>
            <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
            <userHeader>X-Alfresco-Remote-User</userHeader>
         </connector>

         <connector>
            <id>alfrescoHeader</id>
            <name>Alfresco Connector</name>
            <description>Connects to an Alfresco instance using header and cookie-based authentication</description>
            <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
            <userHeader>X-Alfresco-Remote-User</userHeader>
         </connector>

         <endpoint>
            <id>alfresco</id>
            <name>Alfresco - user access</name>
            <description>Access to Alfresco Repository WebScripts that require
               user authentication
            </description>
            <connector-id>alfrescoCookie</connector-id>
            <endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
            <identity>user</identity>
            <external-auth>true</external-auth>
         </endpoint>

         <endpoint>
            <id>alfresco-feed</id>
            <parent-id>alfresco</parent-id>
            <name>Alfresco Feed</name>
            <description>Alfresco Feed - supports basic HTTP authentication via
               the EndPointProxyServlet
            </description>
            <connector-id>alfrescoHeader</connector-id>
            <endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
            <identity>user</identity>
            <external-auth>true</external-auth>
         </endpoint>

         <endpoint>
            <id>alfresco-api</id>
            <parent-id>alfresco</parent-id>
            <name>Alfresco Public API - user access</name>
            <description>Access to Alfresco Repository Public API that require
               user authentication.
               This makes use of the authentication that is provided by parent
               'alfresco' endpoint.
            </description>
            <connector-id>alfrescoHeader</connector-id>
            <endpoint-url>http://localhost:8080/alfresco/api</endpoint-url>
            <identity>user</identity>
            <external-auth>true</external-auth>
         </endpoint>

      </remote>
   </config>
</blockcode>

I've created a JIRA - https://issues.alfresco.com/jira/browse/ALF-21367

Re: Alfresco community 5.0.d with Jasig CAS

alexpaes — Fri, 19 Jun 2015 16:10:30 GMT

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!

Re: Alfresco community 5.0.d with Jasig CAS

idwright — Mon, 22 Jun 2015 07:21:18 GMT

I would suggest starting with the SDK

It's also really useful to check out the code from svn

It should be fairly easy to search for these

Re: Alfresco community 5.0.d with Jasig CAS

idwright — Thu, 25 Jun 2015 08:53:00 GMT

I'm still looking at this but it's not a top priority for me at the moment

I'm getting error messages about integrity violations e.g. when creating a site however it still seems to work… (different unrelated problem now also solved)

I've noticed that there's no logout option enabled which there used to be

You've got access to the password change tab on the profile which you shouldn't have