как реализовать безопасность на уровне строк в весенних данных jpa с помощью фильтра гибернации или другими способами?

Али, это интересный сценарий.

Здесь вам нужно ответить на два вопроса.

Первый вопрос: при предоставлении данных система будет просто фильтровать их или вы пойдете дальше? Например, если вы предоставляете такую ​​операцию, как users/{id}, вам необходимо проверить авторизацию и убедиться, что у пользователя есть доступ к этой операции. Если вы просто выставите операцию типа /users, тогда все, что вам нужно, это фильтрация, потому что вы просто выставите пользователей, которых текущий пользователь имеет право видеть. Это различие во многом определит реализацию.

Второй вопрос: сколько ручной работы вы можете выполнять?

С одной стороны, вы можете адаптировать данные к тому, что нужно фреймворку, и стараться максимально полагаться на встроенную функциональность (выражения безопасности, ACL). Или, с другой стороны, вы могли бы адаптировать код к структуре ваших данных и больше делать что-то вручную.

Это два фактора, на которых я бы сосредоточился в первую очередь, прежде всего, потому что реализация будет выглядеть совершенно по-другому на основе этих четырех решений.

Наконец, чтобы ответить на ваш вопрос "можно ли масштабировать ACL" - два быстрых примечания. Один - нужно тестить. Да, ACL можно масштабировать, но можно ли масштабировать его до 10 000 или 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 или 100 000 000 000 000 000 000 000 000, это вопрос, на который нельзя ответить конкретно, без тестирования.

И во-вторых, когда вы проводите тестирование, продумайте реалистичные сценарии. Конечно, важно понимать пределы вашего решения. Но помимо этого, если вы думаете, что в вашей системе будет 1 миллион сущностей — отлично. Но если не будет - не ставьте это целью.

Надеюсь, это поможет.

С Spring вы можете использовать следующие вещи:

1) Вы можете использовать Расширение SpEL EvaluationContext, которое делает свойства и выражения безопасности доступными в выражениях SpEL в аннотациях @Query. Это позволяет получить только те бизнес-объекты, которые относятся к текущему пользователю:

interface SecureBusinessObjectRepository extends Repository<BusinessObject, Long> {

    @Query("select o from BusinessObject o where o.owner.emailAddress like ?#{hasRole('ROLE_ADMIN') ? '%' : principal.emailAddress}")
    List<BusinessObject> findBusinessObjectsForCurrentUser();
}

2) Вы можете ссылаться в Beans и используйте переменные пути в Web Security Expressions. Это позволяет предоставлять доступ только к тем объектам, которые разрешены текущему пользователю:

@Service
public class UserService {
    public boolean checkAccess(Authentication authentication, int id) {
        // ...
    }
}

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    // ...

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/businessObjects/{id}/**").access("@userService.checkAccess(authentication, #id)")
            // ...
    }
}

Проверьте мой демонстрационный проект для получения дополнительной информации. В этом примере Пользователи могут получить доступ к Комнатам, если они принадлежат к категориям, связанным с этими Пользователями. Администратор имеет доступ ко всем комнатам.