FIWARE: аутентификация между агентом IoT и брокером контекста - PullRequest
2 голосов
/ 30 апреля 2019

Я работал с Fiware и пытался понять, как обращаться с безопасностью.На этой диаграмме показан пример использования прокси-серверов для аутентификации запросов.

enter image description here

Но я не вижу никакой аутентификации между агентом IoT и посредником контекста.Я бы предположил, что агент IoT предназначен для шлюза, работающего на оборудовании, физически расположенном рядом с устройствами.Но если дело обстоит так с этой настройкой, то при выполнении вызовов в посредник контекста аутентификация не выполняется.

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

1 Ответ

2 голосов
/ 02 мая 2019

Он основан на сценарии, в котором настроены эти компоненты.Обычно данные отправляются в Context Broker с устройств через pep-proxy и iotagent.
Мы реализовали сценарий, в котором устройства отправляют контекстную информацию в Context Broker, в этом случае аутентификация токена доступа и устройств будет выполнятьсяWilma / Keyrock перед обработкой информации в iotagent, а затем в Orion (Context Broker).В приведенном выше случае связь между iotagent и Orion (Context Broker) является скрытой (частной), никто не обращается к Orion или iotagent напрямую из общедоступного домена, и весь сценарий имеет только открытую конечную точку Wilma (pep-proxy).Таким образом, каждый раз, когда устройство отправляет данные, оно может только отправлять его в Wilma, а после аутентификации с помощью Keyrock оно затем обрабатывается в iotagent и, в конечном итоге, в Orion.

Обычно iotagent не работает рядом с конечными устройствами.они работают на облачных узлах вместе с другими компонентами FIWARE, устройства расположены удаленно.

Для получения более подробной информации см. https://documenter.getpostman.com/view/513743/RWaHxUgP

...