Серия 05 - Новый подход к CIBA

У времени есть ответы; Отвечает всем и каждому. Он отвечает на ваши боли. Он отвечает на ваши неудачи. Он отвечает на ваши падения. Он отвечает на твои слезы, о которых знает только твоя подушка. У времени есть ответ для сломленного ВАС. У времени есть ответ для людей, которые сломали вас. Время отвечает твоей воле и остроумию. Время отвечает на ваш аппетит к победе. Время отвечает вашей эволюции. Время помогает в эволюции.

Время развивается - Время позволяет всему развиваться.

У нас было несколько проблем, которые закончились архитектурой POC CIBA [Эпизод 03]. Нашей основной проблемой была нагрузка на IS [Identity Server] из-за опроса и минимизированный патч для существующей архитектуры WSO2-IS. С этим конкретным подходом прокси мы реализовали POC и также провели демонстрацию [ Эпизод 04 ].



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

Хотя болезненно отказываться от архитектурного подхода V1.0, описанного в Эпизоде ​​03, эволюция архитектуры делает работу более интересной, и у нас был сдвиг: в сторону архитектурного подхода V2.0.

Почему такой подход ??

Он должен придерживаться стандартного шаблона развертывания WSO2 -IS.

Подход

В то время как функции и возможности остаются такими же, как в V1.0, подход 2.0 использует прокси-сервер Ciba как компонент внутри IS. Следовательно, нам необходимо разделить прокси на несколько частей и добавить их к существующей базовой архитектуре WSO2-IS.

Таким образом, мы разделили прокси на два основных компонента.

  1. Конечная точка CIBA [верхний левый угол сервера идентификации]
  2. Компонент CIBA [Фиолетовая рамка]

Поток

Поскольку архитектура претерпела изменения, поток функции также претерпел некоторые изменения. Хотя высокоуровневая концепция развязанной аутентификации и механизма опроса для токенов остается неизменной, мы вынуждены адаптировать изменения, которые принесла архитектура. Но все же поток будет следовать за проповедью спецификаций.

Разделение ПОТОКА

Хорошо бы рассмотреть поток, указанный на рисунке 2. на три фазы.

  1. Этап - 1 [2–6]
  2. Этап - 2 [7-13]
  3. Этап - 3 [№1 - №4]

Этап - 1 [запросы и ответы аутентификации]

  1. EndPoint получает CIBA AuthenticationRequest [шаг 2 на рисунке 2.]
