Доступ всегда отрицается в Spring Безопасность - DenyAllPermissionEvaluator
Я настроил ACL в моем приложении Spring Boot. Конфигурация ACL выглядит следующим образом:
@Configuration
@ComponentScan(basePackages = "com.company")
@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true)
public class ACLConfigration extends GlobalMethodSecurityConfiguration {
@Autowired
DataSource dataSource;
@Bean
public EhCacheBasedAclCache aclCache() {
return new EhCacheBasedAclCache(aclEhCacheFactoryBean().getObject(), permissionGrantingStrategy(), aclAuthorizationStrategy());
}
@Bean
public EhCacheFactoryBean aclEhCacheFactoryBean() {
EhCacheFactoryBean ehCacheFactoryBean = new EhCacheFactoryBean();
ehCacheFactoryBean.setCacheManager(aclCacheManager().getObject());
ehCacheFactoryBean.setCacheName("aclCache");
return ehCacheFactoryBean;
}
@Bean
public EhCacheManagerFactoryBean aclCacheManager() {
return new EhCacheManagerFactoryBean();
}
@Bean
public DefaultPermissionGrantingStrategy permissionGrantingStrategy() {
ConsoleAuditLogger consoleAuditLogger = new ConsoleAuditLogger();
return new DefaultPermissionGrantingStrategy(consoleAuditLogger);
}
@Bean
public AclAuthorizationStrategy aclAuthorizationStrategy() {
return new AclAuthorizationStrategyImpl(new SimpleGrantedAuthority("ROLE_ACL_ADMIN"));
}
@Bean
public LookupStrategy lookupStrategy() {
return new BasicLookupStrategy(dataSource, aclCache(), aclAuthorizationStrategy(), new ConsoleAuditLogger());
}
@Bean
public JdbcMutableAclService aclService() {
return new JdbcMutableAclService(dataSource, lookupStrategy(), aclCache());
}
@Bean
public DefaultMethodSecurityExpressionHandler defaultMethodSecurityExpressionHandler() {
return new DefaultMethodSecurityExpressionHandler();
}
@Override
public MethodSecurityExpressionHandler createExpressionHandler() {
DefaultMethodSecurityExpressionHandler expressionHandler = defaultMethodSecurityExpressionHandler();
expressionHandler.setPermissionEvaluator(new AclPermissionEvaluator(aclService()));
expressionHandler.setPermissionCacheOptimizer(new AclPermissionCacheOptimizer(aclService()));
return expressionHandler;
}
}
Литература:
и конфигурация безопасности выглядит следующим образом:
@Configuration
@EnableWebSecurity
public class CustomSecurityConfiguration extends WebSecurityConfigurerAdapter {
@Bean
public AuthenticationEntryPoint entryPoint() {
return new LoginUrlAuthenticationEntryPoint("/authenticate");
}
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.csrf()
.disable()
.authorizeRequests()
.antMatchers("/authenticate/**").permitAll()
.anyRequest().fullyAuthenticated()
.and().requestCache().requestCache(new NullRequestCache())
.and().addFilterBefore(authenticationFilter(), CustomUsernamePasswordAuthenticationFilter.class);
}
@Override
public void configure(WebSecurity web) throws Exception {
web.ignoring().antMatchers(HttpMethod.OPTIONS, "/**");
}
@Bean
public CustomUsernamePasswordAuthenticationFilter authenticationFilter()
throws Exception {
CustomUsernamePasswordAuthenticationFilter authenticationFilter = new CustomUsernamePasswordAuthenticationFilter();
authenticationFilter.setUsernameParameter("username");
authenticationFilter.setPasswordParameter("password");
authenticationFilter.setFilterProcessesUrl("/authenticate");
authenticationFilter.setAuthenticationSuccessHandler(new CustomAuthenticationSuccessHandler());
authenticationFilter.setAuthenticationFailureHandler(new CustomAuthenticationFailureHandler());
authenticationFilter.setAuthenticationManager(authenticationManagerBean());
return authenticationFilter;
}
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
}
Мой CustomAuthenticationProvider
класс:
@Component
public class CustomAuthenticationProvider implements AuthenticationProvider {
@Autowired
private UsersService usersService;
@Override
public Authentication authenticate(Authentication authentication)
throws AuthenticationException {
String username = authentication.getName();
String password = authentication.getCredentials().toString();
User user = usersService.findOne(username);
if(user != null && usersService.comparePassword(user, password)){
return new UsernamePasswordAuthenticationToken(
user.getUsername(),
user.getPassword(),
AuthorityUtils.commaSeparatedStringToAuthorityList(
user.getUserRoles().stream().collect(Collectors.joining(","))));
} else {
return null;
}
}
@Override
public boolean supports(Class<?> authentication) {
return authentication.equals(UsernamePasswordAuthenticationToken.class);
}
}
Здесь мой CustomUsernamePasswordAuthenticationToken
:
public class CustomUsernamePasswordAuthenticationFilter extends UsernamePasswordAuthenticationFilter {
@Override
public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response)
throws AuthenticationException {
if(!request.getMethod().equals("POST"))
throw new AuthenticationServiceException(String.format("Authentication method not supported: %s", request.getMethod()));
try {
CustomUsernamePasswordAuthenticationForm form = new ObjectMapper().readValue(request.getReader(), CustomUsernamePasswordAuthenticationForm.class);
String username = form.getUsername();
String password = form.getPassword();
if(username == null)
username = "";
if(password == null)
password = "";
UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(username, password);
setDetails(request, token);
return getAuthenticationManager().authenticate(token);
} catch (IOException exception) {
throw new CustomAuthenticationException(exception);
}
}
private class CustomAuthenticationException extends RuntimeException {
private CustomAuthenticationException(Throwable throwable) {
super(throwable);
}
}
}
Помимо вышеизложенного, у меня есть CustomAuthenticationFailureHandler
, CustomAuthenticationSuccessHandler
, CustomNoRedirectStrategy
и CustomUsernamePasswordAuthenticationForm
, которые я пропустил ради этой длины вопроса.
И я использую схему MySQL, которую можно найти здесь.
Я добавляю записи в мои связанные с acl таблицы следующим образом:
INSERT INTO acl_class VALUES (1, com.company.project.domain.users.User)
INSERT INTO acl_sid VALUES (1, 1, "demo")
(У меня есть пользователь с именем пользователя demo
)
INSERT INTO acl_object_identity VALUES (1, 1, 1, NULL, 1, 0)
INSERT INTO acl_entry VALUES (1, 1, 1, 1, 1, 1, 1, 1)
Но все, что я получаю, это:
Denying user demo permission 'READ' on object [email protected]
в моем
@PostFilter("hasPermission(filterObject, 'READ')")
Я подозреваю несколько вопросов здесь:
- Выражение
hasPermission
: я заменил его "READ" и "1", но ни в коем случае.
- Мои записи в базе данных неверны.
- Я не внедряю специализированный оценщик разрешений. Требуется ли это, или это
expressionHandler.setPermissionEvaluator(new AclPermissionEvaluator(aclService()));
достаточно?
Обновление
Пример метода, в котором используется @PostFilter
:
@RequestMapping(method = RequestMethod.GET)
@PostFilter("hasPermission(filterObject, 'READ')")
List<User> find(@Min(0) @RequestParam(value = "limit", required = false, defaultValue = "10") Integer limit,
@Min(0) @RequestParam(value = "page", required = false, defaultValue = "0") Integer page,
@RequestParam(value = "email", required = false) String email,
@RequestParam(value = "firstName", required = false) String firstName,
@RequestParam(value = "lastName", required = false) String lastName,
@RequestParam(value = "userRole", required = false) String userRole) {
return usersService.find(
limit,
page,
email,
firstName,
lastName,
userRole);
}
Обновление # 2:
Теперь вопрос отражает все, что было настроено в отношении аутентификации/авторизации/ACL.
Обновление # 3:
Теперь я очень близок к решению проблемы, осталось только решить следующее:
https://stackoverflow.com/info/42996579/custom-permissionevaluator-not-called-although-set-as-permissionevaluator-deny
Если кто-нибудь может помочь мне в этом вопросе, я могу, наконец, написать о том, что я сделал, чтобы решить эту проблему.
Ответы
Ответ 1
Вот долгожданный ответ:
документация четко описывает:
Чтобы использовать выражения hasPermission(), вам необходимо явно настроить PermissionEvaluator в контексте вашего приложения. Это будет выглядеть что-то вроде этого:
так что в основном я делал в своем AclConfiguration
, который расширяет GlobalMethodSecurityConfiguration
:
@Override
protected MethodSecurityExpressionHandler createExpressionHandler() {
DefaultMethodSecurityExpressionHandler expressionHandler = new DefaultMethodSecurityExpressionHandler();
expressionHandler.setPermissionEvaluator(new AclPermissionEvaluator(aclService()));
expressionHandler.setPermissionCacheOptimizer(new AclPermissionCacheOptimizer(aclService()));
return expressionHandler;
}
Что не обрабатывалось Spring!
Мне пришлось отделить AclConfig
и GlobalMethodSecurityConfiguration
. Когда в последнем указано @Bean
, указанный выше метод не обрабатывается, что может быть ошибкой (если нет, то любое разъяснение по теме приветствуется).
Ответ 2
Я обновил свое приложение, чтобы использовать Spring Security 4.2.1.RELEASE, после чего я начал испытывать неожиданный доступ, запрещенный во всех @PreAuthorize
аннотированных методах, который работал отлично до обновления.
Я отлаживал код безопасности Spring, и я понял, что проблема в том, что все роли, которые нужно проверить, имеют префикс строки по умолчанию "ROLE_", независимо от того, что я установил префикс по умолчанию для пустого, как показано в коде ниже.
auth.ldapAuthentication()
.groupSearchBase(ldapProperties.getProperty("groupSearchBase"))
.groupRoleAttribute(ldapProperties.getProperty("groupRoleAttribute"))
.groupSearchFilter(ldapProperties.getProperty("groupSearchFilter"))
//this call used to be plenty to override the default prefix
.rolePrefix("")
.userSearchBase(ldapProperties.getProperty("userSearchBase"))
.userSearchFilter(ldapProperties.getProperty("userSearchFilter"))
.contextSource(this.ldapContextSource);
Все мои методы контроллера были аннотированы с помощью @PreAuthorize("hasRole('my_ldap_group_name')")
, однако структура не учитывала мою пустую настройку префикса ролей и поэтому использовала ROLE_my_ldap_group_name для проверки фактической роли.
После того, как я углубился в код фреймворка, я понял, что класс org.springframework.security.web.access.expression.DefaultWebSecurityExpressionHandler
по-прежнему имеет префикс роли по умолчанию, установленный на "ROLE_"
. Я отслеживал источник его значения, и я узнал, что он сначала проверял объявленный bean класса org.springframework.security.config.core.GrantedAuthorityDefaults
на поиск префикса по умолчанию при первой инициализации bean org.springframework.security.config.annotation.web.configurers.ExpressionUrlAuthorizationConfigurer
, однако, поскольку этот инициализатор bean не смог найти его объявленным, он в конечном итоге использовал вышеупомянутый префикс по умолчанию.
Я считаю, что это не ожидаемое поведение: Spring Однако для решения этой проблемы безопасность должна была учитывать тот же параметр rolePrefix из ldapAuthentication, что необходимо было добавить bean org.springframework.security.config.core.GrantedAuthorityDefaults
в мой контекст приложения (I 'm, используя конфигурацию на основе аннотаций), как показано ниже:
@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class CesSecurityConfiguration extends WebSecurityConfigurerAdapter {
private static final String ROLE_PREFIX = "";
//... ommited code ...
@Bean
public GrantedAuthorityDefaults grantedAuthorityDefaults() {
return new GrantedAuthorityDefaults(ROLE_PREFIX);
}
}
Возможно, у вас такая же проблема: я мог видеть, что вы используете DefaultMethodSecurityExpressionHandler, а также использует bean GrantedAuthorityDefaults, поэтому, если вы используете ту же самую версию безопасности Spring как я - 4.2.1.RELEASE вы, вероятно, сталкиваетесь с той же проблемой.
Ответ 3
Ваши данные в БД и вашей конфигурации выглядят хорошо. Я использую @PostFilter("hasPermission(filterObject, 'READ')")
все время.
Я бы проверял, чтобы ваш пользовательский класс, который расширяет UserDetails, возвращает одно и то же имя пользователя через getUsername(), который у вас есть в db. Наряду с проверкой, чтобы убедиться, что безопасность и приложение находятся в одном контексте.
hasPermission принять Authentication объект как первый параметр.
boolean hasPermission(Authentication authentication,
Object targetDomainObject,
Object permission)
Объектом Authentication является класс реализации, обычно UsernamePasswordAuthenticationToken. Поэтому метод getPrincipal() должен возвращать объект с методом getUserName(), который возвращает то же самое, что и в вашей БД.
Взгляните на PrincipalSid
public PrincipalSid(Authentication authentication) {
Assert.notNull(authentication, "Authentication required");
Assert.notNull(authentication.getPrincipal(), "Principal required");
if (authentication.getPrincipal() instanceof UserDetails) {
this.principal = ((UserDetails) authentication.getPrincipal()).getUsername();
}
else {
this.principal = authentication.getPrincipal().toString();
}
}