nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Is External authentication subsystem safe? How does it work?

iblanco

It migth sound like a stupid question but I'm using it for CAS (through apache's mod_auth_cas) authentication and there are some points I don't understand.

I do understand that Apache's httpd server negotiates the session with CAS after checking it's certificate, so I do understand that Apache can get the user in a safe way, so far so good.

Once apache has the user it just passes the credentials to Tomcat through the AJP connector… but here my concerns arise. How does tomcat know that the connected AJP client is the right Apache and not a rogue one ? Is there some kind of check or does it simply rely on the correct configuration of the listening IP's and firewalls ?

What about the HTTP conector of Tomcat ? If the "external" authentication subsystem is activated can a fake HTTP request simulating "some credentials" access Alfresco or it just acts on the AJP side ?

Finally the wiki says that whole "/alfresco" Location should be protected by "mod_auth_cas" but that makes some "non web-ui" services like Webdav or "/service" not work.

I think that it would be enough just protecting "/alfresco/faces" , maybe even "/alfresco/faces/jsp/login.jsp" only. In the "standard" Alfresco Explorer every non authenticated request will be forwarded to the login page so that seems like no risk, and that makes Webdav and "service" authenticate through HTTP authentication.

Is this correct or is there any security implication ? If someone could confirm that point I would update the wiki.

Find more posts tagged with

Comments

mrogers

Yes you will need to set up firewalls to prevent "rogue" access to your instance of Alfresco.

The external authentication subsystem makes alfresco accept an external authentication token so you need to make sure that its not possible to abuse or subvert that trust.

iblanco

Thank you mrogers:

That's a clear answer, thank you very much.
I'll take some time to update the wiki I think this must be made very very clear in the wiki.
What about protecting with CAS only "/faces/jsp/login.jsp", would it be enough ?

Thanks.

iblanco

Finally I changed the Location Apache directive and instead used LocationMatch:

<LocationMatch ^/alfresco/(?!service/|service$|webdav/|webdav$|s/|s$).*>
 …your config here
</LocationMatch>‍‍‍

That should protect whole /alfresco/ urls except service, s and webdav. Probably I miss some other exceptions but adding them would be trivial and forgetting one just means that yo overprotect something, not that you miss something.

goldmar

The Wiki says:

The direct strategy is easier to set up and have one network hop less than the indirectstrategy (and that hop involves encryption using certs). It should in theory thus be a bit faster than the indirect strategy. However, to use the direct strategy you need to make sure that yoru alfresco server is well locked down, i.e. that no direct connection to port 8080 are possible. In other words, you have to enforce that all connections have to go through apache. This can be achieved easily with a firewall rule (like iptables on Linux). If the setup is not well locked, then a malicious user could log as any user just forging the auth header with the user he wants to log in as.

At least for me, limiting port 8080 to localhost was not enough. When I accessed alfresco via Apache with AJP, Apache still passed the X-Alfresco-Remote-User header to Alfresco and thus made it possible for any user to authenticate as admin.

Therefore, I've now added the following setting in Apache:

<LocationMatch ^/alfresco/(?!service/|service$|webdav/|webdav$|s/|s$).*>
  […]
  RequestHeader unset X-Alfresco-Remote-User
  […]
</LocationMatch>
‍‍‍‍‍‍

This should be safe. I think the Wiki should be adjusted to account for this issue. Or did I miss something and there is an easier way to lock down Alfresco?

iblanco

goldmar, I didn't have to deal with Share when I made this configuration, but what you comment sound reasonable to me.
I propose you to update the wiki yourself.

goldmar

I'm a bit confused right now… if you don't use Share, then you don't need to do all the steps written in the Wiki. You only need to protect /alfresco with mod_auth_cas and that's it. You don't need to deal with certificates and you don't have to (or even should not!) make Alfresco Explorer accept the X-Alfresco-Remote-User header because the authentification in Explorer works via the HttpServletRequest.getRemoteUser() method (which is not related to the header modification). You only need to accept the header in Explorer if you want to use proxy authentification (e.g. if you use Share, then Share is the proxy because you authenticate to Share and Share forwards the authentication to Explorer).

iblanco

That's it I only protect Apache with mod_auth_cas, but you have to make sure that Tomcat or AJP is not exposed directly for example through 8080 port. If I expose AJP port or tomcat's 8080 port publicly someone else could "chain" their apache with their mod_auth_cas configuration to MY alfresco, isn't it?

goldmar

Yeah, you're right - I did not think about it. I've probably been too focused on the header issue