- Consumes("application/x-www-form-urlencoded")
- Produces("application/json")
{
"name": "https://localhost:9443/oauth2/ciba",
   "request": {
    "method": "POST",
    "header": [
     {"key": "Content-Type",
      "name": "Content-Type",      
      "value": "application/x-www-form-urlencoded"
     }
    ],
    "body": {
     "mode": "urlencoded",
     "urlencoded": [
      {
       "key": "request",
       "value": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJaenhtRHFxSzhZWWZqdGxPaDl2dzg1cW5OVm9hIiwiYXVkIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6OTQ0My9vYXV0aDIvY2liYSIsInNjb3BlIjoib3BlbmlkIiwiYmluZGluZ19tZXNzYWdlIjoiMTkwODE5OTUiLCJsb2dpbl9oaW50Ijoidml2ZWsiLCJpYXQiOjE1NzE2MzExODUsImV4cCI6MTU3MTY0MDM3OSwibmJmIjoxNTcxNjMxMTg1LCJqdGkiOiI5ZmY4NDViOS0yMGJmLTQwMzMtOWVkMy0zY2NjNjNmNTIwNGMiLCJ0cmFuc2FjdGlvbl9jb250ZXh0IjoiUnN4eHgueHgifQ.50Lv_27ptjCgDvsEQ-bFhnAjJ6k77B4jcttLvnTnonc"
      }  
     ]
}

2. Процесс валидации [шаг 3 на рисунке 2.]

  • isValidClien t - проверяет, существует ли [зарегистрированный] клиент, инициирующий запрос, на сервере идентификации.
  • isValidUser - проверяет, существует ли [зарегистрированный] пользователь, обозначенный подсказками, на сервере идентификации.
  • isValidUserCode - это проверка кода пользователя на соответствие пользователю, для которого сделан запрос аутентификации [WSO2 IS не планировал предоставлять поддержку для этого в первом выпуске. Но задано как расширяемая точка, где разработчик может реализовать логику соответствующим образом]
  • isValidRequest - проверяет наличие обязательных параметров, а также правильность и действительность указанных значений.

3. Сохраните требуемые параметры [Шаг 3 на Рис.2.]

Здесь будут храниться параметры, необходимые для работы потока.

4. Создайте auth_req_id

  • auth_req_id будет подписанным JWT
auth_req_id => 
eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJaenhtRHFxSzhZWWZqdGxPaDl2dzg1cW5OVm9hIiwibmJmIjoxNTcxNjM2MDY1MjMyLCJ0cmFuc2FjdGlvbl9jb250ZXh0IjoiUnN4eHgueHgiLCJzY29wZSI6Im9wZW5pZCIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC9jaWJhIiwiYmluZGluZ19tZXNzYWdlIjoiMTkwODE5OTUiLCJleHAiOjE1NzE2Mzk2NjMyMzIsInVzZXJfaGludCI6InZpdmVrIiwiaWF0IjoxNTcxNjM2MDYzMjMyLCJqdGkiOiIwM2U3ODBiMy00NGZhLTQyMjYtOWE0OS04OGZiZjJkNjMxNTQifQ.VqDM8Y_sxSbUu0NiRupR0OznNKm4jgNCel5WidDeB-GPvFQoX_jgu9Oh6tvbvvQfMwIzDa3-nUTKW67cftzoYFwo3e8Knz-NAfGZMOU-CUAyVq1EsLDXXaJ6ykkq_vt3Q9iIg6FJ8PRFEcWPOG3VO-ASGT3bmKHWieCDtUFZec2b0gFvQq7lmOcJEcv98F0Un8xaFtQgTn_fdTK_KXXavHIWrPLiapu2-rjEvD3I8KUJKcHbtMBtruY56P5DwjssEHPamKu_bPO7Cw6vlLqz1IVHBmoONmAi8DZrCZ8-4H8F8ZVZ5B19xuZ6uxk0G3bLZBJxiB2q-AhtI_1XNPBGqQ

5. Вернуть ответ аутентификации [шаг 5 на рисунке 2.]

HTTP/1.1 200 OK
Content-Type: application/json
{
"expiresIn":3600,
"interval":2,
"auth_req_id":"eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJaenhtRHFxSzhZWWZqdGxPaDl2dzg1cW5OVm9hIiwibmJmIjoxNTcxNjM2MDY1MjMyLCJ0cmFuc2FjdGlvbl9jb250ZXh0IjoiUnN4eHgueHgiLCJzY29wZSI6Im9wZW5pZCIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC9jaWJhIiwiYmluZGluZ19tZXNzYWdlIjoiMTkwODE5OTUiLCJleHAiOjE1NzE2Mzk2NjMyMzIsInVzZXJfaGludCI6InZpdmVrIiwiaWF0IjoxNTcxNjM2MDYzMjMyLCJqdGkiOiIwM2U3ODBiMy00NGZhLTQyMjYtOWE0OS04OGZiZjJkNjMxNTQifQ.VqDM8Y_sxSbUu0NiRupR0OznNKm4jgNCel5WidDeB-GPvFQoX_jgu9Oh6tvbvvQfMwIzDa3-nUTKW67cftzoYFwo3e8Knz-NAfGZMOU-CUAyVq1EsLDXXaJ6ykkq_vt3Q9iIg6FJ8PRFEcWPOG3VO-ASGT3bmKHWieCDtUFZec2b0gFvQq7lmOcJEcv98F0Un8xaFtQgTn_fdTK_KXXavHIWrPLiapu2-rjEvD3I8KUJKcHbtMBtruY56P5DwjssEHPamKu_bPO7Cw6vlLqz1IVHBmoONmAi8DZrCZ8-4H8F8ZVZ5B19xuZ6uxk0G3bLZBJxiB2q-AhtI_1XNPBGqQ"
}
  • Ответ об ошибке [если параметры отсутствуют]:
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error" : "invalid_request"
"error_description" : "parameters_missing"
}
  • Ответ об ошибке [если неавторизованный клиент]
HTTP/1.1 401 UnAuthorized
Content-Type: application/json
{
"error" : "unauthorized"
"error_description" : "unknown_client"
}

6. Запрос разрешения на пожарную охрану [Шаг 6 на Рисунке 2.]

  • Это будет асинхронный HTTP-вызов авторизованной конечной точки WSO2 -IS с необходимыми параметрами.
https://localhost:9443/oauth2/authorize?response_type=ciba&redirect_uri=http://localhost/CibaResponse&client_id=ZzxmDqqK8YYfjtlOh9vw85qnNVoa&user=vivek

Примечание :

* Мы подробно обсудим запросы, ответы, проверки и параметры, задействованные в более позднем эпизоде.

* А также мы скоро обсудим компоненты, пакеты, классы и методы, задействованные в потоке.

Этап - 2 [Аутентификация и авторизация]

  • Эта фаза почти контролируется структурой аутентификации, локальными / исходящими аутентификаторами WSO2 -IS.
  1. Компонент Inbound-OAuth-Auth получает запрос на авторизацию.
  2. Inbound-OAuth-Auth запускает платформу аутентификации для продолжения процесса авторизации [шаг 7 на рисунке 2].
  3. Аутентификаторы и структура аутентификации заботятся о многоступенчатой ​​аутентификации [шаги 8–11 на рисунке 2].
  4. После надлежащей аутентификации и авторизации путем предоставления согласия управление снова передается компоненту Ciba [шаг 12 на рисунке 2].
  5. Компонент Ciba обновляет ответы аутентификации / авторизации в хранилище [шаг 13 на рис.2.].

Этап - 3 [запрос токена, ответ токена и опрос]

На этой последней фазе потока клиенты будут опрашивать токен в конечной точке токена WSO2-IS.

  1. Запрос токена должен быть направлен к конечной точке токена WSO2-IS [шаг №1 на рисунке 2.]
https://localhost:9443/oauth2/token 
  • Образец TokenRequest
{
   "name": "https://localhost:9443/oauth2/token",
   "request": {
    "auth": {
     "type": "basic",
     "basic": [
      {
       "key": "username",
       "value": "ZzxmDqqK8YYfjtlOh9vw85qnNVoa",
       "type": "string"
      },
      {
       "key": "password",
       "value": "ZkaeWpAW3RztIm4hKAgmf251LdAa",
       "type": "string"
      }
     ]
    },
    "method": "POST",
    "header": [
     {
      "key": "Content-Type",
      "value": "application/x-www-form-urlencoded"
     }
    ],
    "body": {
     "mode": "urlencoded",
     "urlencoded": [
      {
       "key": "grant_type",
       "value": "urn:openid:params:grant-type:ciba",
       "type": "text"
      },
      {
       "key": "auth_req_id",
       "value": "eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJaenhtRHFxSzhZWWZqdGxPaDl2dzg1cW5OVm9hIiwibmJmIjoxNTcxNjM2MDY1MjMyLCJ0cmFuc2FjdGlvbl9jb250ZXh0IjoiUnN4eHgueHgiLCJzY29wZSI6Im9wZW5pZCIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC9jaWJhIiwiYmluZGluZ19tZXNzYWdlIjoiMTkwODE5OTUiLCJleHAiOjE1NzE2Mzk2NjMyMzIsInVzZXJfaGludCI6InZpdmVrIiwiaWF0IjoxNTcxNjM2MDYzMjMyLCJqdGkiOiIwM2U3ODBiMy00NGZhLTQyMjYtOWE0OS04OGZiZjJkNjMxNTQifQ.VqDM8Y_sxSbUu0NiRupR0OznNKm4jgNCel5WidDeB-GPvFQoX_jgu9Oh6tvbvvQfMwIzDa3-nUTKW67cftzoYFwo3e8Knz-NAfGZMOU-CUAyVq1EsLDXXaJ6ykkq_vt3Q9iIg6FJ8PRFEcWPOG3VO-ASGT3bmKHWieCDtUFZec2b0gFvQq7lmOcJEcv98F0Un8xaFtQgTn_fdTK_KXXavHIWrPLiapu2-rjEvD3I8KUJKcHbtMBtruY56P5DwjssEHPamKu_bPO7Cw6vlLqz1IVHBmoONmAi8DZrCZ8-4H8F8ZVZ5B19xuZ6uxk0G3bLZBJxiB2q-AhtI_1XNPBGqQ",
       "type": "text"
      },
      {
       "key": "redirect_uri",
       "value": "http://localhost/CibaResponse",
       "type": "text"
      }
     ]
    },
    "url": {
     "raw": "https://localhost:9443/oauth2/token",
     "protocol": "https",
     "host": [
      "localhost"
     ],
     "port": "9443",
     "path": [
      "oauth2",
      "token"
     ]
    }
   }

2. Затем Identity Server проверяет запрос [шаг № 2 на рис. 2].

  • isValidGrant - проверяет, зарегистрирован и авторизован ли GranType, упомянутый в запросе, для клиента, сделавшего запрос.
  • isValidClien t - проверяет, существует ли [зарегистрированный] клиент, инициирующий запрос, на сервере идентификации.
  • isPollingAllowed - проверяет, авторизован ли клиент, опрашивающий в конечной точке токена, на опрос. В первом выпуске не планировалось поддерживать «Ping Flow», но он был предоставлен разработчикам в качестве расширяемой точки для расширения поддержки.
  • ActiveAuthReqID - это необходимо для подтверждения того, что auth_req_id, с которым сделан запрос, активен и предоставляется самой IS.
  • CorrectPollingFrequency - Это необходимо для подтверждения правильной частоты опроса запроса токена.

3. Сервер идентификации проверяет статус аутентификации [шаг № 3 на рисунке 2.]

  • isUserAuthenticated - проверяет, прошел ли пользователь, указанный в auth_req_id, аутентификацию и авторизацию.

4. Предоставьте токены [шаг 4 на рис. 2].

  • Если шаги №2, №3 положительны, верните правильный ответ токена.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token":"01e51139-a7e6-302a-97b9-325c0e2b53bd",
"refresh_token":"26b17e0b-8d4e-332b-840c-cf3f63eb5c1d",
"scope":"openid",
"token_type":"Bearer",
"expires_in":3600",
"id_token":"eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiSjFScUhvSFRLN2ctS3dLOXFZVGY0dyIsImF1ZCI6Ilp6eG1EcXFLOFlZZmp0bE9oOXZ3ODVxbk5Wb2EiLCJzdWIiOiJ2aXZlayIsIm5iZiI6MTU3MTczODAwMCwiYXpwIjoiWnp4bURxcUs4WVlmanRsT2g5dnc4NXFuTlZvYSIsImFtciI6WyJ1cm46b3BlbmlkOnBhcmFtczpncmFudC10eXBlOmNpYmEiXSwiaXNzIjoiaHR0cHM6XC9cL2xvY2FsaG9zdDo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiZXhwIjoxNTcxNzQxNjAwLCJpYXQiOjE1NzE3MzgwMDB9.JCjTzmZRNk5yllEX7R7NLDwybzjvP0H7xPVTInapiw44BJPM-VodXDDYE5lK1gu01-0XmfOwlUMjK1ir5I3R85lvXNsbPjCzspJVr8s5Z9UcrB9jF9gEfwkkz5V3uxh6GMrUqfxDhfftLkWkmEn3hbFVcNCQZo8gupnFQAFNpwipcEZVSXukeCgupCRmLqbGLZH6NyX8K5fui7qLzodcHXqbJYwRYk5WZ_aFWk8tXGYA8EGOEA9tDf31THqE1w8b6ZtsuEns1XyMbZcbzvBp-sEmEeAQV1FleGIC8EFv99WMqWd2xkPmYw-OoQl9xPeX13oXqI5uEnx-TiNK1M5HJg"
}
  • Вернуть ответ об ошибке, если проверка завершилась неудачно [описания ошибок различаются в зависимости от проверок, которые токен не прошел].
HTTP/1.1 400 BadRequest
Content-Type: application/json
{
    "error_description": "authoization_pending",
    "error": "invalid_grant"
}
  • Например: ErrorResponse при неправильной частоте опроса.
HTTP/1.1 400 BadRequest
Content-Type: application/json
{
    "error_description": "slow_down",
    "error": "invalid_grant"
}

В этом выпуске серии CIBA мы увидели наш новый подход к реализации поддержки CIBA для WSO2 IS. Мы реализовали логику для полноценного функционирования CIBA. В репозиториях ниже можно найти реализацию компонентов

  1. org.wso2.carbon.identity.oauth2.endpoint.ciba
  2. org.wso2.carbon.identity.oauth.ciba

Нам нравится разбивать архитектуру Ciba на части, чтобы каждый мог понять наше мнение о внедрении Ciba. Вы слышали о режиме 4 + 1 ? Следующим выпуском будет очередь картинок. Продолжаю ждать !.

Удачного обучения.