Spring Security Frage fuer Fortgeschrittene

[klarkimming]

Hallo,

Folgendes Problem:

1. Ein Nutzer loggt sich

2. Ein Admin sperrt den Nutzer

3. Der Nutzer schickt einen Request ab.

Problem:

Spring Security fuehrt NUR einmal eine Authentifizierung durch. Sprich bei Schritt drei wird der Zugriff nicht verweigert OBWOHL der Nutzer in der DB schon gesperrt ist.

Meine konkrette Frage ist:

Wie schaffe ich es das Spring-Security IMMER eine Pruefung der Daten durchfuehrt ?

Anmerkung bitte auf die Problemstellung achten. Es geht nicht um einen Nutzer der seine Daten aendert, sondern um einen Admin, der die Daten eines anderen Nutzers aendert!

Sprich ich kann nicht einfach den Context aktualisieren bzw. loeschen. Ich muesste Zugriff auf alle Contexte haben oder auf alle Session des Tomcats. Beide Moeglichkeiten sind so weit ich weiss nicht moeglich.

Meine Idee war einen zusaetzlichen AuthenticationFilter einzubauen. Allerdings muesste dann auch die Methode "requiresAuthentication" ueberschrieben werden, was zu ein paar Problemen fuehrt....

Umgebung:

Spring Security Version: 2.0.1
Spring
JPA mit Hibernate

Config:

<!-- Security -->
    <bean id="permissionVoter" class="org.springframework.security.vote.RoleVoter">
        <property name="rolePrefix" value=""/>
    </bean>

    <bean id="accessDecisionManager" class="org.springframework.security.vote.UnanimousBased">
        <property name="decisionVoters">
            <list>
                <ref bean="permissionVoter"/>    
            </list>
        </property>
        <property name="allowIfAllAbstainDecisions" value="true"/>
    </bean>

    <security:http once-per-request="true" access-decision-manager-ref="accessDecisionManager">
        <security:intercept-url pattern="/processpartner*.do" access="ADMINISTRATEPROCESSPARTNER"/>
        <security:intercept-url pattern="/user*.do" access="ADMINISTRATEUSER"/>
        <security:intercept-url pattern="/*.do" access="COMMON"/>
        <security:form-login login-page='/views/Login.jsp'/>

    </security:http>

    <security:authentication-provider user-service-ref="userService"/>

 

[Thomas Darimont]

Hallo,

eine einfache aber eher ineffiziente Methode wäre wohl den SessinContext
über einen ServletFilter nach jedem Request null zu setzen.

net.sf.acegisecurity.context.ContextHolder.setContext(null);

Falls dein Authentication Provider die User Credentials Cachen sollte, muss du hier den Cache noch mal (bei Bedarf) aktualisieren: Das möchte man natürlich nur dann tun, wenn es wirklich notwendig wist (user wurde gerade gesperrt).

Sicherlich gibt es da im Framework noch eine effizientere Methode.

Gruß Tom

 

[Oliver Gierke]

Schuss ins Blaue, aber kannst du nicht über die SessionRegistry.getAllPrincipals() herausbekommen ob der User, den du blocken willst gerade eingeloggt ist und einfach dessen Session killen?

Der Weg wäre AuthenticationManager -> SessionController -> SessionRegistry.

Gruß
Ollie

 

[klarkimming]

Hallo,

danke an alle fuer die Hinweise. Der Kunde ist aber mittlerweile zur Entscheidung gelangt, dass es genuegt, wenn die Daten erst beim naechsten Login aktuell sind....

Falls jemand das Problem trotzdem noch hat:

Eine Loesung ist vermutlich:

- Erstellen eines AuthenticationFilter mit "before"
- dort "setAuthenticated(false)"-- Das gibt allerdings ggf. Probleme mit der ConcurrentSession Control!! bzw. mit dem Wechsel eines Passwortes des Nutzers selbst. Es muesste dann ein neues AuthenticationObject im Filter erstellt werden und der Nutzer muesste aus dem von Oliver beschriebenen Pool entfernt werden.

@Oliver: Der Zugriff auf die Principals waere schon ein erster Schritt. Allerdings muss dafuer ein ConcurrentSessionControll defniert sein. Darueber hinaus ist der Zugriff auf die Contexte selbst noetig, um die Authentication zu invalidieren bzw. ein neues AuthenticationObject zu erstellen....

@Thomas:
Habs ausprobiert. Hat nicht funktioniert. Eine genaue Fehleranalyse haben wir nicht durchgefuehrt, da das Setzen des Context auf null aus unserer Sicht ein erheblicher Eingriff waere...