I have below queries in DFC and WDK:-
1) TBO is type base objects and is for specific object type in documentum. SBO is for global use. Can we make a SBO code to act like a TBO, if yes then how? How can I make my SBO specific for a particular object type.
2) How can I call a behavior class from an action.xml in WDK? If I dont want to use the component in my WDK customization. Any examples to support these queries will be appreciable.
3) Why is scope required in WDK? What is its role and can scope override over privileges in terms of hierarchy. If a user is provided a scope for a component in WDK but he/she doesnt have sufficient privileges to access it in documentum. Can the user still access the particular component?
4) Can folder security values override basic object level permissions? Which will come first folder security or basic level permissions or privileges?
Thanks!!
Deb
This is not kind of question for SO, at least in most parts. However:
1.) TBO and SBO are just architectural approaches for specific requirements. If you have specific code that you want to run for objects of specific type and not only for objects of subtypes, than you need to change object model to apply logic for all objects in type hierarchy. This isn't a problem with Documentum object/type model.
For example: You have custom_document as subtype of dm_document and custom_child1_document and custom_child2_document, both subtypes of custom_document. You have TBO set to custom_child2_document.
You don't want to apply SBO to have custom logic available everything under dm_document.
Just add TBO to type custom_documentm and you'll have your logic for all types under dm_document.
2.) You cannot call behavior class without invoking component. If you have specific code you want run from other places, isolate it at some other place and run it at will.
3.) You don't need to specify scope for your WDK configuration. However, once you learn WDK in details you will find it useful.
4.) Folder is object. You need to know that when you access objects via folders you need access permission for both folder and document linked to that folder (Read level is enough). You need only permissions on object id you access that object from DQL for instance. Basic and extended permissions are meant to be used in specific cases, you don't need extended permissions to read object content if you have Read basic permission on your object. However you need Relate basic permission + Run procedure extended permsission on target Workflow to start workflow with that specific object as attachment/package. Different rules go when you want to add object inside specific folder. But this is long story.
Regarding folder security - check this article.
Related
I'm trying to implement the RBAC (Role-Based Access Control) on a website.
The problem is the permission of nested objects.
Suppose we have some projects on the website. Each user can have a role in each project. e.g. user1 has the admin role in project1 and the customer role in project2.
Admin role, for example, consists of some permissions like Adding subproject, Deleting subproject, etc.
All docs I've read about RBAC, define general permissions like Add subproject, but when a user has this permission, it can add subproject for all projects not a specific project (here project1).
How can I restrict such permission to a specific project?
One bad solution is to define new permissions for each project. So the permissions will be Add subproject to project1, Delete subproject from project1, etc. and defining the corresponding roles like project1 Admin.
But I don't feel good about this redundancy; while the projects themselves can be added/removed, dynamically.
I think you've run into one of the known limitations of RBAC: permissions can only be assigned to user roles (not to resources or operations).
Recently, there has been growing development in permissions services based on Google's Zanzibar paper which describes a more general permissions system that supports describing resources, users, and relationships between them.
In a Zanzibar based system, you would define a resource for Projects, an admin and customer relation for Projects, and then defines tuples to manifest actual relationships representing your data. Thus, you can define <project1, admin, user1> and <project2, customer, user1>, a straightforward way to represent and check granular permissions on resources. This is a conceptual overview but there are concrete services where you can read their implementation specific details as well as try them out.
I stumbled across your post while researching authorization as part of my new job so I'm adding this answer in case others encounter similar challenges. Some resources we've put together than may be useful:
What is Zanzibar?: blog post that gives an overview
Playground: an interactive tool for writing and testing namespaces (there's a pre-written RBAC example you can test as well)
Disclaimer: I am a RBAC beginner
The way i understood RBAC is that you have Permissions which combine actual Resources and Operations.
In your case: The Resource would be "project1" and the Operation would be "create_subproject", so the Permission would be called "project1.create_subproject", which indicates that you have one permission per Resource, hence the mentioned redundancy.
My proposal to your question is to introduce a ResourceGroup. This is not part of the NIST RBAC Standard though. A ResourceGroup would combine Resources of a common type.
The access check goes through all objects in the ResourceGroup and if it finds your specific Resource it can evaluate the allowed Operations
OK. I've got a solution workaround for such a situation.
My problem with granularity was raised because of an extra-large context: where projects themselves are considered to be resources having independent permissions. But the problem is that with such permissions, other nested permissions are not independent anymore. (i.e. create_subproject permission is depended on project_access permission; which breaks granularity.
So the workaround is to define permissions at the project level (assuming the project itself is accessible), and define the tuples of <user, role, project> to specify which user has which roles on each project.
Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.
I'm trying to programmatically determine whether the current user has certain permissions on a given Active Directory object (specifically in this case, I'm trying to determine whether the user has the "Send As" permission for another Exchange user or distribution list object).
I already figured out how to access the ntSecurityDescriptor attribute using ADSI: I can enumerate the ACEs in the IADsSecurityDescriptor's DiscretionaryACL property. But:
How do I determine from that data whether the "Send As"-permission is explicitly allowed or denied for a trustee?
How do I discover this when the permission has been granted indirectly via group membership? Do I really have to parse the effective permissions myself by (recursively) checking all groups the user is a member of? Surely there must be an API for that task...
FWIW, I'm coding in Delphi (i.e. native Win32 code) using the ActiveDs.dll typelibrary, so .NET-specific solutions won't really help me much unless their source code gives me clues to how to do the same thing in native code. The same goes for PowerShell.
Before anyone starts: I already know about the PR_EMS_AB_PUBLIC_DELEGATES and PR_EMS_AB_PUBLIC_DELEGATES_BL_O Extended MAPI properties. However, this is not what I'm after. These properties refer to the "Send on behalf of"-right (a.k.a. delegates), not the "Send As" permission, which is quite a different thing.
Here's the MSDN article that explains - http://msdn.microsoft.com/en-us/library/windows/desktop/ms675580(v=VS.85).aspx. There is an attached sample that shows how to call the API.
I can't believe all I find to define role hierarchies is some strange .xml notation of ">" assignments. There has to be a way to create a RoleHierarchy object from a database defined role hierarchy.. ?!
I'm thinking of a table that has the columns:
role_id
child_role_id
defining a many-to-many relationship between Role and Role saying: which role has which children? I think I'd prefer children over parents as that's the way the hierarchy is set up in those .xml files: ADMIN > USER, USER > VISITOR.
(This by the way makes me wonder if the standard implementation also supports things like ADMIN > USER, VISITOR meaning USER and VISITOR are "on the same level".)
Now if I want to call
roleHierarchy.getReachableGrantedAuthorities(authentication.getAuthorities()));
I need a RoleHierarchy Implementation object. spring-security provides one but the setter accepts only this weird string representation. I don't really want to transform my database results into a string representation but rather work with some kind of tree structure.
So the only way seems to be extending the Implementation and writing my own setter to work with my database result set to build the rolesReachableInOneStepMap and rolesReachableInOneOrMoreStepMap.
Or does anyone know of a different solution?
Thanks for any pointers or confirmation!
We came up with our own solution by implementing RoleHierarchy, resolving the hierarchy inside the UserDetailsService and using a m:n self referencing relationship between Role and Role.
The hierarchy is thus saved in the database, cached at application launch, updated when needed and used to resolve all GrantedAuthorities when creating a UserDetails object on login.
On a Drupal 6 site, I have a 'moderator' role, who worka with an 'article' content type.
I want the moderators to be able to see the list of published/unpublished articles, and have the option to edit the articles (and change their 'published' status).
I do not want, however, for moderators to be able to edit (or see the list of) any other type of content.
If I give moderators the permission to 'administer nodes' I cannot stop them from editing other content types. If I remove that permission, they cannot access the content list (which is crucial for them).
Any ideas?
You might want to check out the Views Bulk Operations Module (http://drupal.org/project/views_bulk_operations). You should be able to use this module to build a custom view that displays only the content types you want the 'moderator' role to edit.
If you all your content types are created with CCK you can unset each content type's permissions for moderators. If not, I'd recommend you do create them in CCK :)
you definitely don't want to give them "administer nodes" permissions since it's a huge can of worms. if the nodes are unpublished you'll need to use the views module to get listings that will let them see the nodes.
that said unless the node type is one created by a specific contrib module you should be able to set the permissions on a per-role basis. if not you might look at using a node access module to control permissions.