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

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

You can create users to access messaging clients and the {ProductName} Console through user definition files, which specify the authentication type and authorization policies.

Users are configured as `MessagingUser` resources. Users can only 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 `federated`. 

NOTE: In the default configuration, `password` authentication type users can only access messaging endpoints, whereas
`federated` authentication type users can only access the {ProductName} Console. 

=== 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=
----

=== Federated authentication type

For the `federated` type, the `provider` field must also be specified. The supported values
depend on the identity providers configured for the address space. The `federatedUsername`
and `federatedUserid` fields must be set, and must map to the `username` and `userid` in the federated
identity provider.

== 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`.

