Comment puis-je supprimer le ROLE_ préfixe du Printemps de Sécurité avec JavaConfig?

J'essaie de retirer le "ROLE_" préfixe au Printemps de Sécurité. La première chose que j'ai essayé était:

http.servletApi().rolePrefix("");

Qui n'a pas fonctionné, j'ai donc essayé de créer un BeanPostProcessor comme suggéré dans http://docs.spring.io/spring-security/site/migrate/current/3-to-4/html5/migrate-3-to-4-jc.html#m3to4-role-prefixing-disable. Qui n'a pas fonctionné non plus.

Enfin, j'ai essayé de créer mon propre SecurityExpressionHandler:

  @Override
  protected void configure(HttpSecurity http) throws Exception {
      http
          .authorizeRequests()
          .expressionHandler(webExpressionHandler())
          .antMatchers("/restricted").fullyAuthenticated()
          .antMatchers("/foo").hasRole("mycustomrolename")
          .antMatchers("/**").permitAll();
  }

  private SecurityExpressionHandler<FilterInvocation> webExpressionHandler() {
      DefaultWebSecurityExpressionHandler defaultWebSecurityExpressionHandler = new DefaultWebSecurityExpressionHandler();
      defaultWebSecurityExpressionHandler.setDefaultRolePrefix("");
      return defaultWebSecurityExpressionHandler;
  }

Toutefois, cela ne fonctionne pas non plus. Si j'utilise "hasAuthority(roleName)" au lieu de hasRole, il fonctionne comme prévu.

Est-il possible de supprimer le ROLE_ préfixe du Printemps de Sécurité de l'hasRole vérifier?

