Какие'минимальная настройка OAuth2 для Spring-Security, если я хочу защитить REST-сервер для одного клиента? Я неЯ не хочу использовать ненужные настройки или реализовывать ненужные компоненты. Может бытьс "легко" учебник / пример уже есть для Spring-Security + OAuth2? (Хотя я'я стараюсь не слишком надеяться на это)

Моя текущая рабочая установка (работа с копией + past + wtf из контекста sparklr) выглядит слишком сильно:

Я уже реализовал аутентификационный менеджер (UserDetailsService) как часть реализации базовой безопасности Spring, чтобы учетные записи и роли сохранялись в нашей базе данных.

Бобы я неЭто действительно:

userApprovalHandler: Зачем мне нужно одобрение пользователя в потоке / гранте client_credentials? Похоже, sparklr переопределяет дефолтTokenServicesUserApprovalHandler автоматически одобрить одного клиента. Нужно ли это делать также для связи между моим доверенным клиентом (ами) и сервером?

oauthAuthenticationEntryPoint: все, что делает sparklr по этому поводу:

Какие'это должно делать?

clientCredentialsTokenEndpointFilter В нем говорится, что я должен включить это, только если я хочу аутентифицироваться с помощью параметров запроса. Итак, я имею в виду именно это: отправьте GET (?) Запрос на мой сервер с секретом и получите токен и с этим токеном получите доступ ресурсы? Так что я'Думаю, запрос на токен должен содержать секрет в качестве параметра запроса ..?

resourceServerFilter Мне кажется, что это указывает на отдельный ресурсный сервер? Как это применимо, если мои ресурсы находятся на том же сервере, что и поставщик аутентификации?

AccessDecisionManager Я неНе забудьте использовать это при настройке моей собственной реализации Spring-Security, почему я хотел бы сделать это сейчас?

Спасибо за прочтение! Надеюсь, кто-то может ответить на несколько моих вопросов ..

UpdateI»

мы обновили настройку до текущего рабочего состояния. Теперь я могу запросить токен доступа с учетными данными клиента:

$ curl -X -v -d 'client_id=the_client&client_secret=secret&grant_type=client_credentials' -X POST "http://localhost:9090/our-server/oauth/token"

и использовать этот токен для доступа к защищенным ресурсам:

$ curl -H "Authorization: Bearer fdashuds-5432fsd5-sdt5s5d-sd5" "http://localhost:9090/our-server/rest/social/content/posts"

Это все еще похоже на настройку, и мои вопросы остаются. Также я'Мне интересно, если это правильный путь для обеспечения безопасности связи между доверенным клиентом и сервером REST в целом.

Также все еще ощущается, что первоначальный запрос токена небезопасен, за исключением случаев, когда он выполняется через https, но будет ли этого достаточно?

А как насчет самого токена, должен ли я дать ему долгую жизнь и сохранить его на клиенте? в любом случае это будет означать перехват исключения токена, а затем запрос нового. Или я должен делать рукопожатие для каждого запроса? Как насчет обновления токена? Я думаю, что где-то читал, что токен обновления не безопасен для типа предоставления учетных данных клиента ..? Нужно ли отправлять токен как заголовок HTTP или я могу это изменить? Я немы не хотим использовать клиентский стек Spring-security для нашего клиента, так как он имеет довольно устаревшую настройку (jboss 5), и все, что мы до сих пор делали, - это интегрировали возможности связи REST с параметрами запроса.

Это также поможет узнать больше обо всех настройках Spring-Security, но документация довольно скудная.

РЕДАКТИРОВАТЬ

Обновлена конфигурация безопасности весны до нашего текущего состояния. Также здесь's наш web.xml:

    the-display-name

    
        contextConfigLocation
        /WEB-INF/spring-context.xml
    

    
        org.springframework.web.context.ContextLoaderListener
    

    
        org.springframework.web.context.request.RequestContextListener
    

    
        jersey-serlvet     
        
            com.sun.jersey.spi.spring.container.servlet.SpringServlet
                
        
            com.sun.jersey.config.property.packages
            base.package.rest
                       
        1
    

    
        jersey-serlvet
        /rest/*
    

    
        appServlet
        org.springframework.web.servlet.DispatcherServlet
        
            contextConfigLocation
            
            /WEB-INF/servlet-context.xml            
            
        
        2
    
    
        appServlet
        /*
    

    
        springSecurityFilterChain
        org.springframework.web.filter.DelegatingFilterProxy
        
            contextAttribute
            org.springframework.web.servlet.FrameworkServlet.CONTEXT.appServlet
        
    

    
        springSecurityFilterChain
        /*
    

Примечание. Spring-security-context.xml сверху будет инициализирован сервлет-контекстом. Сам Spring-context.xml только инициализирует bean-компоненты. (Кроме того: наш сервер также имеет несколько представлений, поэтому все остальные ресурсы запускаются в / rest, следовательно, с помощью url-шаблона. Но: всегда необходимо иметь отдельный сервлет и контекст Spring.)