Several questions for setting up SSO with authorization server

[AlexGoris-KasparSolutions]

I'm looking into setting up authorization server using SSO. I've got the basics working: I have a local admin user which I used to create a user which exists with the same username on my keycloak instance, and I'm able to log in with that new user through the keycloak SSO mechanism, so far so good :). We want to setup JSReport to allow several users in our company to configure their own templates, which should be possible through the new user groups feature: Add the correct users to the correct groups, then grant permissions to the relevant templates for those user groups. There are however a few things which I can't find an answer for in the documentation:

• When a user tries to log on through SSO, and this user doesn't yet exist in JSReport, the user is shown a blank page with the error exception and stack trace. Is there a way to provide a custom page which should be shown to the users so that we can inform them they should contact our team to have them set up?
• It seems the default admin user (configured through extensions.authentication.admin) is the only user who can add and delete users. Since we work in a team it would mean having to share this admin user's credentials across the team, which is considered a bad security practice. Is there a way to define multiple admin users?

I'm pretty sure this last one is not possible, but decided to write it down anyways, so it can maybe be considered as a feature request: We have the possibility of creating folders, and then creating requests, templates etc... under those folders. It would be great if we could define permissions on those folders, and have all child elements in those folders inherit the folders permission, this would save us a lot of working having to grant permissions to each individual item.

[bjrmatos]

hi @AlexGoris-KasparSolutions

When a user tries to log on through SSO, and this user doesn't yet exist in JSReport, the user is shown a blank page with the error exception and stack trace. Is there a way to provide a custom page which should be shown to the users so that we can inform them they should contact our team to have them set up?

something like that does not exist at the moment but it is really a good idea, i am opening an issue for this so we can plan it.

It seems the default admin user (configured through extensions.authentication.admin) is the only user who can add and delete users. Since we work in a team it would mean having to share this admin user's credentials across the team, which is considered a bad security practice. Is there a way to define multiple admin users?
I'm pretty sure this last one is not possible but decided to write it down anyways, so it can maybe be considered as a feature request

you are right, this is not possible, the admin user is still considered a special entity that has master privileges for things like user management. I am opening an issue also for this so we can discuss it and plan it.

We have the possibility of creating folders, and then creating requests, templates etc... under those folders. It would be great if we could define permissions on those folders, and have all child elements in those folders inherit the folders permission, this would save us a lot of working having to grant permissions to each individual item

hmm as far as i remember this should work, if you right-click the folder and choose Edit, you will be able to assign permissions on the folder, which in the end should make the entities in the folder inherit the permissions.

can you describe a case in which this does not work?

[bjrmatos]

I'm looking into setting up authorization server using SSO. I've got the basics working: I have a local admin user which I used to create a user which exists with the same username on my keycloak instance, and I'm able to log in with that new user through the keycloak SSO mechanism, so far so good :)

just FYI I see that it was not mentioned in the docs, but since 3.2.0 we have support for users group based login with SSO.

I have updated the docs to mention the usage of groups when doing SSO.

what I want you to know about this is the following:

jsreport needs to know how to associate the users from your authorization server to users/groups in jsreport, this association is needed to correctly identify which jsreport entities and permissions the user of your authorization server is able to work with in the context of jsreport. to do this you will have to do any of the following:

• associate the jsreport username of an existing jsreport user with a claim (authorizationServer.usernameField) linked to the user handled by your authorization server.

• associate the jsreport group name of an existing jsreport group with a claim (authorizationServer.groupField) linked to the user handled by your authorization server. this association has the extra advantage of not requiring to duplicate the user of your authorization server in jsreport, you can handle all the permissions in jsreport in groups and let your authorization server handle the user, you just need to associate them so after login the jsreport is able to identify which entities it has access to. When doing SSO to the jsreport studio you can customize the username shown there by setting another claim (authorizationServer.usernameField) to the data linked to the user handled by your authorization server.

so in your case, you can skip this part:

which I used to create a user which exists with the same username on my keycloak instance

you can start avoiding this duplication (avoiding the creation of a jsreport user) if you define all your permissions in jsreport groups and then on keycloak you associate the group name with the users (the keycloak users), this means that after you do SSO login in studio using a keycloak user, according to the associating you have made, this user will now have all permissions in jsreport to the linked group.

[AlexGoris-KasparSolutions]

Thanks for all the great feeback @bjrmatos!

I indeed overlooked the group permissions. This completely fixes that point I made.

The feature to be able to map users to groups works perfectly, and combined with the group permissions, eliminates a lot of situations where the team would previously had needed admin access (and having to resort to using the shared credentials), like adding a new request under a specific group, or granting a new user access.

Thanks again, it's so nice to use a product which ticks all the boxes :)