W poprzednim artykule opisałem jak skonfigurować kontrole dostępu w brokerze MQTT, ale opisywane rozwiązanie posiada wady. Daje pełny dostęp do wszystkich tematów każdemu użytkownikowi. Wystarczy posiadać login i hasło i możemy publikować i subskrybować wszystkie tematy. Często jednak może zachodzić potrzeba, aby w temacie mógł publikować tylko określony użytkownik, ale już aby każdy mógł go subskrybować. Dla przykładu mając czujnik temperatury nie chcemy, aby inne urządzenia publikowały coś w temacie temperatura. Ale równocześnie nie przeszkadza nam, że każdy może ją odczytać.

Aby zarządzać takimi mechanizmami należy stworzyć nowy plik konfiguracyjny acl file.

Budowa pliku acl

Plik acl można podzieli na trzy podstawowe sekcje reguł:

• użytkowników anonimowych
• użytkowników
• wzorów tematów dla użytkowników i klientów

Reguły dla użytkowników anonimowych

Są te reguły subskrypcji oraz publikacji wiadomości w określonych tematach tylko dla klientów którzy nie podali żadnej nazwy użytkownika, ani hasła, czyli anonimy. Aby jakakolwiek reguła z tej sekcji działała musimy w pliku mosquitto.conf ustawić parametr  allow_anonymous na wartość true. 

W tej sekcji regułę tworzymy według szablonu:

topic [read|write|readwrite] <topic>

Gdzie:

• topic – to słowo kluczowe, które musi byś zawsze na początku
• [read|write|readwrite] – umożliwiają określenie formy dostępu
  • read – zezwalamy tylko na czytanie (subskrypcje)
  • write – zezwalamy tylko na pisanie (publikację)
  • readwrite – zezwalamy na czytanie oraz pisanie (subskrypcja oraz publikacja) – pełen dostęp
• <topic> – w te miejsce wpisujemy nazwę tematu do którego ma odnosić się reguła

Przykład:

Jeżeli chcemy, żeby każdy anonimowy użytkownik mógł czytać wszystkie tematy systemowe to nasza reguła będzie wyglądała następująco:

topic read $SYS/#

Znaki „+”, oraz „#” działają dokładnie tak samo jak podczas subskrypcji narzędziem mosquitto_sub.

Te reguły odnoszą się tylko do użytkowników anonimowych, jeżeli w ten sposób zezwolimy na publikację w jakimś temacie, to tylko i wyłącznie użytkownicy anonimowi będą mogli to robić, zalogowany użytkownik nie będzie miał tych uprawnień. Dla nich należy opisać osobną regułę.

Reguły dla użytkowników

Ta sekcja reguł odpowiada za to co mogą czytać i pisać aplikacje klienckie które podały prawidłowy login oraz hasło dostępu (nie są anonimowe).

Na początku każdej z sekcji reguł dla użytkowników określamy dla jakiego użytkownika będą te reguły obowiązywały, służy to tego bardzo prosta linia tworzona według szablonu:

user <username>

Gdzie:

• user – to słowo kluczowe
• <username> – to nazwa naszego użytkownika, dla którego tworzymy regułę/reguły

W następnych liniach po określeniu użytkownika wpisujemy regułę tak samo jak dla użytkownika anonimowego.

Przykład:

Załóżmy, że mamy w domu pewną grupę czujników temperatury, wilgotności. I dla nich będzie istniał osobny użytkownik sensorUser, a dla serwera przetwarzającego będzie użytkownik serverUser. Czujniki będą mogły tylko publikować dane, a serwer tylko subskrybować. Dodatkowo mamy użytkownika debugUser, który może wszystko i służy do testowania. Dla takiej konfiguracji nasz plik acl będzie wyglądał następująco:

user sensorUser
topic write home/sensors/temperature/#
topic write home/sensors/humidity/#

user serverUser
topic read home/sensors/temperature/#
topic read home/sensors/humidity/#

user debugUser
topic readwrite home/sensors/temperature/#
topic home/sensors/humidity/#

Dwie ostatnie linie zezwalają na publikację oraz subskrypcje. Jeżeli nie określimy formy dostępu to znaczy, że jest domyślnie jako readwrite.

Reguły dla wzorów tematów dla użytkowników i klientów

Ostatnia sekcja daje bardzo ciekawe możliwości. Pozwala tworzyć reguły dostępu na postawie wzoru tematu. W tym przypadku posługujemy się szablonem reguły:

pattern [read|write|readwrite] <topic>

Gdzie:

• pattern – to słowo kluczowe
• [read|write|readwrite] – umożliwiają określenie formy dostępu
• <topic> – to wzór tematu do którego odnosi się reguła

Wewnątrz wzoru tematu wykorzystuje się dwa słowa kluczowe:

• %c – zastępuje nazwę klienta (nazwę urządzenia)
• %u – zastępuje nazwę użytkownika

Przykład:

pattern write home/devices/status/%c

Taka reguła zezwoli na publikację wiadomości w temacie gdzie %c będzie odpowiadało nazwie klienta nadawcy. W tym przypadku jakieś meldowanie statusu urządzenia.

Uruchomienie przykładowego pliku acl

W celu uruchomienia pracy pliku acl będziemy musieli wykonać następujące czynności:

• utworzenie pliku acl
• konfiguracja pliku mosquitto.conf
• restart brokera

Utworzenie pliku acl

Plik acl to zwykły plik tekstowy do jego utworzenia wystarczy dowolny edytor teksu (np. nano). Zaczynamy od wywołania polecenia:

sudo nano /etc/mosquitto/acl

W edytorze który się otworzył wpisujemy zawartość z naszymi przykładowymi regułami:

topic read $SYS/#

user sensorUser
topic write home/sensors/temperature/#
topic write home/sensors/humidity/#

user serverUser
topic read home/sensors/temperature/#
topic read home/sensors/humidity/#

user debugUser
topic readwrite home/sensors/temperature/#
topic home/sensors/humidity/#

pattern write home/devices/status/%c

Zapisujemy plik ctrl+oi zamykamy edytor ctrl+x.

Konfiguracja pliku mosquitto.conf

W tym etapie poinformujemy nasz broker o istnieniu pliku acl, oraz gdzie się on znajduje. Zezwolimy też na dostępu użytkowników anonimowych, bo teraz ich role są określone w naszym nowym pliku acl.

Otwieramy plik mosquitto.conf:

sudo nano /etc/mosquitto/mosquitto.conf

i wpisujemy tam linię:

acl_file /etc/mosquitto/acl

a także zmieniamy linię zawierającą allow_anonymous na:

allow_anonymous true

Zapisujemy plik ctrl+oi zamykamy edytor ctrl+x.

Restart brokera

Ostatnim krokiem jest restart brokera mosquitto, tak, aby uruchomił się już z nowymi ustawieniami. W tym celu wykonujemy polecenie:

sudo systemctl restart mosquitto

Od tej chwili wszystkie subskrypcje oraz publikację wiadomości będą już określanie przez reguły z pliku acl.