Workspace Membership

Hi All,

Can someone explain to me how membership is a workspace works. How does this tie into trustee assignments to security policies, if at all. How does it tie into workgroups. What kind of privleges does this give a trustee.

Thanks
E

Find more posts tagged with

Comments

Migrateduser

Hi E -

I think you asked about six questions there, so let me try to succinctly outline the basic principles that should be operating here.

Trustees are the units to which permissions are ultimately assigned. They can either be created directly in a realm in one of your libraries, or imported into a realm using LDAP synchronization. The realms themselves have a hierarchy similar to LDAP, but cannot be directly manipulated with LDAP queries. A trustee can be an individual user, a group, or an organizational unit. Workgroups area a way for a workspace owner to dynamically assemble trustees into groups he can manage, without IT intervention. Access to any object (document, project, workspace, issue list, whatever) is determined by assiging privileges and security policies to workgroups. A privilege determines what you can do, a security policy determines what you can see.

Does that answer your question?

Migrateduser

Thanks for the reply.

Can you clarify why I would be required and what benefit I would gain by adding trustees to a workspace if there is no access rights associated with it.

Also, how does inheritance work with security policies. If every item must have a policy assigned, then how does inheritance work?

Thanks
E

dbguy

If a trustee is not a member of a workspace, he/she cannot see the workspace or any of its contents. Once you grant membership, the trustee can see the workspace and whatever content has the public or view predefined security policies.

If you are using custom security policies, the trustee may not need to be explicitly added to them to see content. For example, if the default level for a policy is VIEW, and there are no denials, the trustee will be able to see content secured by this policy.

I think the "inheritance" you mention is not really inheritance in the usual sense. Say you have folder 1, that contains folder 2, that contains document X. To see X the trustee must have view rights on it and browse rights in folder 1 and folder 2. Say they all have different policies and you revoke/deny browse in folder 1, the trustee cannot see X anymore. It is kinda inheritance, but it may be a bad use of the word.

Migrateduser

That terminology tripped me up a bit as well, which is partly why I hadn't responded yet. For a pretty thorough, yet reasonly succinct explanation of the permissions model, pages 40-46 of the Best Practices manual are really excellent. Inheritance makes me think of more like the Windows ACL security model, where you can explicitly grant permissions on a file inside a folder to which the user might not have access. The inability to do that in WorkSite is a good thing, because it limits the ability of users to overexpose their data.