// Module included in the following assemblies:
//
// assembly-tenant-guide.adoc
// master.adoc

[id='con-user-model-{context}']
= User model

A messaging client connects using a MessagingUser. A MessagingUser specifies an authorization policy that controls which addresses may be used and the operations that may be performed on those addresses.

Users are configured as `MessagingUser` resources. Users can be created, deleted, read, updated, and listed.

The following example shows the `user-example1.yaml` file:

[source,yaml,options="nowrap"]
----
include::../common/user-example1.yaml[]
----

The following fields are required:

* `metadata.name`
* `metadata.namespace`
* `spec.authentication`
* `spec.authorization`

The `spec.authentication` object defines how the user is authenticated, whereas
`spec.authorization` defines the authorization policies for that user.

== Authentication

The supported values for the authentication type are `password` and `serviceaccount`. When using the `password` authentication type, you specify the username and password to be used by your messaging client when connecting. With the `serviceaccount` authentication type, you use the special string `@@serviceaccount@@` as the username, and a {KubePlatform} service account token as the password.

=== Password authentication type

For the `password` type, an additional field `password` must be set to a base64-encoded value of the
password for that user. The password will not be printed out when reading the resource.

A password can be base64-encoded on the command line. To encode `my-password`, for example:

[source, shell]
----
$ echo -n my-password | base64
bXktcGFzc3dvcmQ=
----

=== Serviceaccount authentication type

For the `serviceaccount` type, the `username` field must contain the {KubePlatform} serviceaccount name that will be used to authenticate. When connecting with the messaging client, use the string `@@serviceaccount@@` as the username, and the service account token as the password.

== Authorization

In addition, authorization policies can be defined using operations and addresses. Valid operations
are `send`, `recv`, `view`, and `manage`.

The `manage` and `view` operations apply to all addresses in the address space.

In the `standard` address space, the asterisk wildcard can be used at the end of an address. The address [x-]`top*`
matches addresses `topic` and `topic/sub`.

In the `brokered` address space, the plus sign and asterisk wildcards can be used at the end of an address to match a single word (plus sign) or all words (asterisk) after the forward slash delimiter. So, the address `topic/+` matches
`topic/sub` but not `topic/s/sub`.  The address [x-]`topic/*` matches `topic/sub` and `topic/s/sub`.

