What is 'project scoped' visibility in RTC ?
Does this mean members of the project area can view this stream or workspace ?
When you create a repo workspace, you can select "project scoped" in order for the member of the project area to be able to have a look at your change sets that you have checked out in it.
That means they will be able to add your repo workspace to the "flow target" section of their own repo workspace, not for delivering anything (you cannot push change sets to a repo workspace you don't own), but to accept change sets.
This is very useful if you check in changes, ... but don't deliver them on the stream.
If the visibility is "private", your change sets are stuck in your repo workspace.
If the visibility is "project scoped", another member of the project area can have a look, accept your changes and deliver them for you while you are not available.
The article "Controlling access to source control in Rational Team Control" adds more on the "project scoped" visibility, for other elements than just the "repo workspace".
For instance, a component can have its visibility scoped:
The access control for source control is based upon the component.
For components owned by the project area, its access is scoped the same way the project area is.
For components owned by an individual user, the owner can specify how it is scoped.
For streams:
Starting with RTC 3.0.1, streams can be scoped to individual team areas, meaning that only the team's members will have access to the streams and components that the team owns.
Pros:
Tighter access control.
Access control can follow organizational hierarchy.
Cons:
Not all teams fit cleanly onto an org-chart.
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 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.
We've been using Trac for a while now for our developers only. However we are now opening it up for our (internal) clients. We have a project listing page (based on the default one that comes with Trac). What we'd like to do, is display more information about the project than what is currently available.
I have searched google and here, to see if I can find how to get more information. There seems to be a variable called $project which has .name, .description and .href as attributes.
Is there somewhere, a list of the attributes available? Or perhaps a different solution altogether that will allow us to display more information on the project list page. Such as the number of open tickets etc.
As far as I known, you can use $project.env as well. It is an object, which provides a number of attributes:
$project.env.base_url
$project.env.base_url_for_redirect
$project.env.secure_cookies
$project.env.project_name
$project.env.project_description
$project.env.project_url
$project.env.project_admin
$project.env.project_admin_trac_url
$project.env.project_footer
$project.env.project_icon
$project.env.log_type
$project.env.log_file
$project.env.log_level
$project.env.log_format
More detail is available at env.py
On the project page customization page there is not much variables, indeed. Looking at the source code there is also trac.version, trac.time, but that's all. There is also project.env that may hold more information. I do not have a multiproject setup at hand, so you might be interested to see for yourself what variables are available with TracDeveloper plugin. It dumps variables if enabled and you add debug=true in the URL.
I'm looking for some clarity with regards to the use of Windows Workflow 4 in an integrated solution - specifically with regards to rehosting the designer and executing workflows created by eg. a business user.
Is the intention that the required custom activities are created and compiled into a dll, which is then deployed with the rehosted designer, allowing the business user to create/configure workflows that make use of these activities - the business user would then save the workflow as XAML, which can be stored in a location known to the application (database, filesystem etc.), and then when it is necessary for the application to execute a workflow, it can use XamlServices.Load to load the workflow from the specific location and execute it as a DynamicActivity?
How is the workflow saved so that it can later be reserialized with properties and other configuration values? I've tried deserializing a Xaml file saved out of the designer, and also using XamlServices.save().
Are there any potential issues here with using bookmarks/persistence?
As a related question, is there any easy way to "Go back" in a workflow, without defining return branches on every flowchart element? I'm looking at integrating a workflow with a UI for a user to enter responses, which the wf will process, and make decisions based on the input. Through the UI, the user should be able to "Go Back" to a previous input.
You can use the ActivityXamlServices.Load(path) to load a XAML file. It will return an Activity, actually a DynamicActivity, and you can use a WorkflowApplication to run it.
See my blog post for an exmple.