Étrange le BeanPostProcessor fonctionne pour moi (vous avez le déclarer comme une static méthode d'haricot et inclus la PriorityOrdered de sorte qu'il s'exécute très tôt?) et de même pour le gestionnaire d'expression. Nous avons également une DefaultMethodSecurityExpressionHandlerDefaultMethodSecurityExpressionHandler` configurée avec l'ensemble de préfixes la null.
Oui, j'ai copié le code de la BeanPostProcessor directement à partir de la documentation. J'ai essayé de mettre le @Bean dans mon @Configuration classe pour le Printemps de Sécurité et dans mon @SpringBootApplication classe. J'ai ajouté un System.out.println pour s'assurer qu'il est configuré avant le Printemps de la Sécurité. hasAuthority fonctionne comme prévu, donc je pense que je vais l'utiliser à la place.
Nous avons dans un non de printemps de l'application de démarrage. Pourrait-elle être celle qui est atteinte ou que la sécurité de démarrage est en quelque sorte encore configuré auparavant?

OriginalL'auteur Matt Raible | 2016-06-30

  1. 16

    De départ à partir du Printemps 4.2, vous pouvez définir le préfixe avec un seul haricot, comme décrit ici: https://github.com/spring-projects/spring-security/issues/4134

    @Bean
GrantedAuthorityDefaults grantedAuthorityDefaults() {
    return new GrantedAuthorityDefaults(""); //Remove the ROLE_ prefix
}

    XML version:

    <beans:bean id="grantedAuthorityDefaults" class="org.springframework.security.config.core.GrantedAuthorityDefaults">
    <beans:constructor-arg value="" />
</beans:bean>
    N'a pas Fonctionné pour moi
    Ne fonctionne pas: voir le 4ème commentaire en question stackoverflow.com/questions/46756013
    Il a travaillé ennemi me suffit bien. Merci!!!!
    Il y a une différence entre un GrantedAuthority et un Rôle. Cette réponse est pour GrantedAuthority.
    Celui-ci fonctionne pour moi

    OriginalL'auteur Antoine Melki

  2. 7

    La configuration suivante fonctionne pour moi.

    @Override
public void configure(WebSecurity web) throws Exception {
    web.expressionHandler(new DefaultWebSecurityExpressionHandler() {
        @Override
        protected SecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, FilterInvocation fi) {
            WebSecurityExpressionRoot root = (WebSecurityExpressionRoot) super.createSecurityExpressionRoot(authentication, fi);
            root.setDefaultRolePrefix(""); //remove the prefix ROLE_
            return root;
        }
    });
}
    fonctionne très bien avec le printemps de sécurité 5, ty pour le partage.

    OriginalL'auteur walsh

  3. 3

    Si vous êtes avant 4.2 et utilisez donc appelé les électeurs (si vous utilisez des annotations comme @hasRole etc) ensuite, vous devez définir ci-dessous les haricots dans le contexte:

    @Bean
public DefaultMethodSecurityExpressionHandler defaultMethodSecurityExpressionHandler() {
    DefaultMethodSecurityExpressionHandler defaultMethodSecurityExpressionHandler = new DefaultMethodSecurityExpressionHandler();
    defaultMethodSecurityExpressionHandler.setDefaultRolePrefix("");
    return defaultMethodSecurityExpressionHandler;
}

@Bean
public DefaultWebSecurityExpressionHandler defaultWebSecurityExpressionHandler() {
    DefaultWebSecurityExpressionHandler defaultWebSecurityExpressionHandler = new DefaultWebSecurityExpressionHandler();
    defaultWebSecurityExpressionHandler.setDefaultRolePrefix("");
    return defaultWebSecurityExpressionHandler;
}

    Ces haricots sont utilisés pour créer de l'évaluation de contexte pour le sort des expressions et ils ont un defaultRolePrefix mis à 'ROLE_'. Même si cela dépend de votre cas d'utilisation. Ceci a travaillé pour moi et au-dessus n'a pas.

    EDIT: répondre à la question au sujet de configuration xml -> bien sûr, il peut être fait en xml. Tout ce qui est fait en java config peut être écrit en xml de configuration. Voici un exemple (bien que je n'ai pas tester donc il y aura peut être une faute de frappe ou quelque chose):

    <bean id="defaultWebSecurityExpressionHandler" class="org.springframework.security.web.access.expression.DefaultWebSecurityExpressionHandler">
        <property name="defaultRolePrefix" value=""></property>
</bean>

<bean id="defaultMethodSecurityExpressionHandler" class="org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler">
        <property name="defaultRolePrefix" value=""></property>
</bean>
    Est-il un équivalent en configuration XML?
    J'ai mis à jour ma réponse xml de config... mais comme je l'ai écrit, il y a peut être une erreur - je n'ai pas testé. La règle générale est - tout en java config peut être fait en xml.
    La configuration xml fonctionne pas pour moi.
    échoue dans mon JHipster application pendant le démarrage, avec org.springframework.beans.factory.BeanCreationException: .......; nested exception is java.lang.IllegalArgumentException: A ServletContext is required to configure default servlet handling
    Petr - c'est juste une je devine, mais si vous obtenez cette erreur, cela signifie probablement que vous ne disposez pas d'un contexte web de sorte que vous n'avez pas besoin de la deuxième bean - DefaultWebSecurityExpressionHandler. De toute façon, chaque configuration est différente, donc il est difficile de dire ce que le problème est vraiment dans votre cas, les gars. Pour moi, ces deux haricots résolu le problème.

    OriginalL'auteur Piotr Tempes

  4. 2

    Il semble que le nouveau GrantedAuthorityDefaults va changer le préfixe de la DefaultWebSecurityExpressionHandler et la DefaultMethodSecurityExpressionHandler, mais il ne modifie pas la RoleVoter.rolePrefix qui est de l'installation de @EnableGlobalMethodSecurity.

    La RoleVoter.rolePrefix est ce qui est utilisé pour @Secured("ADMIN") style de la méthode de sécurité.

    Ainsi, en plus de la GrantedAuthorityDefaults, j'ai dû également ajouter cette CustomGlobalMethodSecurity classe pour remplacer les valeurs par défaut pour RoleVoter.

    @Configuration
@EnableGlobalMethodSecurity(securedEnabled = true)
public class CustomGlobalMethodSecurity extends GlobalMethodSecurityConfiguration {

    protected AccessDecisionManager accessDecisionManager() {
        AffirmativeBased accessDecisionManager = (AffirmativeBased) super.accessDecisionManager();

        //Remove the ROLE_ prefix from RoleVoter for @Secured and hasRole checks on methods
        accessDecisionManager.getDecisionVoters().stream()
                .filter(RoleVoter.class::isInstance)
                .map(RoleVoter.class::cast)
                .forEach(it -> it.setRolePrefix(""));

        return accessDecisionManager;
    }
}
    J'ai utiliser le @EnableGlobalMethodSecurity dans WebSecurityConfigurerAdapter, comment obtenir l'accès à AccessDecisionManager?
    Le AccessDecisionManager devra être configuré dans une classe supplémentaire, car je ne crois pas qu'il peut être fait à partir de la WebSecurityConfigurerAdapter. Je pense que vous aurez juste besoin de créer une nouvelle Configuration de la classe qui étend la classe GlobalMethodSecurityConfiguration

    OriginalL'auteur Jeff Sheets

  5. 0

    Si vous utilisez le Printemps de Démarrage 2, vous pouvez créer ce bean pour remplacer le RoteVoter préfixe

    @Bean
public GrantedAuthorityDefaults grantedAuthorityDefaults() {
    return  new GrantedAuthorityDefaults("<anything you want>");
}

    Il fonctionne parce que quand GlobalMethodSecurityConfiguration crée AccessDecisionManager dans la méthode GlobalMethodSecurityConfiguration.accessDecisionManager(). Voici l'extrait de code, l'avis de la valeur null vérifier sur grantedAuthorityDefaults

        protected AccessDecisionManager accessDecisionManager() {
    ....
    RoleVoter roleVoter = new RoleVoter();
    GrantedAuthorityDefaults grantedAuthorityDefaults =
            getSingleBeanOrNull(GrantedAuthorityDefaults.class);
    if (grantedAuthorityDefaults != null) {
        roleVoter.setRolePrefix(grantedAuthorityDefaults.getRolePrefix());
    }
    decisionVoters.add(roleVoter);
    decisionVoters.add(new AuthenticatedVoter());
    return new AffirmativeBased(decisionVoters);
}

    OriginalL'auteur Hung Tran