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.