Skip to content

Commit e39bd58

Browse files
authored
SMQ-216 - Update auth documentation (#218)
* docs: update supermq architecture docs Signed-off-by: Felix Gateru <[email protected]> * docs: update authentication docs Signed-off-by: Felix Gateru <[email protected]> * docs: update architecture image, fix typos Signed-off-by: Felix Gateru <[email protected]> * feat: add auth description, update architecture image Signed-off-by: Felix Gateru <[email protected]> * refactor: update roles docs Signed-off-by: Felix Gateru <[email protected]> --------- Signed-off-by: Felix Gateru <[email protected]>
1 parent 3bceb27 commit e39bd58

File tree

9 files changed

+521
-429
lines changed

9 files changed

+521
-429
lines changed

docs/architecture.md

Lines changed: 33 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -6,37 +6,47 @@ title: Architecture
66

77
SuperMQ IoT platform is comprised of the following services:
88

9-
| Service | Description |
10-
| :------------------------------- | :-------------------------------------------------------------------------------------- |
11-
| [users][users-service] | Manages platform's users and auth concerns in regards to users and groups |
12-
| [clients][clients-service] | Manages platform's clients, channels and auth concerns in regards to clients and channels |
13-
| [http-adapter][http-adapter] | Provides an HTTP interface for sending messages via HTTP |
14-
| [mqtt-adapter][mqtt-adapter] | Provides an MQTT and MQTT over WS interface for sending and receiving messages via MQTT |
15-
| [ws-adapter][ws-adapter] | Provides a WebSocket interface for sending and receiving messages via WS |
16-
| [coap-adapter][coap-adapter] | Provides a CoAP interface for sending and receiving messages via CoAP |
17-
| [opcua-adapter][opcua-adapter] | Provides an OPC-UA interface for sending and receiving messages via OPC-UA |
18-
| [lora-adapter][lora-adapter] | Provides a LoRa Server forwarder for sending and receiving messages via LoRa |
19-
| [supermq-cli][supermq-cli] | Command line interface |
20-
21-
![arch](img/architecture.jpg)
9+
| Service | Description |
10+
| :--------------------------- | :------------------------------------------------------------------------------------------ |
11+
| [auth][auth-service] | Handles authorization and authentication for the platform as well as managing keys and tokens |
12+
| [users][users-service] | Manages platform's users and auth concerns in regards to users |
13+
| [groups][groups-service] | Manages platform's groups and auth concerns in regards to groups |
14+
| [clients][clients-service] | Manages platform's clients and auth concerns in regards to clients |
15+
| [channels][channels-service] | Manages platform's channels and auth concerns in regards to channels |
16+
| [domains][domains-service] | Manages platform's domains and auth concerns in regards to domains |
17+
| [http-adapter][http-adapter] | Provides an HTTP interface for sending messages via HTTP |
18+
| [mqtt-adapter][mqtt-adapter] | Provides an MQTT and MQTT over WS interface for sending and receiving messages via MQTT |
19+
| [ws-adapter][ws-adapter] | Provides a WebSocket interface for sending and receiving messages via WS |
20+
| [coap-adapter][coap-adapter] | Provides a CoAP interface for sending and receiving messages via CoAP |
21+
| [supermq-cli][supermq-cli] | Command line interface |
22+
23+
![arch](img/architecture.svg)
2224

2325
## Domain Model
2426

25-
The platform is built around 2 main entities: **users** and **clients**.
27+
The platform consists of the following core entities: **user**,**client**,**channel**, **group** and **domain**.
2628

27-
`User` represents the real (human) user of the system. Users are represented via their email address used as their identity, and password used as their secret, which they use as platform access credentials in order to obtain an access token. Once logged into the system, a user can manage their resources (i.e. groups, clients and channels) in CRUD fashion and define access control policies by connecting them.
29+
`User` represents the real (human) user of the system. Users are identified by their username and password, which are used as platform access credentials in order to obtain an access token. Once logged into the system, a user can manage their resources (i.e. domains,groups, clients and channels) in CRUD fashion and define access control policies by creating and managing roles for them.
2830

29-
`Group` represents a logical groupping of users. It is used to simplify access control management by allowing users to be grouped together. When assigning a user to a group, we create a policy that defines what that user can do with the resources of the group. This way, a user can be assigned to multiple groups, and each group can have multiple users assigned to it. Users in one group have access to other users in the same group as long as they have the required policy. A group can also be assigned to another group, thus creating a group hierarchy. When assigning a user to a group we create a policy that defines what that user can do with the group and other users in the group.
31+
`Group` represents a logical grouping of clients, channels or other groups. It is used to simplify access control management by allowing these entities to be grouped together. When a user becomes the member of a role of a group, they are able to access the entities encompassed by the group. A user can have a role in multiple groups, and each group can have multiple members(users). Groups can have a single parent group and many children groups, this enables shared access to entities to users and a hierarchical structure. A role created for a group determines what a member(user) of the role can do with the group and entities associated with the group.
3032

31-
`Client` represents devices (or applications) connected to SuperMQ that uses the platform for message exchange with other "clients".
33+
`Clients` represents devices (or applications) connected to SuperMQ that use the platform for message exchange with other "clients". Clients have roles to which users are members to, determining which actions the role member(user) can perform on them.
3234

33-
`Channel` represents a communication channel. It serves as a message topic that can be consumed by all of the clients connected to it. It also servers as grouping mechanism for clients. A client can be connected to multiple channels, and a channel can have multiple clients connected to it. A user can be connected to a channel as well, thus allowing them to have an access to the messages published to that channel and also clients connected to that channel with the required policy. A channel can also be assigned to another channel, thus creating a channel hierarchy. Both clients and users can be assigned to a channel. When assigning a client to a channel, we create a policy that defines what that client can do to the channel, for example reading or writing messages to it. When assigning a user to a channel, we create a policy that defines what that user can do with the channel and clients connected to it, hereby enabling the sharing of clients between users.
35+
`Channel` represents a communication channel. It serves as a message topic that can be consumed by all of the clients connected to it. It also serves as grouping mechanism for clients. A client can be connected to multiple channels, and a channel can have multiple clients connected to it. A user can also have access to a channel thus allowing them access to the messages published to that channel. As mentioned before a channel can belong to a group.A client connected to a channel forms a connection in SuperMQ. The connection can be of three types: a Publish type, where the client can only publish messages to the channel, a Subscribe type, meaning a client can only receive messages sent to the channel and Publish and Subscribe type where the client can both publish and receive messages on the channel. Channels have roles which determine the actions a role member(user) can perform on them.
36+
37+
`Domain` represents a top level organizational unit which encompases entities such as groups, channels and clients. All these entities have to belong to a domain. A user has a role on a domain which determines what actions the user can perform on the domain as well as the entities in the domain. The domain enables access to clients,channels, groups and messages to be shared with other users on the platform. They also offer the collaborative space to perfom CRUD operations on these entities.
38+
39+
Additional functionality is provided by the following services:
40+
41+
`auth` handles authentication and authorization functionality for the platform. The service is used to issue keys and tokens. The service also facilitates fine grained access control to core entities.
42+
43+
`protocol-adapters` These include adapters for HTTP, CoAP, WS and MQTT. These services handle bidirectional communication between the platform and devices and applications. The adapters enable message handling in the system, supporting the PubSub model of the platform.
3444

3545
## Messaging
3646

3747
SuperMQ uses [NATS][nats] as its default messaging backbone, due to its lightweight and performant nature. You can treat its _subjects_ as physical representation of SuperMQ channels, where subject name is constructed using channel unique identifier. SuperMQ also provides the ability to change your default message broker to [RabbitMQ][rabbitmq], [VerneMQ][vernemq] or [Kafka][kafka].
3848

39-
In general, there is no constrained put on content that is being exchanged through channels. However, in order to be post-processed and normalized, messages should be formatted using [SenML][senml].
49+
In general, there is no constraint put on content that is being exchanged through channels. However, in order to be post-processed and normalized, messages should be formatted using [SenML][senml].
4050

4151
## Edge
4252

@@ -49,14 +59,16 @@ SuperMQ platform can be run on the edge as well. Deploying SuperMQ on a gateway
4959

5060
Running SuperMQ on gateway moves computation from cloud towards the edge thus decentralizing IoT system. Since we can deploy same SuperMQ code on gateway and in the cloud there are many benefits but the biggest one is easy deployment and adoption - once engineers understand how to deploy and maintain the platform, they will be able to apply those same skills to any part of the edge-fog-cloud continuum. This is because the platform is designed to be consistent, making it easy for engineers to move between them. This consistency will save engineers time and effort, and it will also help to improve the reliability and security of the platform. Same set of tools can be used, same patches and bug fixes can be applied. The whole system is much easier to reason about, and the maintenance is much easier and less costly.
5161

62+
[auth-service]: https://github.com/absmach/supermq/tree/main/auth
5263
[users-service]: https://github.com/absmach/supermq/tree/main/users
64+
[groups-service]: https://github.com/absmach/supermq/tree/main/groups
5365
[clients-service]: https://github.com/absmach/supermq/tree/main/clients
66+
[channels-service]: https://github.com/absmach/supermq/tree/main/channels
67+
[domains-service]: https://github.com/absmach/supermq/tree/main/domains
5468
[http-adapter]: https://github.com/absmach/supermq/tree/main/http
5569
[mqtt-adapter]: https://github.com/absmach/supermq/tree/main/mqtt
5670
[coap-adapter]: https://github.com/absmach/supermq/tree/main/coap
5771
[ws-adapter]: https://github.com/absmach/supermq/tree/main/ws
58-
[opcua-adapter]: https://github.com/absmach/supermq/tree/main/opcua
59-
[lora-adapter]: https://github.com/absmach/supermq/tree/main/lora
6072
[supermq-cli]: https://github.com/absmach/supermq/tree/main/cli
6173
[nats]: https://nats.io/
6274
[rabbitmq]: https://www.rabbitmq.com/

0 commit comments

Comments
 (0)