A common scenario is to use Alfresco as a backend for managing content. Other applications access Alfresco using the REST API.
In this setup, another system has already authenticated the user and all requests are passed through this ”proxy”. If this is the case, Alfresco has an out-of-the-box solution. The ”External Authentication Subsystem”.
Step one is to activate the external authentication subsystem.
Next, we add the external authentication first in the authentication chain.
authentication.chain=external1:external,alfrescoNtlm1:alfrescoNtlm. Note that alfrescoNtlm refers to the default Alfresco authentication, meaning that the password hashes are stored in the Alfresco repository (userStore).
A simple way to test this is to try it out with curl.
curl -X GET -L -H "X-Alfresco-Remote-User: admin" http://localhost:8080/alfresco/wcservice/api/people
A thing to look at here is that the REST api endpoint is mapped to /wcservice. The regular /service or /s is hard-coded to basic authentication. So we need to use /wcservice. An other endpoint affected is /webdav. Cmis is not affected as far as I can tell.
Finally, we need to think about security. If we allow external access with this setup we obviously have created a major security hole. One way of addressing the problem is by using the
external.authentication.proxyUserName setting. If this setting is anything other than null/empty, alfresco will use SSL client certificate to identify and trust the proxy (hence enabling the header based authentication).
Here is a complete section of
#First header-based auth, then regular alfresco internal auth (default auth).
#disable proxy SSL client cert check - WARNING unsafe