🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Can the SEMP – REST API work with a READ-ONLY user? If so, how do you create one?
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!
Best Answer
-
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-vpnFinally, 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.
7
Answers
-
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-vpnFinally, 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.
7 -
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 | 90829613730 -
Example:
Legacy SEMP to create a queueplatform: 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/></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/SEMPOf 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>0 -
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.
0 -
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.
1 -
@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.
0
