I need to enable ucm security so that whoever belonging to the org unit should inherit access to the corresponding folders. I can think of a solution wherein we need to create 1000 roles (corresponding to each org unit) and create as many security groups as the number of folders and map the roles to groups. This doesn’t seem to be a viable option as this involve way too many roles and security groups that the system may not even support. Can you plz provide some pointers.
Certainly, use accounts, not security groups here. Managing Accounts - 11g Release 1 (11.1.1)
a) accounts have hierarchical nature which better corresponds with org charts
b) accounts can be mapped to user groups from LDAP
Thanks for the reply.
I did analyse the possibility of using accounts for this case. However I am not able figure out how to achieve below scenario using accounts.
If Account is setup at the content item level, how do I achieve below.
Org1 – Content Item 1, Content Item 2, Content Item 3
Org2 – Content Item 2, Content Item 3, Content Item 4
Org3- Content Item 1, Content Item 2, Content Item 5.
Or to keep it more simple
Content Item 1- Org1 , Org2, Org3
Content Item 2- Org2, Org3, Org4
You need to put some more context into that.
For instance, if you have org units North, South, West, and East, and accounts (regions) like NorthEast, SouthWest, etc., where members of relevant org units (North and West for NorthWest) would have the appropriate rights. Of course, this expects that the number of combinations is reasonable - if you can end up with all permutations of your org units (factorial of 1000), this way won't help you, because then your data are not hierarchically organized at all. You could, then, use ACLs, which are very dynamic, but I'm afraid you will end up with unmanageable number of ACLs and performance issues.
Ok, Here is what i want. I need to create organizations which can access certain folders. A single folder can be accessible across two different orgs.
And When i create any user under a specific organization, I need user to inherit all folder access of that org.
The number of organizations in my case will be about 1000-1500.
Can i have Group/Role ACL defined at each folder and have 1000 roles defined in my UCM. Is this a viable solution?
What permissions will the two organizations have? Always both RW, or can there be more combinations?
With ACLs, there are always two potential issues:
- manageability - you write that a single folder can be accessible across two different orgs. I think this can be viable only on condition that there is just one root folder with such a combination of orgs, or that it will never change in the future. The (dis-)advantage of ACLs is that initial permissions can be revoked. Now, if you have two or more folders somewhere in the hierarchy that has the same settings, and you want to revoke permissions in all such folders, you can be in troubles. If you have a common root, you can easily revoke it at the root level and propagate the new settings down to the hierarchy.
- performance - ACLs are defined per folder or per document, but unlike security groups, or accounts, they are not persistent objects (in the data model there is not, or at least there wasn't where I studied it last time, any table that would store their definition). Therefore, queries like 'show me all documents that (a user has access to) containing XYZ' cannot use joins to eliminate easily inaccessible documents. I've heard that in one of latest releases ACLs were heavily improved, but I'd still tend to declaratory security settings like sec groups or accounts, if there is a chance.
For now the requirement is to have same documents at same level, that means the security is configured at the root folders and all the subfolders inherit the same security.
If not for ACL, is there any way i can achieve the above requirement with accounts alone? I need two orgs to access same folder with RWD premissions.
I thought I did suggest a way. Maybe, it wasn't that clear:
- so, let's suppose that in LDAP you have user groups that correspond to your org units and contain users
- now, accounts can also be defined in LDAP - see Additional Content Server Security Connections - 11g Release 1 (11.1.1)
So, you will need user groups defined as @ORG_X_ORG_Y, where ORG_X and ORG_Y represent all combinations of pair of org units. There will be a lot of such combinations ( (n+1)*n/2, which mean more than 500K for 1000 org units, and more than 1M for 1500), but this creation can be automated - @ORG_X_ORG_Y will contain two user groups, ORG_X and ORG_Y
- rather than roles and ACLs, you will use accounts only (you will need just one role, or you can use standard roles like reader and contributor to fine tune permissions across all available accounts)
Considering the performance, with ACLs, you will always work with all the documents. With accounts, you will first use accounts as the primary index (a user will have access to 1000 out of 500K combinations, so if your content is distributed more or less evenly you will work just with 1/500 of documents). Furthermore, accounts are searchable, so you may revoke them in much easier way.
I did a small POC on how this entire thing works. I am using just account for the solution as suggested. Here is a problem am dealing with as of now.
Role - TestRole and RWDA on TestGroup
Folder - TestFolder ,
security group: TestGroup
Now the problem is...if i have any account which start with Test, lets say TestA, and it is associated to another folder...even that folder is given the access to TestUser. How to restrict it? I want only TestFolder with account Test should be accessible.
Please revert if my question is not clear.
The caveat is in your mapping - a membership in the TestRole group grants a UCM role TestRole (RWDA to sec group TestGroup), but also permissions to the account Test.
a) you need to differentiate between roles and accounts
(Also recommended): use better naming convention. For instance, your role could be named as Reader (granting R permissions on all sec groups), Contributor (granting RW), etc.
Your 'account' groups, which can also be defined in 'weblogic' (I guess the embedded WLS LDAP is meant here - in production, usually an external one is used) via the mnemonics @account_name can correspond to your org chart. Therefore, they might be named as your org units.
b) accounts are hierarchical
Keep in mind that accounts are hierarchical - this means that if you give permissions to Prefix, the access to all PrefixSuffixes is granted as well (e.g. access to USA grants accesses to USA/FL, USA/MA, etc.). It is a good practice, then, to use an ending character or sequence to prevent unwanted permissions (e.g. USA_BU, USA/FL_BU, etc.)
Yes, you can map your roles from an external LDAP, and it is a good practice. However, that's not the point - the point is that you should not use membership in one LDAP group for both roles and accounts. It's apples and oranges - accounts correspond to your org chart, whilst roles define what position a particular employee takes (if there is no distinction needed you can go with a single role for all the employees).