Can the SEMP – REST API work with a READ-ONLY user? If so, how do you create one?

emyrpetersen

We want to delegate monitoring capability to another team, but we don’t want to give them the ability to change the configuration.

Thanks in advance!

brenda

The Solace broker has three kinds of users - one kind for working in the SolOS shell (that is the Linux shell, not the CLI), one kind for connecting to the management bus (aka usernames) and one kind for connecting to the message bus (aka client-usernames).

There are two types of management users: CLI users and File Transfer users.
​
The kind of user that makes SEMP requests is the management "username", CLI subtype. This kind of user is created with the "create username" CLI command.

The data bus users are created with the "create client-username" command. (This is only mentioned here to alert you to the similar name and command - username vs client-username - to avoid confusion. The rest of this post will not talk about client-usernames or Linux shell users.)

Usernames have individual authorization/authentication settings.

You can make a new username on the management bus just for handling the SEMP queries, and you can give that username separate permissions on the system data and the per-message-vpn data.

Access to the system data is divided into categories. The levels of access to the system data are:

• admin (full permission)
• read-write
• read-only
• none

Access to the message-vpn data is also divided into categories. The levels of access are:

• read-write
• read-only
• none

Also, the username can have individual per-message-vpn permissions on each of the message-vpns, and some default permissions for any message-vpns that are not among the exceptions.

A username with read-only permission on the system data and with default read-only permission on the message-vpns can give any commands that can be done with read-only permission. If that username gives commands that require read-write or admin permission, those commands fail with a response like:

`<permission-error>Command prohibited due to Authorization Access Level</permission-error>`

Some documentation links on usernames:

Management User Authentication / Authorization
Show Username Info
enable configure username
enable configure username message-vpn

Finally, one last point - there are two versions of SEMP - "legacy" SEMP and SEMP/v2. SEMP/v2 is not fully implemented, and specifically the implementation to date has concentrated on the per-message-vpn data - so, currently, if you want to get any system data you must use legacy SEMP.

brenda

The Solace broker has three kinds of users - one kind for working in the SolOS shell (that is the Linux shell, not the CLI), one kind for connecting to the management bus (aka usernames) and one kind for connecting to the message bus (aka client-usernames).

There are two types of management users: CLI users and File Transfer users.
​
The kind of user that makes SEMP requests is the management "username", CLI subtype. This kind of user is created with the "create username" CLI command.

The data bus users are created with the "create client-username" command. (This is only mentioned here to alert you to the similar name and command - username vs client-username - to avoid confusion. The rest of this post will not talk about client-usernames or Linux shell users.)

Usernames have individual authorization/authentication settings.

You can make a new username on the management bus just for handling the SEMP queries, and you can give that username separate permissions on the system data and the per-message-vpn data.

Access to the system data is divided into categories. The levels of access to the system data are:

• admin (full permission)
• read-write
• read-only
• none

Access to the message-vpn data is also divided into categories. The levels of access are:

• read-write
• read-only
• none

Also, the username can have individual per-message-vpn permissions on each of the message-vpns, and some default permissions for any message-vpns that are not among the exceptions.

A username with read-only permission on the system data and with default read-only permission on the message-vpns can give any commands that can be done with read-only permission. If that username gives commands that require read-write or admin permission, those commands fail with a response like:

`<permission-error>Command prohibited due to Authorization Access Level</permission-error>`

Some documentation links on usernames:

Management User Authentication / Authorization
Show Username Info
enable configure username
enable configure username message-vpn

Finally, one last point - there are two versions of SEMP - "legacy" SEMP and SEMP/v2. SEMP/v2 is not fully implemented, and specifically the implementation to date has concentrated on the per-message-vpn data - so, currently, if you want to get any system data you must use legacy SEMP.

surya kumar

Hi, Could you please provide some examples for legacy semp .
Am trying to create scripts from jenkins pipeline to create/delete destinations/bridges,VPN etc..
Thanks,
Surya | 9082961373

brenda

Example:
Legacy SEMP to create a queue

platform: Solace PubSub+ Enterprise Version 9.2.0.14

We want to do the following CLI commands over SEMP:

enable > configure > message-spool message-vpn default > create queue Q1
enable > configure > message-spool message-vpn default > queue Q1 > access-type exclusive
enable > configure > message-spool message-vpn default > queue Q1 > permission all delete
enable > configure > message-spool message-vpn default > queue Q1 > subscription topic a/>
enable > configure > message-spool message-vpn default > queue Q1 > no shutdown

