LDAP group to be mapped to user role

I am new to RConnect - We have integrated RConnect with LDAP and all the users logged in by default are publisher role. We need a seperate LDAP group to be provided the viewer role, can we map the LDAP group to the User role, so all the users on the LDAP group will be mapped to the user role ( role mapping ).

Any suggesstions ?

Thanks for sharing this feature request! We will definitely add your vote for this feature, which we have had requested before.

Unfortunately, today there is no automatic mapping of user roles as you describe. However, it should be possible to create a workaround using the RStudio Connect Server API: Posit Connect Documentation Version 2024.02.0 - . This should allow you to (1) check user roles, (2) change user roles (if run as an admin), and (3) check group membership.

You could even script this using R and scheduled as an Rmd on RStudio Connect. If you end up doing this in R, this experimental R package might help you.

You could do something like:

client <- connect(
  host = 'https://connect.example.com',
  api_key = '<SUPER SECRET API KEY>'
all_users <- client$users()

updated_user <- client$users_update(user_guid = "user-guid", user_role = "viewer")

Thanks Cole.

Do I need to create the rstudio connect user from the remote LDAP group to map the correct user role or can i create rstudio connect group which will eventually pull all the group members locally?

  1. create user / group in rconnect
  2. verify the user role for the users
  3. change the role for the group members

In our case, all the users are in LDAP and we don have anyone locally in the rconnect. So need the steps to manage the role in this case.


Right, you will need to create the user before you can customize the role. If you do not create the user account, the first time the user logs in, they will get:

  • their group memberships picked up automatically
  • the default role

You would then need to follow up later to "correct" the role. If you want the "first time they login" to have the appropriate role, then you will need to be sure that you either (1) align that with the default or (2) pre-provision the user account on Connect.

It's worth noting that users do not take up a license seat on Connect (even if you create them) until they log in.

The user creation process for LDAP is spelled out here:


Further, it is shown explicitly in the Connect API cookbook:


However, I just realized that we do not support group member search for LDAP groups:


So that means in order to do the group lookup, you would need to run an ldapsearch or call directly against LDAP. Is that something that you are familiar with? ldapsearch is a command line utility that allows searching for group members, making arbitrary LDAP queries, etc.

One follow-up question here from our developers:

How would you expect the case to be handled where a user is a member of the ad-connect-viewers group and a member of the ad-connect-publishers group? If we had this feature, how would you expect Connect to behave?

Some thoughts:

  • error / warn
  • set role to the "greatest" of the roles - publisher
  • set role to the "least" of the roles - viewer
  • something else entirely?

Hi Cole,

I would prefer to be set role to the "greatest" of the roles - publisher, as user is anyways part of Publisher group.


1 Like

Thanks for this feedback! This is definitely helpful for developers to consider as they explore this feature.

One final question - what if roles were not strictly ordered (so that "greater" may not have any meaning). I.e. if "Viewer" had some permissions that "Publisher" didn't. We have explored the possibility of making roles more flexible / configurable in the future.

If there was no strict ordering and your LDAP groups created a conflict that we could not resolve, how would you expect Connect to behave? Would the user get denied on login? Would Connect proactively warn about this potential conflict?

Hi Cole,

This seems to be RBAC (role based access control ) vs ABAC ( attribute based access control).

So I believe the connect should be allowed to decide permission based on the attributes, once the user is logged in using the LDAP ( used here only for authentication and not authorisation ) and default role is assigned.
Then for the contents to be accessed must have a ACL defined with LDAP groups allowed to access as viewer , publisher and collaborator. so if the member is part of any LDAP group then respective permission must be applied to the content for the user.

just my view :slight_smile:

Tactically, we can handle this now by warning the user and allow them to switch roles if possible to perform the actions on the respective role.


1 Like

That makes a lot of sense! Thanks for the feedback! This is definitely helpful input to have as we think over how best to build this functionality. Please let us know if you have any more thoughts / questions / ideas on this topic or others!