OAuth 0 Provider

• Название: OAuth 0 Provider
• Дата: 12.01.2019
• Размер: 472.99 Kb.
• Имя файла: OAuth 2.docx
• Тип: Документы; #63371

OAuth 2.0 Provider

Механізм надання послуг OAuth 2.0 відповідає за виявлення захищених ресурсів OAuth 2.0. Конфігурація передбачає встановлення клієнтів OAuth 2.0, які можуть самостійно отримувати доступ до захищених ресурсів або від імені користувача. Провайдер це робить, керуючи та перевіряючи токени OAuth 2.0, які використовуються для доступу до захищених ресурсів. У відповідних випадках постачальник повинен також надати користувачеві інтерфейс для підтвердження того, що клієнт може отримати доступ до захищених ресурсів (наприклад, сторінки підтвердження).

OAuth 2.0 Provider Implementation

Роль постачальника в OAuth 2.0 фактично розділена між Службою авторизації та Службою ресурсів, і в той час як вони іноді перебувають у тій самій програмі, з OAuth Spring Security ви можете розділити їх на дві програми, а також мати кілька служб ресурсів, які поділяються Служба авторизації. Запити на токени обробляються кінцевими точками контролерів Spring MVC, а доступ до захищених ресурсів обробляється стандартними фільтрами запитів Spring Security. Для реалізації сервера авторизації OAuth 2.0 потрібні наступні кінцеві точки:

• 
  AuthorizationEndpoint використовується для обслуговування запитів для авторизації. URL-адреса за умовчанням: / oauth / authorize.
  
• 
  TokenEndpoint використовується для обслуговування запитів для токенів доступу. URL-адреса за замовчуванням: / oauth / token.
  
• 
  
  

Для реалізації сервера ресурсів OAuth 2.0 потрібен наступний фільтр:
OAuth2AuthenticationProcessingFilter використовується для завантаження аутентифікації для запиту з токенмом автентифікованого доступу.

Для всіх функцій провайдера OAuth 2.0 конфігурація спрощена за допомогою спеціальних адаптерів Spring OAuth @Configuration. Існує також простір імен XML для конфігурації OAuth, а схема знаходиться на http://www.springframework.org/schema/security/spring-security-oauth2.xsd. Простір імен - http://www.springframework.org/schema/security/oauth2.

Authorization Server Configuration

Під час налаштування сервера авторизації ви повинні розглянути тип гранту, який клієнт повинен використовувати для отримання токену доступу від кінцевого користувача (наприклад, код авторизації, облікові дані користувача, токен оновлення). Конфігурація сервера використовується для забезпечення реалізації служб деталізації служб і токенів, а також для включення або відключення певних аспектів механізму в глобальному масштабі. Зверніть увагу, однак, що кожен клієнт може бути налаштований спеціально з дозволами, щоб мати можливість використовувати певні механізми авторизації та отримання дотацій. І.е. лише тому, що ваш провайдер налаштований на підтримку типу надання грантів "client credentials", не означає, що конкретний клієнт має право використовувати цей тип гранту.
Анотація @EnableAuthorizationServer використовується для налаштування механізму сервера авторизації OAuth 2.0 разом з будь-якими @Beans, які реалізують AuthorizationServerConfigurer (існує зручна реалізація адаптера з порожніми методами). Наведені нижче функції делегуються окремим конфігураторам, створеним Spring, і передаються в AuthorizationServerConfigurer:

• 
  ClientDetailsServiceConfigurer: конфігуратор, який визначає службу деталей клієнта. Дані клієнта можуть бути ініціалізовані, або ви можете просто перейти до існуючого магазину.
  
• 
  AuthorizationServerSecurityConfigurer: визначає обмеження безпеки на кінцевій точці токена.
  
• 
  AuthorizationServerEndpointsConfigurer: визначає кінцеві точки авторизації та токенів та служби токенів.
  

Важливим аспектом конфігурації постачальника є спосіб передачі коду авторизації клієнту OAuth (в гранті коду авторизації). Код авторизації отримується клієнтом OAuth, направляючи кінцевого користувача на сторінку авторизації, де користувач може ввести свої облікові дані, в результаті чого перенаправлення з сервера авторизації постачальника на клієнт OAuth з кодом авторизації. Приклади цього викладені в специфікації OAuth 2.
У XML є елемент , який використовується аналогічним чином для налаштування сервера авторизації OAuth 2.0.

Configuring Client Details

ClientDetailsServiceConfigurer (зворотний виклик з вашої AuthorizationServerConfigurer) може використовуватися для визначення реалізації в оперативній пам'яті або JDBC служби деталей клієнта. Важливими атрибутами клієнта є

• 
  clientId: (потрібний) ідентифікатор клієнта.
  
• 
  secret: (необхідний для довірених клієнтів) таємниця клієнта, якщо така є.
  
• 
  scope: сфера, до якої клієнт обмежений. Якщо область необмежена або порожня (за замовчуванням), клієнт не обмежений обсягом.
  
• 
  authorizedGrantTypes: види гранту, які дозволені для використання клієнтом. Значення за замовчуванням порожнє.
  
• 
  authorities: Влада, яка надається клієнту (регулярні органи безпеки Spring).
  

Дані клієнта можуть бути оновлені в робочій програмі, доступ до основного магазину безпосередньо (наприклад, таблиці баз даних у випадку JdbcClientDetailsService) або через інтерфейс ClientDetailsManager (який також реалізує як реалізації ClientDetailsService).
ПРИМІТКА. Схема служби JDBC не упакована в бібліотеку (оскільки існує забагато варіантів, які ви, можливо, хотіли б використати на практиці), але існує приклад, з якого можна починати з коду тесту в github.