So we issue the following legacy SEMP messages (illustrated with curl)

curl -u admin:admin -d '<rpc semp-version="soltr/9_2_0VMR">
    <message-spool>
        <vpn-name>default</vpn-name>
        <create>
            <queue>
                <name>Q1</name>
            </queue>
        </create>
    </message-spool>
</rpc>' http://192.168.133.77:8080/SEMP

curl -u admin:admin -d '<rpc semp-version="soltr/9_2_0VMR">
    <message-spool>
        <vpn-name>default</vpn-name>
        <queue>
            <name>Q1</name>
            <access-type>
                <exclusive></exclusive>
            </access-type>
        </queue>
    </message-spool>
</rpc>' http://192.168.133.77:8080/SEMP


curl -u admin:admin -d '<rpc semp-version="soltr/9_2_0VMR">
    <message-spool>
        <vpn-name>default</vpn-name>
        <queue>
            <name>Q1</name>
            <permission>
                <all></all>
                <delete></delete>
            </permission>
        </queue>
    </message-spool>
</rpc>' http://192.168.133.77:8080/SEMP

curl -u admin:admin -d '<rpc semp-version="soltr/9_2_0VMR">
    <message-spool>
        <vpn-name>default</vpn-name>
        <queue>
            <name>Q1</name>
            <subscription>
                <topic>a/&gt;</topic>
            </subscription>
        </queue>
    </message-spool>
</rpc>' http://192.168.133.77:8080/SEMP

curl -u admin:admin -d '<rpc semp-version="soltr/9_2_0VMR">
    <message-spool>
        <vpn-name>default</vpn-name>
        <queue>
            <name>Q1</name>
            <no>
               <shutdown></shutdown>
            </no>
        </queue>
    </message-spool>
</rpc>' http://192.168.133.77:8080/SEMP

Of course, you will need a management username with more than read-only permission for this. I have illustrated using the admin user.

To find the xml syntax to use, there is a "cli-to-semp" utility on the broker. If you ssh to the broker and get a shell in the application container (eg by running solacectl shell) you will be able to run cli-to-semp. Here is an example:

[appuser@vmr-133-77 ~]$ cli-to-semp 'enable configure message-spool message-vpn default queue Q1 access-type exclusive'
SEMP Request:
<rpc semp-version="soltr/9_2_0VMR">
    <message-spool>
        <vpn-name>default</vpn-name>
        <queue>
            <name>Q1</name>
            <access-type>
                <exclusive></exclusive>
            </access-type>
        </queue>
    </message-spool>
</rpc>

TD_asilva

Which user type is needed for using authentication with REST messaging? I have tried creating a user from the cli as detailed under the Configuring REST Consumer Authentication Schemes section here: https://docs.solace.com/Configuring-and-Managing/Managing-RDPs.htm. That did not work. I've also tried using the user that I log in to the admin panel of my pub/sub instance with. I am testing using the curl call provided on that page as well. If I turn off REST authentication, the call works, but if it's on, none of the credentials from the users mentioned above work - they just produce 401s.

TD_asilva

OK, I figured this out after re-reading the docs and your answer above. My confusion came from a couple places, which I will list here in case anyone else has the same questions/thoughts. Firstly, I had been adding users via the admin control panel under the "Users" page in the side bar. I thought that these were messaging users, but they were not. I had been using their credentials to log in and interact with my event broker, but in actuality, it seems like I had actually been logging in with the "default" client-username (which comes out of the box with no password). Also, the event broker comes out of the box with authentication enabled, but authentication method as none - so when I turned that to internal database and tried to use the users I had created under the "Users" tab, I was getting the 401s because those credentials were not client-username/messaging credentials. So after further research, I ended up giving my "default" client-username a password and turning on internal database authentication and now I am able to log in (and more importantly, lock down my event broker). Hope this helps someone else.

Solace employees: if I could make a suggestion, I would suggest that maybe somewhere in the initial setup/config docs, explain that the default configuration is open to the world. Also, while your docs do explain how to lock the event broker down in general, it might be useful to have a tutorial that explains how to go from initial (open to the world) configuration to a more secure configuration.

marc

@TD_asilva - thank you for the great feedback! We'll definitely take it under consideration

Solace employees: if I could make a suggestion, I would suggest that maybe somewhere in the initial setup/config docs, explain that the default configuration is open to the world. Also, while your docs do explain how to lock the event broker down in general, it might be useful to have a tutorial that explains how to go from initial (open to the world) configuration to a more secure configuration.