Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

READONLY role handling problems with the ReST API

Description

On typical deployment, all the users have ROLE_USER assigned. That should provide read-only access to the ReST API.

The ROLE_REST was designed to provide full access to ReST (that not necessarily means, the user can access the rest of the WebUI). In terms of ReST, ROLE_REST can be compared with ROLE_ADMIN. In other words, the user is able to perform changes through ReST like modify requisitions, modify nodes/interfaces/services, change monitored services behavior, alarm/notification behavior, etc.

Now, if a user has ROLE_REST but is also marked as a read-only user (in Horizon 19, means it also has ROLE_READONLY), the user should not be able to perform PUT/POST/DELETE requests.

Thre are a few exceptions, like the measurements API which has POST requests but they won't perform changes. Those ReST queries should be treated as read-only, like GET requests.

Unfortunately this is not the case, and demo.opennms.org is configured in this way. In my opinion, the demo user should not belong to ROLE_REST That should fix the security access problem on that server.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jesse White July 31, 2019 at 5:46 PM

Having ROLE_READONLY be a role that doesn't grant additional permissions but actually takes some away makes managing the permissions much more complicated.

I agree that we need to review the way in which we handle roles and permissions throughout the application.

Alejandro Galue April 10, 2017 at 10:16 AM

One way to configure access through the Sprint Security XML, is by using SPEL expressions, instead of a discrete list of ROLES, as described on the following link:

http://docs.spring.io/spring-security/site/docs/3.0.x/reference/el-access.html

The alarms ReST end point (and for the upcoming 19.1.0, the acks end point) has hard coded rules to make sure the user has access, but I think these should not be controlled in code, as change those rules means code changes. All this can be done with the appropriate changes on applicationContext-spring-security.xml

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

PagerDuty

Created April 10, 2017 at 10:13 AM
Updated September 21, 2021 at 6:22 PM