Document roles/grants available in Spring Boot Admin

[cdprete]

Hello.
In the company where I work, we're potentially evaluating Spring Boot Admin as a central monitoring solution for our, so far, Spring Boot applications.
The plan is to allow users to login into it based on the role(s) they've assigned in our Active Directory (LDAP authentication and authorization).
I've more or less clear how I should configure the application in order to achieve LDAP authentication but, regarding the authorization path, I've no idea which role(s)/grant(s) Spring Boot Admin supports so that I can map my incoming role(s) with the one supported by Spring Boot Admin in order to grant/prevent access to certain parts of the UI and/or data it displays.

Question
Can you please extend the documentation by specifying as well which role(s) Spring Boot Admin supports and what does/should each role mean?

Enhancement
Please extend the documentation with the role(s) Spring Boot Admin supports.

[erikpetzold]

Hi @cdprete , there are no roles in Spring Boot Admin. All users have the same permissions.

There can be some kind of read-only mode built with security config by not accepting post requests, see #1692

Besides that it is very individual which actuator endpoints your applications provide and what should be allowed, so there is no central permission model.

[cdprete]

Hi @cdprete , there are no roles in Spring Boot Admin. All users have the same permissions.

There can be some kind of read-only mode built with security config by not accepting post requests, see #1692

Besides that it is very individual which actuator endpoints your applications provide and what should be allowed, so there is no central permission model.

Hi @erikpetzold.
Indeed, that may be a solution to a certain extend.
Of course, as stated also in the provided issue, getting error messages back is not ideal.

Also, are the authentication and authorization information automatically propagated the actuator endpoints called from a client or do I need to build something around the "customer headers" which are present in the documentation?

Regarding the permissions, I was hoping in some sort of:

• no permission: a view X is hidden
• read permission: a view X is rendered in read-only mode
• write permission: a view X is rendered in read-write mode

Maybe - this is just an idea in the wild - it could be possible to extend the instance metadata so that each instance, during the registration, may specify which role or permission is needed to access a view X in read and/or write mode.
In this way, the server would have all the needed information to know if and how it has to render the view X.
Of course, if no authorization information are provided for such a view/endpoint, the old logic applies for backward-compatibility.

[cdprete]

Hi @erikpetzold.
I use the chance of this ticket being open to say that, ideally, also CustomCsrfFilter mentioned in the example https://docs.spring-boot-admin.com/3.4.1/security.html should be shown in there, in my opinion.
I would personally also add the findings which are in #1692

[erikpetzold]

We are discussing this internally. This would imply some big changes to how Spring Boot Admin works and what it is used for. But we also see the benefits of the flexible role model. We will come back with a response, but this may take a bit of time.

[cdprete]

We are discussing this internally. This would imply some big changes to how Spring Boot Admin works and what it is used for. But we also see the benefits of the flexible role model. We will come back with a response, but this may take a bit of time.

That's a great news. :)