Rollen und Rechte: LDAP-Gruppen → Liberty-Security-Rollen

Status: verifiziert. Alle Ergebnisse unten sind echte curl-Antworten gegen einen laufenden Liberty-Server mit echter LDAP-Anbindung (siehe 02-ldap-registry.md).

Das Modell

Liberty trennt bewusst zwei Ebenen (Standard-Jakarta-EE-Security-Modell, hier gegen LDAP verifiziert):

1. Wer ist der Nutzer? → beantwortet vom ldapRegistry (Authentifizierung), siehe 02-ldap-registry.md.
2. Was darf der Nutzer? → beantwortet von der application-bnd (auch "authorization table" genannt) in server.xml: sie bildet LDAP-Gruppen auf Anwendungs-Rollen ab.

<webApplication id="concordia-portal" location="concordia-portal.war" name="concordia-portal">
    <application-bnd>
        <security-role name="PortalAdmin">
            <group name="concordia-portal-admins"/>
        </security-role>
        <security-role name="PortalUser">
            <group name="concordia-portal-users"/>
        </security-role>
    </application-bnd>
</webApplication>

Wichtig: die Rollennamen (PortalAdmin, PortalUser) sind anwendungsspezifisch und werden in web.xml (security-role, security-constraint) UND hier in server.xml (application-bnd) verwendet — die LDAP-Gruppennamen (concordia-portal-admins) sind dagegen Sache des Verzeichnisses (siehe infra/openldap/bootstrap/01-concordia-bank.ldif). Ein WAS-Admin, der eine neue Rolle einführt, muss beide Seiten pflegen — ein häufiger Anfängerfehler ist, nur die eine Seite zu ändern und sich zu wundern, warum die Rolle nicht greift.

web.xml: welche URLs geschützt sind

<security-constraint>
    <web-resource-collection>
        <web-resource-name>secure-area</web-resource-name>
        <url-pattern>/secure/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>PortalUser</role-name>
        <role-name>PortalAdmin</role-name>
    </auth-constraint>
</security-constraint>
<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>ConcordiaBankLDAP</realm-name>
</login-config>

/health bleibt bewusst außerhalb dieses url-pattern — siehe HealthServlet.java: ein Health-Check, der selbst an Login-Credentials scheitern kann, macht Load-Balancer-Checks unbrauchbar (relevant für docs/70-high-availability/).

Verifikation: vier echte Testfälle gegen den laufenden Server

$ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:19080/concordia-portal/secure/whoami
401

$ curl -s -u "m.bauer:AdminDemo123!" http://localhost:19080/concordia-portal/secure/whoami
{"principal":"m.bauer","isPortalAdmin":true,"isPortalUser":false}

$ curl -s -o /dev/null -w "%{http_code}\n" -u "m.bauer:falsch123" http://localhost:19080/concordia-portal/secure/whoami
401

$ curl -s -u "j.klein:UserDemo123!" http://localhost:19080/concordia-portal/secure/whoami
{"principal":"j.klein","isPortalAdmin":false,"isPortalUser":true}

Was das beweist:

• Ohne Credentials → 401 (Liberty erzwingt BASIC-Auth, bevor der Servlet-Code überhaupt läuft).
• m.bauer (Mitglied von concordia-portal-admins im LDAP, siehe Bootstrap-LDIF) bekommt korrekt isPortalAdmin: true, aber isPortalUser: false — sie ist NICHT Mitglied der User-Gruppe, das Rollen-Mapping ist also nicht "jeder LDAP-Nutzer bekommt alles", sondern exakt gruppenscharf.
• Falsches Passwort → 401 — die Prüfung geht wirklich gegen den LDAP-Bind, nicht gegen eine lokale Nutzerliste.
• j.klein (nur concordia-portal-users) bekommt spiegelbildlich isPortalUser: true, isPortalAdmin: false.

Siehe WhoAmIServlet.java für die Implementierung (request.isUserInRole(...)).