Liferay laesst sich nciht per Basic authentication schuetzen

[Hans Kanns, geändert vor 14 Jahren.]

Hallo Community,

Ich habe versucht meine Liferay Installation per BASIC authentication zu schuetzen.

Mit einem standalone Tomcat ohne Liferay klappt es auch problemlos.

ROOT\WEB-INF\web.xml:

...
<security-constraint> 
    <web-resource-collection>
        <web-resource-name>everything</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>showroom</role-name>
    </auth-constraint>
</security-constraint>
<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>showroom</realm-name>
</login-config>
<security-role>
    <role-name>showroom</role-name>
</security-role>
...

tomcathome\conf\tomcat-users.xml

...
<tomcat-users>
    <user name="admin" password="admin" roles="admin,manager" />
    <role rolename="showroom" />
    <user username="hans" password="hans" roles="showroom,admin,manager" />
</tomcat-users>
...

In der tomcat + liferay installation habe ich dann noch einen Realm in der liferayhome\conf\server.xml hinzugefuegt

...
<realm className="org.apache.catalina.realm.MemoryRealm" />
...

Wenn ich nun den Server starte und im Browser auf localhost:8080 gehe, erscheint das Login-Popup und unabhaengig von den eingegebenen Daten wird folgender Stacktrace geworfen:

ERROR [UserLocalServiceImpl:629]
com.liferay.portal.NoSuchUserException: No User exists with the primary key 0
        at com.liferay.portal.service.persistence.UserPersistenceImpl.findByPrimaryKey(UserPersistenceImpl.java:622)
        at com.liferay.portal.service.impl.UserLocalServiceImpl.authenticateForJAAS(UserLocalServiceImpl.java:590)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
...

org.apache.catalina.realm.JAASRealm authenticate
WARNUNG: Login exception authenticating username "hans"
javax.security.auth.login.LoginException
        at com.liferay.portal.security.jaas.ext.BasicLoginModule.login(BasicLoginModule.java:97)
        at com.liferay.portal.security.jaas.PortalLoginModule.login(PortalLoginModule.java:111)
        at com.liferay.portal.kernel.security.jaas.PortalLoginModule.login(PortalLoginModule.java:72)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
...

Error 1: es scheint mir, als wuerde die tomcat-users.xml nicht gefunden
Error 2: Wird hier der JAAS anstatt der MemoryRealm benutzt?


danke fuer sachdienliche Hinweise

MfG Hans

[Olaf Kock, geändert vor 14 Jahren.]

Liferay kommt selbst mit einer recht umfangreichen Benutzerverwaltung. Ich vermute, dass diese ebenfalls versucht, die Logindaten aus der Basic-Authentication auswertet und versucht, den offensichtlich gerade angemeldeten (Basic) Benutzer in der eigenen Datenbank zu finden. Die Annahme, dass ein angemeldeter Benutzer auch in der Benutzerdatenbank zu finden ist, ist dabei erstmal keine schlechte - funktioniert aber nicht, wenn die Benutzerinformationen nur in einem Tomcat-Realm stehen, nicht aber in der Liferay-Benutzerdatenbank.

(Disclaimer: Ich hab's nicht selbst ausprobiert, alles ist nur eine Vermutung)

Ich stelle mir allerdings die Frage, was ein "zusätzlicher" Schutz per Basic-Auth nutzen soll. Reicht es nicht, die entsprechenden zu schützenden Seiten mit den Liferay-Maßnahmen zu schützen?

[Hans Kanns, geändert vor 14 Jahren.]

Es geht darum, ein Portal so lange vor dem Google Bot zu "schuetzen", bis es fertig zum Livegang ist.

Auch ein komplett neues Liferay, bei dem ausschließlich der test account und eine Hypersonic DB existieren funktioniert die BASIC Methode nicht.
Habe auch versucht den testuser in den realm zu schreiben, ohne Erfolg.


Gruß
Hans

[Olaf Kock, geändert vor 14 Jahren.]

Gegen den Googlebot und andere "gute" Bots hilft auch robots.txt. Die "bösen" Bots bringen eh keinen Traffic. Wenn's nicht um generelle Geheimhaltung geht, würde ich dazu raten.

Zugegeben: Hilft nicht, wenn der gesamte Inhalt auch nicht aus der Gerüchteküche bekannt werden soll... Ansonsten gibt's immer noch die Liferay-eigenen Zugriffsrechte, die man bei Liveschaltung dann wieder wegnehmen kann. Die Guest-Community kann man auch schützen, so dass man sich bei Liferay anmelden muss, bevor man Zugriff auf die Seite bekommt.

[Hans Kanns, geändert vor 14 Jahren.]

Olaf Kock:

Gegen den Googlebot und andere "gute" Bots hilft auch robots.txt. Die "bösen" Bots bringen eh keinen Traffic. Wenn's nicht um generelle Geheimhaltung geht, würde ich dazu raten.

...

Es geht leider um beide Sachen. Es gilt die Inhalte sowohl der Allgemeinheit, als auch den bots unzugaenglich zu machen ohne einen großen Konfigurationsaufwand zu haben.

Gruß
Hans

[Olaf Kock, geändert vor 14 Jahren.]

Ich halte es für "großen Aufwand" Liferay so zu verändern, dass es mit Basic Authentication klarkommt. "Kleiner Aufwand" ist die Veränderung der Site, so dass die darzustellende Community zunächst per Login geschützt ist. Kurz vor Online-Schaltung kann dann der Aspekt der öffentlichen Verfügbarkeit noch explizit getestet werden - wenn es dann egal ist, wenn jemand den Inhalt sehen kann.

Als Alternativen kann ich mir vorstellen:

• Begrenzung des Zugriffs auf bestimmte Client-IP-Adressen
• Installationen in einem geschützten Bereich (DMZ) + VPN für die Clients, die auf die DMZ zugreifen
• Schlechte Sicherheit durch "erfinden" eines nicht-öffentlichen DNS-Namens, den die Clients in ihren eigenen Hosts-Dateien eintragen

Außer Konkurrenz, weil ich nicht weiß, wie Liferay damit umgeht, könnten "Client Side Certificates" (o.ä.) im Falle von HTTPS helfen - soweit ich weiß, kann man die Vertrauensstellungen dazu auch bereits von Apache abprüfen lassen. Das macht aber sicher etwas mehr Aufwand...

[Dominik Förderreuther, geändert vor 14 Jahren.]

Hallo,

wir haben diese Anforderung relativ häufig, wenn Kunden nicht wollen, dass ihre Portale auf dem Preview-Server öffentlich zugänglich sind. Wir machen hierfür einfach Port 8080 über die Firewall dicht und stellen die Basic authentication im VirtualHost des Apache ein. Das funktioniert völlig problemlos.

Einfaches Beispiel:

<virtualhost *>
        JkMount  /* worker1
        <location />
                AuthType Basic
                AuthName "Testseite"
                AuthUserFile /etc/apache2/.htpass
                Require valid-user
        
</virtualhost>

Viele Grüße,
Dominik