Managing Tokens

Інтерфейс AuthorizationServerTokenServices визначає операції, необхідні для управління точками OAuth 2.0. Зверніть увагу на наступне:

• 
  Коли маркер доступу створюється, автентифікація повинна бути збережена таким чином, щоб ресурси, що приймають токен доступу, могли посилатися на нього пізніше.
  
• 
  Токен доступу використовується для завантаження аутентифікації, яка використовувалася для авторизації її створення.
  

Під час створення вашої програми AuthorizationServerTokenServices ви можете розглянути можливість використання DefaultTokenServices, у якому є багато стратегій, які можна підключити, щоб змінити формат та зберігання токенів доступу. За замовчуванням він створює токени за допомогою випадкового значення та обробляє все, крім збереження токенів, які він делегує до TokenStore. Магазин за замовчуванням є вбудованою пам'яттю, але доступні інші реалізації. Ось опис з деякими обговореннями кожного з них

• 
  Стандартний InMemoryTokenStore ідеально підходить для одного сервера (наприклад, низький трафік і відсутність гарячої заміни на сервері резервного копіювання у разі виходу з ладу). Більшість проектів можна почати тут, і, можливо, працювати таким способом у режимі розробки, щоб зробити його легким для запуску сервера без будь-яких залежностей.
  

• 
  JdbcTokenStore - це версія JDBC тієї самої, яка зберігає токенів у реляційній базі даних. Використовуйте версію JDBC, якщо ви можете поділитися базою даних між серверами, або розширені екземпляри одного і того ж сервера, якщо є лише один, або Сервери авторизації та ресурсів, якщо є кілька компонентів. Для використання JdbcTokenStore вам потрібен "spring-jdbc" в path classpath.
  

• 
  Версія магазину JSON Web Token (JWT) кодує всі дані про грант в самий токен (таким чином, немає жодного зворотного накопичувача, що є суттєвою перевагою). Одним з недоліків є те, що ви не можете легко відкликати маркер доступу, тому вони, як правило, надаються з короткими термінами дії, а скасування обробляється за допомогою токену оновлення. Інший недолік полягає в тому, що токени можуть бути досить великими, якщо ви зберігаєте велику кількість вхідних даних користувача в них. JwtTokenStore насправді не є "магазином" в тому сенсі, що воно не зберігає жодних даних, однак воно відіграє ту ж саму роль у перетворенні значень токенів між собою та інформації про автентифікацію в службі DefaultTokenServices.
  

ПРИМІТКА. Схема служби JDBC не упакована в бібліотеку (оскільки існує забагато варіантів, які ви, можливо, хотіли б використати на практиці), але існує приклад, з якого можна починати з коду тесту в github. Будьте впевнені, щоб @EnableTransactionManagement, щоб запобігти зіткненню між клієнтськими додатками, конкуруючими за ті ж рядки, коли токени створюються. Зауважте також, що схема зразків має явні декларації ПЕРВИЧНА КЛЮЧА - вони також необхідні в одночасному середовищі.

JWT Tokens

Для використання токерів JWT вам потрібен JwtTokenStore на сервері авторизації. Ресурсний сервер також повинен мати можливість декодувати токени, таким чином, JwtTokenStore має залежність від JwtAccessTokenConverter, і така ж реалізація потрібна як для сервера авторизації, так і для ресурсного сервера. Токени підписуються за умовчанням, а сервер ресурсів також повинен мати змогу перевіряти підпис, тому йому потрібна та сама симетрична (підписана) ключ, як сервер авторизації (загальний таємний або симетричний ключ) або йому потрібна громадськість ключ (ключ підтвердження), який відповідає приватному ключу (ключ підписування) на сервері авторизації (загальнодоступний або асиметричний ключ). Обліковий ключ (якщо він є) відкривається Сервером авторизації на кінцевій точці / oauth / token_key, яка за замовчуванням захищена за допомогою правила доступу "denyAll ()". Ви можете відкрити його шляхом введення стандартного виразу SpEL в AuthorizationServerSecurityConfigurer (наприклад, "permitAll ()", ймовірно, є адекватним, оскільки він є відкритим ключем).
Для використання JwtTokenStore вам потрібен "spring-security-jwt" у вашому path classp (ви можете знайти його в тому самому сховищі github як Spring OAuth, але з різним циклом випуску).

Grant Types

Типи грантів, що підтримуються AuthorizationEndpoint, можна налаштувати за допомогою авторизаці їServerEndpointsConfigurer. За умовчанням підтримуються всі типи грантів, окрім пароля (див. Нижче, щоб дізнатись, як його ввімкнути). Наступні властивості впливають на типи грантів:

• 
  authenticationManager: гранти пароля вмикаються шляхом введення AuthenticationManager.
  
• 
  userDetailsService: якщо ви вводите UserDetailsService або якщо він все-таки налаштовується глобально (наприклад, у GlobalAuthenticationManagerConfigurer), грань токену оновлення міститиме перевірку відомостей про користувача, щоб переконатися, що обліковий запис все ще активний
  
• 
  authorizationCodeServices: визначає служби кодування авторизації (екземпляр AuthorizationCodeServices) для надання авторизації коду.
  
• 
  implicitGrantService: керує державою під час отримання грантів imlpicit.
  
• 
  tokenGranter: TokenGranter (повністю контролює надання та ігнорування інших властивостей вище)
  

У типів XML-дотику включені як дочірні елементи авторизації-сервера.