Как отфильтровать полномочия аутентификации JWT на основе заголовка http - PullRequest
Новая
       10

Как отфильтровать полномочия аутентификации JWT на основе заголовка http

0 голосов
/ 21 февраля 2019

В основном я хочу реализовать фильтр после разбора токена JWT и до вызова метода с возможностью изменения объекта аутентификации на основе заголовка http

Context

В нашемВ приложении у нас есть (среди прочего) три сущности, связанные с аутентификацией / авторизацией: пользователи, разрешения и группы.Разрешения могут быть непосредственно назначены пользователю или могут быть назначены одной из групп, к которым принадлежит пользователь.

Учитывая это, токен JWT выглядит следующим образом: 

{
  "username": "duck",
  "groups": [
    {
      "name": "swimmer",
      "permissions": [
        "swim"
      ]
    },
    {
      "name": "walker",
      "permissions": [
        "walk"
      ]
    }
  ],
  "permissions": [
    "quack"
  ]
}

Поток JWTрасширение установки AuthorizationServerConfigurerAdapter и ResourceServerConfigurerAdapter, а разрешения извлекаются из карты утверждений JWT путем расширения DefaultUserAuthenticationConverter

. Используя @EnableGlobalMethodSecurity(prePostEnabled = true) в конфигурации, я могу аннотировать методы с помощью @PreAuthorize

Например: 

@PreAuthorize("hasPermission('quack')")
public void quack();

Это работает с разрешениями, непосредственно назначенными пользователю.

Однако я хочу получить заголовок http, например: 'x-group' идобавить разрешения из этой группы (если есть) к объекту аутентификации

Затем, учитывая вышеуказанное jwt с заголовком http, установленным на swimmer, я хочу иметь возможность вызывать следующий метод: 

@PreAuthorize("hasPermission('swim')")
public void

1 Ответ

0 голосов
/ 21 февраля 2019

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

Поскольку вы уже используете DefaultUserAuthenticationConverter, я хотел бы знать, сможете ли вы получить те же дополнительные полномочияиз бэкэнда, скажем, через экземпляр UserDetailsService?

Тем не менее, чтобы ответить на ваш вопрос, вы можете добавить фильтр: 

public class XGroupFilter extends OncePerRequestFilter {
    // ... look up current Authentication
    // ... look up and validate header
    // ... create new instance of Authentication, adding the new authorities
}

И затем зарегистрировать его: 

@Configuration
public class ResourceServerConfig extends ResourceServerConfigurerAdapter {
    @Override
    public void configure(HttpSecurity http) {
        // ...

        http.addFilterAfter(new XGroupFilter(), OAuth2AuthenticationProcessingFilter.class);
    }
}

Или, если у вас есть возможность обновления, то появилась новая поддержка в Spring Security 5.1 , которая немного упрощает ситуацию.Сейчас вы используете устаревший плагин-проект под названием Spring Security OAuth, но поддержка теперь встроена изначально .Кроме того, именно здесь появляются новые функции, что делает его ценным для начала, если вы не слишком далеко зашли по пути Spring Security OAuth.

В этом случае конфигурация все еще очень похожа: 

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) {
        // ...

        http.addFilterAfter(new XGroupFilter(), BearerTokenAuthenticationFilter.class);
    }
}
...