Faites-le simplement de la manière habituelle, puis insérez-le en utilisant SecurityContextHolder.setContext() dans votre classe de test, par exemple:

Contrôleur:

Authentication a = SecurityContextHolder.getContext().getAuthentication();

Test:

Authentication authentication = Mockito.mock(Authentication.class);
// Mockito.whens() for your authorization object
SecurityContext securityContext = Mockito.mock(SecurityContext.class);
Mockito.when(securityContext.getAuthentication()).thenReturn(authentication);
SecurityContextHolder.setContext(securityContext);

Vous avez tout à fait raison d'être concerné - les appels de méthodes statiques sont particulièrement problématiques pour les tests unitaires car vous ne pouvez pas facilement vous moquer de vos dépendances. Ce que je vais vous montrer, c'est comment laisser le conteneur Spring IoC faire le sale boulot pour vous, vous laissant avec un code soigné et testable. SecurityContextHolder est une classe framework et bien qu'il soit possible que votre code de sécurité de bas niveau y soit lié, vous voulez probablement exposer une interface plus propre à vos composants D'interface utilisateur (c'est-à-dire contrôleur).

Falaise.meyers a mentionné une façon de contourner cela-créez votre propre type "principal" et injectez une instance dans les consommateurs. La balise Spring aop:scoped-proxy/> introduite dans 2.x combiné avec une définition de bean de portée de requête, et le support de la méthode d'usine peut être le ticket pour le code le plus lisible.

Cela pourrait fonctionner comme suit:

public class MyUserDetails implements UserDetails {
    // this is your custom UserDetails implementation to serve as a principal
    // implement the Spring methods and add your own methods as appropriate
}

public class MyUserHolder {
    public static MyUserDetails getUserDetails() {
        Authentication a = SecurityContextHolder.getContext().getAuthentication();
        if (a == null) {
            return null;
        } else {
            return (MyUserDetails) a.getPrincipal();
        }
    }
}

public class MyUserAwareController {        
    MyUserDetails currentUser;

    public void setCurrentUser(MyUserDetails currentUser) { 
        this.currentUser = currentUser;
    }

    // controller code
}

Rien de compliqué jusqu'à présent, non? En fait, vous avez probablement dû faire la plupart de cela déjà. Ensuite, dans votre bean contexte définir un bean à portée de requête pour contenir le principal:

<bean id="userDetails" class="MyUserHolder" factory-method="getUserDetails" scope="request">
    <aop:scoped-proxy/>
</bean>

<bean id="controller" class="MyUserAwareController">
    <property name="currentUser" ref="userDetails"/>
    <!-- other props -->
</bean>

Grâce à la magie de la balise AOP:scoped-proxy, la méthode statique getUserDetails sera appelée chaque fois qu'une nouvelle requête HTTP arrivera et toutes les références à la propriété currentUser seront résolues correctement. Maintenant, les tests unitaires deviennent triviaux:

protected void setUp() {
    // existing init code

    MyUserDetails user = new MyUserDetails();
    // set up user as you wish
    controller.setCurrentUser(user);
}

Espérons que cela aide!

Sans répondre à la question sur la façon de créer et d'injecter des objets D'authentification, Spring Security 4.0 fournit des alternatives bienvenues en matière de test. L'annotation @WithMockUser permet au développeur de spécifier un utilisateur fictif (avec des autorités facultatives, un nom d'utilisateur, un mot de passe et des rôles) de manière ordonnée:

@Test
@WithMockUser(username = "admin", authorities = { "ADMIN", "USER" })
public void getMessageWithMockUserCustomAuthorities() {
    String message = messageService.getMessage();
    ...
}

Il y a aussi la possibilité d'utiliser @WithUserDetails pour émuler un UserDetails renvoyé par le UserDetailsService, par exemple

@Test
@WithUserDetails("customUsername")
public void getMessageWithUserDetailsCustomUsername() {
    String message = messageService.getMessage();
    ...
}

Plus de détails peuvent être trouvés dans le @WithMockUser et les chapitres @ WithUserDetails dans les documents de référence de sécurité Spring (à partir desquels les exemples ci-dessus ont été copiés)

Personnellement, j'utiliserais simplement Powermock avec Mockito ou Easymock pour me moquer du SecurityContextHolder statique.getSecurityContext () dans votre unité / test d'intégration par exemple

@RunWith(PowerMockRunner.class)
@PrepareForTest(SecurityContextHolder.class)
public class YourTestCase {

    @Mock SecurityContext mockSecurityContext;

    @Test
    public void testMethodThatCallsStaticMethod() {
        // Set mock behaviour/expectations on the mockSecurityContext
        when(mockSecurityContext.getAuthentication()).thenReturn(...)
        ...
        // Tell mockito to use Powermock to mock the SecurityContextHolder
        PowerMockito.mockStatic(SecurityContextHolder.class);

        // use Mockito to set up your expectation on SecurityContextHolder.getSecurityContext()
        Mockito.when(SecurityContextHolder.getSecurityContext()).thenReturn(mockSecurityContext);
        ...
    }
}

Certes, il y a un peu de code de Plaque de chaudière ici, c'est-à-dire simuler un objet D'authentification, simuler un SecurityContext pour retourner l'authentification et enfin simuler le SecurityContextHolder pour obtenir le SecurityContext, mais c'est très flexible et vous permet de tester l'unité pour des scénarios comme null Objets d'authentification, etc. sans avoir à changer votre code (non test)

