How can I change the permissions in CKAN, so every editor/admin of an organization can add a group to a dataset (right now, the editor or admin has to be a member of the group to be able to add a certain group to a dataset)?
The dataportal I am developing only has 8 groups and every admin/editor should be able to add these groups to a dataset.
It seems to me that Group permissions are a bit of a hangover from the past (there was a time in CKAN without Organizations and only groups, and groups are based heavily on Organizations internally) and I wanted to make a proposal to the CKAN developers for providing an option to remove them (i.e. every Org editor or Admin can add anything to any group). Apart from that possibility there are a couple of workarounds:
Make everyone of these users a superuser (probably bad)
Make a "master" group which contains all existing groups (this is only
possible via the API) and then use the cascading authorization
configuration:
http://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-auth-roles-that-cascade-to-sub-groups
Make an extension that hooks into the user creation process and
automatically adds all Org editors and Admins to all groups
Make an
extension that doesn't check or relaxes auth when trying to add
datasets to groups (this seems like overkill compared to the general
change I mentioned at the beginning: both would need to be coded and
I am more interested in doing the first one!)
Related
I want to make access polices on the folder each of costumer:
DocumentLibrary/Custumers/CostmerA
DocumentLibrary/Custumers/CostmerA
.
DocumentLibrary/Custumers/CostmerN
Then the CustomerA (tenant user) can't access the folders of other another Customers
I think abut doing this using "Tenants", and a would like to see an exeample.
The Multi Tenant (MT) feature in Alfresco does not do what you ask for. Especially, tenants don't share the same document library, they are completely separated.
You could use MT to achieve complete separation of tenants. This separation would include not only documents but users, groups, permissions, everything you deploy in the Data Dictionary.
I recommend to use a single (default) tenant and normal folder permissions if you just want to handle read/write permissions.
Before using Multi-Tenancy, pay close attention to the features you will be giving up, which are documented here.
The correct way to do what you are attempting to do is to simply use permissions. Give all of your customers access to the /customers folder. Then, in each customer-specific folder, break the ACL inheritance (Manage Permissions, Un-check Inherit Permissions), then assign the specific customer (perhaps using a group) to the folder with the appropriate access.
You might even consider using a separate Share site for each customer, which would make this easier.
The caveat to this is that if you are trying to hide all of your users and groups from each other, then really what you want are separate repositories, and that's what Multi-Tenancy provides, at the expense of the features I referenced at the top of the post.
If you go that route, you'll have to use the tenant console to create each customer-specific tenant. Your tenants will be separated into their own repositories. And you won't have a way to view all of your customer documents side-by-side without switching tenants.
Honestly, due to the stability of the multi-tenancy feature and the other features you have to give up, I'd be more inclined to use completely separate servers, even though that increases your maintenance burden. Alfresco doesn't even use their own multi-tenancy feature in their own cloud product.
You really should have no problems. MT is already there, you just need to enable it. There's no additional work that you should do in order to hide tenants from each others - that's the whole point of this feature.
http://docs.alfresco.com/5.1/concepts/mt-intro.html
I have been trying for a few days to figure out how to allow a set of customers to view a specific set of documents in OpenERP's knowledge management module. The goal is to easily add access to various sets of documents to existing customers. My particular use is that I deliver three different types of training sessions each of which has a set of materials in pdf format. I would like to offer all the attendees access to those materials through OpenERP (since they are already in the system as customers). I am not using the Events modules and I am not particularly interested in exploring it at this time.
Setup that I have tried:
Have some existing customers with at least a name and email address
Create a "Directory" in Knowledge->Document Management->Directories
Add a few pdf files in Knowledge->Documents each with the directory just created
Create a "Group" in Settings->Groups
... ???
I've tried various combinations of access rights, rules, users, etc. but nothing seems simple and nothing works exactly as I'm hoping: namely that a customer receives access through the web client to a clearly labeled menu that then shows them exactly the set of documents that they are allowed to access.
I have also tried the various "Share" features that can be done with documents, but again, they don't seem to work well for existing customers, nor so well with groups of related documents.
I have been able to get a user (not a customer) to get restricted access to see only a small set of the documents in the Knowledge Management system, but even there I'm having a hard time restricting that user to see only the documents that are in the specified directory.
I've taken a look at a number of sites (including ZestyBeanz) that describe various means of getting users to access the portal / limited features of OpenERP.
My OpenERP installation is self-hosted on Amazon so I have full control. I have written sophisticated modules for OpenERP and I am a reasonably capable Python programmer so please feel free to get seriously technical if that would help. I'm willing to consider writing a custom module to enable what I feel should be an obvious and easy feature, but that really seems like overkill!
To be clear: either a configuration or programming solution would be fine by me.
We have multiple apps that use OpenLDAP for authentication and for storing data. We have quite lot links to these OpenLDAP entities from DBs from multiple applications (each app has its own DB), so when you change OpenLDAP entity you have to track object changes (currently we are using DN as a reference key). And inside LDAP we have few references, like what user can access which objects, as they can have very specific access rights (access right are not depend on hierarchy), LDAP also doesn't track these changes, so once these referenced objects are moved we need to track them both in LDAP and in multiple DBs.
I'm new to linux and OpenLDAP (we have it running on linux), but to me this all seems like a wrong way to handle things and it seems like we are using LDAP in the way it wasn't designed to be used (The idea of using it like this came from senior developers).
My questions is:
Is there anything bad to use LDAP in way i have described.
How can i change the OpenLDAP schema to create something like GUID for all object classes we are using, this way at least we can store object GUID instead of DN and don't have to track changes. If I change schema will I be able to perform search and filter by this GUID?
Sorry, but your architecture description is not clear for me, so I can't write if it's bad to use it like this.
Having multiple directories in a company is very common in middle to big companies (most of the time it's due to historical reasons) but for single sign on "Meta directories" are setup to have a single authentification point.
In my point of view the DN is obsolutly not the way to point an object in a directory, jus because moving an object is changing his DN. Each directory has got an attribute inherited from the "top" class that contains an unique identifier inside the directory. In OpenLDAP it's entryUUID.
entryUUID: bec561c4-c5b0-102a-81c0-81bc30f92d57
If you want to link datas in a not too big Directory you can also use referential integrity, that the way users are linked to groups (when you move a user you don't have to look at each group it belongs to) in operating systems directories (RefInt Overlay in OpenLDAP).
We're migrating from Bugzilla to Redmine and there's one feature of bugzilla which I'm unsure how to replicate in Redmine.
Is there any way to list all the bugs / features of a specific priority across all projects?
We used to use this mechanism to identify what bugs / features to assign next to developers. If listing all urgent bugs doesn't work in Redmine, perhaps there's a different way of working which could be used instead?
This is easy:
Go to https://your.redmine.domain/issues?set_filter=1 : This should clear any current filter criteria and display all open issues across all projects the currently logged user has access to.
Select your filter - in this case, add a filter for Priority, and hit apply
You may save this filter by clicking on Save: This will allow you to access to this filter quickly without configuring it every time. You may also choose grouping criteria as well as the columns to display.
Does anyone know of some good resources related to setting up heirarchical user account systems? I'm currently setting one up and am struggling with some of the more complex logic (especially with determining permissions). I was hoping I might be able to find some resources to help me along.
Some Background:
I'm building a user account system for a web CMS that allows for a nested group hierarchy. Each group can be allowed/denied access to read, write, add, and delete (either explicitly for that group, or implicitly by one of its parents). As if that weren't complicated enough, the system also allows for users to be members of multiple groups. -- This is where I'm stuck. I've got everything set up, but I'm struggling with the actual logic for determining pemissions for a given user.
The manual for CakePHP has an excellent description of how Access Control Lists work.
http://book.cakephp.org/2.0/en/core-libraries/components/access-control-lists.html
Represent the permissions set for a given group as a bit mask. OR-ing the bit masks together will give you the resultant permission set.
Update for #Alex:
I wrote this answer 3 years ago, but I believe I was alluding to the following...
From the question
a nested group hierarchy. Each group can be allowed/denied access to
read, write, add, and delete (either explicitly for that group, or
implicitly by one of its parents). As if that weren't complicated
enough, the system also allows for users to be members of multiple
groups. -- This is where I'm stuck. I've got everything set up, but
I'm struggling with the actual logic for determining pemissions for a
given user.
Assign a bitmask matching the total permission set of a group (or role) in the system:
e.g. 00 (using two bits keeps it simple here!)
The first bit confers Permission A and the second Permission B.
Now say Group A confers the following permission set: 01.
... and say Group B confers the following permission set: 10.
To get the resultant permission set for a user in an arbitrary set of groups you could perform a logical OR on the permission set bit masks:
Permission set for Group A 01
Permission set for Group B 10 OR
----
Resultant permission set 11 (i.e. both permission A and B are conferred)
I do not know the details of the questioner's system, but the system outlined here could be augmented to achieve different group-composition behaviors using different logical operators.
Look at the permissions in the Andrew File System. It allows users to create and administer groups of their own, while selectively assigning admin rights and ACLs. You might find that many of the pesky details are already worked out for you in their model.
Edit: here's a better link to AFS documentation:
http://www.cs.cmu.edu/~help/afs/index.html
Here's the section on groups:
http://www.cs.cmu.edu/~help/afs/afs_groups.html
I've done exactly this before and its no trivial implementation. You're going to want to look at the SecurityPermission class.
[http://msdn.microsoft.com/en-us/library/system.security.permissions.securitypermission.aspx][1]
I have done this before by utilizing XML (which I'm not sure I'd do again) and storing that XML as permission list inside of SQL server in an XML column through a CLR stored proc. The XML would have an element called a "permission" and then the permission would actually be a ENUM inside of the code. Each permission was a new implementation of the SecurityPermission class (linked above) Users were tied to groups which were defined in SQL server and then as the user was added/removed to groups, the XML doc would get updated to reflect which groups they were apart of.
As soon as the user logged in, the users credentials would be loaded into the application store (session) and then would be accessed accordingly. When authorization needed to take place the XMl in the application store would be pulled down loaded into the SecurityPermission via the "FromXML" method. At that point I would use the following methods to determine if the user had permission:
Demand
Intersect
Union
IsUnrestricted
IsSubSetOf
etc., etc, etc.
At that point after performing the Demand I was able to determine if the caller had access according to how I implemented my security routines in the SecurityPermissions.
Again, this is leaving out a TON of detail, but this should get you going down the right path.
Take a look at this name space as well: [2]: http://msdn.microsoft.com/en-us/library/system.security.permissions.aspx "System.Security.Permissions"