This post originated from an RSS feed registered with Web Buzz
by Ed Tennant.
Original Post: Oracle WebCenter Interaction Security
Feed Title: All the Way to the Beginning
Feed URL: http://allthewaytothebeginning.blogspot.com/feeds/posts/default
Feed Description: Beginning Groovy and Grails topics including books, training, developing with NetBeans, Grails plugins, and hosting.
One of the strengths of the WebCenter Interaction (WCI) portal is extremely granular security. Every WCI portal object has security. This can also create a maintenance nightmare when security needs change. It is difficult to remember all of the objects that need to be updated. If you change a page and forget the portlets it doesn't work very well. Likewise, a user can have access to a snapshot query portlet but if they don't have access to the objects being queried they would see an empty portlet. It reminds me of the saying, with great power comes great pain-in-the-tush.
To help alleviate this difficulty, when modifying the security of a folder, the portal will ask if you want to set everything in the folder to the new settings. This is great when you open a community to a new group because it will give the new group access to all of the pages and portlets contained in the community. Unfortunately, this can totally mess things up. Consider a community with two pages, one is seen by group A and the other group B. In this case both group A and group B must have access to the community. Now we decide to give group C access to the community and both pages. The community security is updated and the portal asks if it should change the security on the pages and portlets. Since we want group C to have see everything we let the portal cascade security. All of a sudden group A can see the group B page and vice versa. Ouch!
The practice we have adopted when creating a new portal community in hopes of mitigating this risk is to create four community groups by default: community managers, content managers, community members, and community guests. By establishing these groups up front they can be used to secure the contents of the community even before the groups have members. When it is time to add users to the community, instead of adding users or groups to the community and cascading security, the new users are simply added to the appropriate existing community group. Therefore security doesn't change and we avoid potential mistakes. It also allows different users to have different amounts of access. For instance, community members are likely to see more pages than community guests; using multiple groups makes this possible.
Finally, this also provides the mechanism to grant specific users additional privileges to administer a community. They can be added to the content managers or community managers group and that group can have edit or admin privileges. I don't expect this solution will work in 100 percent of the situations we will encounter over the life of our portal but it should be sufficient in the majority of cases. If we communicate using the idea of the four community groups it becomes straightforward to explain which users should have access to what pages and portlets. Then the on-going maintenance is simply managing the group memberships.
Previous Topic