L'utilisation d'un statique dans ce cas est la meilleure façon d'écrire du code sécurisé.

Oui, la statique est généralement mauvaise-généralement, mais dans ce cas, la statique est ce que vous voulez. Étant donné que le contexte de sécurité associe un Principal au thread en cours d'exécution, le code le plus sécurisé accéderait à la statique à partir du thread aussi directement que possible. Cacher l'accès derrière une classe wrapper qui est injectée fournit à un attaquant plus de points à attaquer. Ils n'auraient pas besoin d'accéder au code (qu'ils auraient du mal à changer si le jar était signé), ils ont juste besoin d'un moyen de remplacer la configuration, ce qui peut être fait à l'exécution ou glisser du XML sur le classpath. Même en utilisant l'injection d'annotation serait substituable avec XML externe. Un tel XML pourrait injecter le système en cours d'exécution avec un principal voyou.

J'ai posé la même question moi-même sur ici, et je viens de poster une réponse que j'ai récemment trouvée. La réponse courte est: injectez un SecurityContext, et référez-vous à SecurityContextHolder seulement dans votre configuration de printemps pour obtenir le SecurityContext

Je voudrais jeter un oeil aux classes de test abstraites de Spring et aux objets fictifs dont on parle ici. Ils fournissent un moyen puissant de câblage automatique de vos objets gérés Spring, ce qui facilite les tests d'unité et d'intégration.

Généralités

En attendant (depuis la version 3.2, en 2013, grâce à SEC-2298) l'authentification peut être injectée dans les méthodes MVC en utilisant l'annotation @AuthenticationPrincipal :

@Controller
class Controller {
  @RequestMapping("/somewhere")
  public void doStuff(@AuthenticationPrincipal UserDetails myUser) {
  }
}

Essais

Dans votre test unitaire, vous pouvez évidemment appeler cette méthode directement. Dans les tests d'intégration utilisant org.springframework.test.web.servlet.MockMvc, vous pouvez utiliser org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.user() pour injecter l'utilisateur comme ceci:

mockMvc.perform(get("/somewhere").with(user(myUserDetails)));

Cela remplira cependant directement le SecurityContext. Si vous voulez faire assurez-vous que l'utilisateur est chargé à partir d'une session dans votre test, vous pouvez utiliser ceci:

mockMvc.perform(get("/somewhere").with(sessionUser(myUserDetails)));
/* ... */
private static RequestPostProcessor sessionUser(final UserDetails userDetails) {
    return new RequestPostProcessor() {
        @Override
        public MockHttpServletRequest postProcessRequest(final MockHttpServletRequest request) {
            final SecurityContext securityContext = new SecurityContextImpl();
            securityContext.setAuthentication(
                new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities())
            );
            request.getSession().setAttribute(
                HttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY, securityContext
            );
            return request;
        }
    };
}

Authentification est une propriété d'un fil dans un environnement serveur de la même manière qu'il est une propriété d'un processus en OS. Avoir une instance bean pour accéder aux informations d'authentification serait une configuration et un câblage gênants sans aucun avantage.

En ce qui concerne l'authentification de test, il existe plusieurs façons de vous faciliter la vie. Mon préféré est de faire une annotation personnalisée @Authenticated et tester l'écouteur d'exécution, qui le gère. Vérifiez DirtiesContextTestExecutionListener pour l'inspiration.

Après beaucoup de travail, j'ai pu reproduire le comportement désiré. J'avais émulé la connexion via MockMvc. C'est trop lourd pour la plupart des tests unitaires, mais utile pour les tests d'intégration.

Bien sûr, je suis prêt à voir ces nouvelles fonctionnalités dans Spring Security 4.0 qui rendront nos tests plus faciles.

package [myPackage]

import static org.junit.Assert.*;

import javax.inject.Inject;
import javax.servlet.http.HttpSession;

import org.junit.Before;
import org.junit.Test;
import org.junit.experimental.runners.Enclosed;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.mock.web.MockHttpServletRequest;
import org.springframework.security.core.context.SecurityContext;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.FilterChainProxy;
import org.springframework.security.web.context.HttpSessionSecurityContextRepository;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.web.WebAppConfiguration;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;

@ContextConfiguration(locations={[my config file locations]})
@WebAppConfiguration
@RunWith(SpringJUnit4ClassRunner.class)
public static class getUserConfigurationTester{

    private MockMvc mockMvc;

    @Autowired
    private FilterChainProxy springSecurityFilterChain;

    @Autowired
    private MockHttpServletRequest request;

    @Autowired
    private WebApplicationContext webappContext;

    @Before  
    public void init() {  
        mockMvc = MockMvcBuilders.webAppContextSetup(webappContext)
                    .addFilters(springSecurityFilterChain)
                    .build();
    }  


    @Test
    public void testTwoReads() throws Exception{                        

    HttpSession session  = mockMvc.perform(post("/j_spring_security_check")
                        .param("j_username", "admin_001")
                        .param("j_password", "secret007"))
                        .andDo(print())
                        .andExpect(status().isMovedTemporarily())
                        .andExpect(redirectedUrl("/index"))
                        .andReturn()
                        .getRequest()
                        .getSession();

    request.setSession(session);

    SecurityContext securityContext = (SecurityContext)   session.getAttribute(HttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY);

    SecurityContextHolder.setContext(securityContext);

        // Your test goes here. User is logged with 
}