Создание и проверка политики контроля доступа в oneM2M

Question

Мы начали внедрять часть безопасности OneM2M и сначала приступили к реализации политики контроля доступа (ACP).Пока мы исследуем пример политики управления доступом oneM2M, мы видим, что привилегиями (PV) и собственными привилегиями (PVS) может быть любой источник, который может быть любым объектом приложения (AE) или объектом общего обслуживания (CSE).

В привилегии каждое правило контроля доступа определяет, какой AE / CSE разрешен для какой операции.Таким образом, для наборов правил контроля доступа операция разрешается, если она разрешена одним или несколькими правилами контроля доступа в наборе.

TS-0001 v3.12.0 |Ln 3432-3433

После этого мы также рассмотрели версию Eclipse реализации OneM2M и запустили приложение для каждого CSE (IN-CSE и MN-CSE).Веб-интерфейс приветствует вас с помощью экрана входа в систему и ожидает ввода имени пользователя и пароля.Затем появляется странная часть.После успешного входа в систему введенные имя пользователя и пароль, по-видимому, используются в качестве источника ресурсов, к которым мы хотим получить доступ.В дополнение к этому, тестовый пользователь также был добавлен в ACP по умолчанию.

Пример ACP взят из ветки форума eclipse.

<m2m:acp xmlns:m2m="http://www.onem2m.org/xml/protocols">
    <pv>
        <acr>
            <acor>admin:admin</acor>
            <acop>63</acop>
        </acr>
        <acr>
            <acor>test</acor>
            <acop>34</acop>
        </acr>
    </pv>
    <pvs>
        <acr>
            <acor>admin:admin</acor>
            <acop>63</acop>
        </acr>
    </pvs>
</m2m:acp>

Вопрос в том, подходит ли логика имени пользователя и пароля дляСам АШП?Что бы это ни было, я понимаю необходимость такого рода использования.Но я не уверен, что это правильный способ сделать это в OneM2M.

Предположим, что у нас есть AE, который имеет веб-интерфейс и используется многими пользователями.Таким образом, каждый пользователь имеет разные привилегии для доступа к другим ресурсам в OneM2M, но политики управления доступом имеют только отправителей, которые могут быть любыми AE / CSE, а не пользователями.Как реализовать такой сценарий?

С этим вопросом связан веб-сайт OneM2M

Cgateway_ae (похоже, MN-AE) отправляет запрос на создание ACP в MN-CSE.Но откуда приходит разрешение для MN-AE на создание ACP для MN-CSE.Каким-то образом он должен быть создан, прежде чем он хочет создать еще один ACP?

Кто несет ответственность за создание этого ACP?Как ответственная сторона узнает соответствующий AE-ID / CSE-ID еще до его создания.

POST /home_gateway?rcn=0 HTTP/1.1
Host: mn.provider.com:8080
X-M2M-Origin: Cgateway_ae
Content-Type: application/vnd.onem2m-res+xml; ty=1
X-M2M-RI: mncse-62948

<m2m:acp xmlns:m2m="http://www.onem2m.org/xml/protocols" rn="MN-CSEAcp">
  <pv>
    <acr>
      <acor>Cgateway_ae Clight_ae1 Clight_ae2 /in-cse/Csmartphone_ae</acor>
      <acop>63</acop>
    </acr>
  </pv>
  <pvs>
    <acr>
      <acor>Cgateway_ae</acor>
      <acop>51</acop>
    </acr>
  </pvs>
</m2m:acp>

------------------ ИЗД. ---------------------------

Это действительно хороший документ.

http://www.onem2m.org/tr-0038/procedures/authorization/configuration-of-accesscontrolpolicy

Answer 1

Реализация Eclipse om2m имеет собственный встроенный веб-интерфейс, который имеет специальную обработку инициатора управления доступом ( acor ). Если acor содержит символ «:», то инициатор разделяется на комбинацию имени пользователя и пароля для пользовательского интерфейса. Насколько я знаю, это все еще касается политик доступа, определенных для этого пользователя в ресурсах . И, как показано в примере, один ресурс может поддерживать более одного источника. При разрешении этого формата реализация Eclipse om2m может не полностью соответствовать.
См. Главу TS-0001 «10.2.2.2 Создать ». Это объясняет, как создается этот идентификатор (CSE). После прочтения этого становится намного понятнее, когда в примерах oneM2M AE-ID начинаются с «C» или «S». Также проверьте в TS-0001 главу "7.2 M2M-SP-ID, CSE-ID, App-ID и AE-ID и форматы идентификатора ресурса" для получения дополнительной информации о формате идентификатора.

CSE всегда должен иметь своего рода «корневого» отправителя вместе с привилегированным , который позволяет управляющим AE выполнять функции управления. Без это может быть CSE-ID. Для Eclipse om2m это будет создатель «admin: admin». С помощью этого инициатора управляющая АЕ может добавлять и отправителей с меньшими привилегиями для других АЕ. Обратите внимание, что такого рода управление пользователями / удостоверениями / доступом обычно является частью бизнес-логики, а не частью oneM2M.

Это достаточно безопасно? Как всегда, это зависит. Многие системы IoT назначают «секретный» токен устройству для аутентификации запроса соединения. Но имейте в виду, что идентификатор отправителя всегда исходит от AE, который должен был в первую очередь успешно зарегистрироваться в CSE и поэтому ему доверяют.

Во второй части вопроса: в примере с веб-сайта oneM2M должен быть , который позволяет создателю "Cgateway_ae" СОЗДАТЬ новый ресурс в пути к ресурсу "/ home_gateway" ( MN-CSE в примере). Это , по-видимому, отсутствует в этом примере, но шлюз AE, который регистрирует новый ресурс для предоставления другим AE прав доступа, должен иметь привилегии для этого. Это может быть сделано либо с помощью предварительно предоставленной информации об аутентификации отправителя (такой как смарт-карта или аналогичные механизмы), либо другим способом распространения информации об отправителе (например, обмен файлом, когда AE фактически работает вместе с CSE в безопасная и надежная среда).

( Обновлено в соответствии с обсуждением )