Sharing shiny apps and dynamic reports could certainly be helpful at my organization, but the real value add for us would be the ability to easily publish certain content to external users who can only see that specific information.
Has anyone set up a system whereby RSConnect is used as the tool to internally develop and share content but then have the ability to allow restricted view permissions for external users (potentially via a different authentication scheme)? The key thing here is that we wouldn't want external clients to see any of the public content in RSConnect, rather only the apps that are explicitly shared with them.
I don't think you can have two separate Auth configs on a single deployment.
In the situation you describe, I'd probably opt to deploy 2 Connect instances. One internal, and one external. Publishing is so simple that apps could easily be published to both of necessary. Or you could use a CI tool to automate deployment, for which their is guidance in the admin guide.
You could also look at shinyApps.io - which is basically RSConnect - then only publish the external content to shinyapps. You get the same 1 button publishing to the site
Mark is correct with one little exception: when using LDAP authentication, it is actually possible for you to define multiple LDAP servers/configurations and we would try to authenticate users against each of them. We have some customers who have a "corporate LDAP" server and a "vendor LDAP server," for instance, and they have RSC configured to point to both LDAP instances so that both groups can login.
That being said, there unfortunately isn't much functionality today to distinguish those users once they've logged in. We have two features on our backlog that sound relevant, though; perhaps you can tell me if these would help.
We've heard requests for a new class of users in RSC that would provide a more limited experience (no visibility into other users on the server, no ability to explore content, etc.).
Some folks are interested in setting the user role based on LDAP/AD group membership. So if you were a member of the "vendor" LDAP group, for instance, then you would be assigned this restricted user role automatically, while the rest of your employees would still default to a regular viewer.
We've also envisioned tackling these problems by adding support for access controls on tags. That way you could have a "vendor" tag that exposes certain content to your vendors. The downside of that scenario is that it doesn't accomplish your ask of "wouldn't want external clients to see any of the public content." In RSC's working model, the expectation is that "public" really means public to all users, so I'm not sure that how we could punch holes in that without really muddying the mental model here.
It does sound like two separate RSC servers might be the best arrangement for you, as Mark suggested. On one server, you restrict access to employees then have public content truly be public to all users on that server. Then on the other server you support client logins and have no public content -- only content that's explicitly shared with particular groups or individuals.
If that sounds like the right technical solution, then you'd just need to resolve the pricing side of things. I'm not on the sales side of the world so I don't want to make any promises, but I'm sure we could do better than a simple "2x your current price" if this is a path that's interesting to you.
I imagine this issue is rather universal. We too have different clients who want reports, dashboards, etc. At the same time, these clients should not be able to see any information (including, but not limited to data, users, reports, dashboards and so forth), that pertains to other entities. The number of clients is sufficiently high to render the option of buying separate RStudio Connect instances impossible. Some sort of internal restrictions are needed to handle the reporting securely, also respect to the GDPR policies. Any thoughts on this?