I know that we have groups and roles but I cant figure out how to separate users from projects. So I want to make projectA visible for DeveloperA and projectB for DeveloperB.
Maybe some tutorial on how to do this? Thanks for any help
Have a look at the JIRA project level security documentation.
Or if you want to drill down to issue level, that information is here.
Use (or create) a project role, e.g. Developers
In Project A add Dev A to the role.
In Project B add Dev B to the same role.
In the permission scheme used by both projects grant the Browse Projects permission to the Developers role (not a group)
That's it!
The key is to decide how you want to manage permissions; by roles typically allows more control whereas by group typically involves less overhead to manage (roles have to be specified per project). If you are unclear on how to set a permission scheme up look here: https://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions.
Depending on how many users/groups/roles you are trying to manage, you can also assign permission to individual users.
Hope that helps.
Unfortunately JIRA is really poorly setup to support project by project visibility. Is it possible? Without a doubt. Does it take a lot of unnecessary setup? Most definitely. These two comments found in JIRA's own documentation alludes to the amount of setup involved:
"in order to accomplish a security configuration which fits your company exactly, it will require a good amount of time, effort, and imagination on your part"
"there is no way to automatically assign users to certain groups without massive customizations to the JIRA environment"
Ok, now that you know there's going to be some work involved, your focus should be centered around creating groups and setting up permission schemes -- both of which you'll have to do for each project or logical grouping of users based on a specific client, division, department, internal, etc. Here is some specific JIRA documentation on getting that setup:
https://confluence.atlassian.com/display/JIRA051/Using+Project+Level+Security+with+User+Groups
Related
We recently had a duplication in uploaded records to one of our REDCap projects totaling about 3,800 files that now need to be removed. Currently it is taking a team of three about 30 seconds per record to delete due to the size of the project and traffic in REDCap. I have not found any solution to delete multiple records at once from Vanderbilt or the other university resources I typically use. I was wondering if others have found a work around?
There is an API method for deleting records, so that would be your best bet for batch deletion. The details, with examples for different languages, are in the API and API playground applications in the project sidebar. You must have an API token generated, and your admin might have to approve that before you can use the API. It also inherits your privileges on the project, so you need to have the privilege to delete records in the User Rights application.
Another method that might be easier and cleaner would be to ditch this particular project and copy the project without its records, then perform the import on the new, empty project.
Consider REDCapR::redcap_delete() if you're using R, or PyCap's delete_records() if you're using Python.
Packages for other languages are listed in REDCap Tools.
I'm trying to implement a claims-based authorization setup using Web API/OWIN/OAuth and I'm trying to find out the best way to manage a more fine-grained type of authorization.
I don't like the idea of using just roles, as there needs to be lots of fine-grained authorization in the application I'm working on. I was thinking a roles+permissions approach made more sense (where a role simply maps to a subset of permissions). The permissions would be based on an action+resource pair (e.g. CanViewEmployee, CanEditEmployee, etc.). Nothing out of the ordinary here.
However, I'm wondering how this should be implemented using OWIN/OAuth, possibly using Thinktecture IdentityServer. I am trying to avoid hard coding the permissions in the custom AuthorizationManager I have as they need to be easily changed without a rebuild. I know it is an option to put these as policies in the web.config (mapping a resource+action to a claim type and value), but if we are talking about dozens, maybe even hundreds of permissions, this seems like it could get out of hand pretty quickly as well.
I guess the third option would be to drive it all from the database, but managing it from there would also need some kind of front-end to do so, which is more effort than just changing a config/XML file.
Am I missing some other options/best practices here when it comes to large numbers of claims/permissions, or perhaps some other utility or package I could use to help manage this when the numbers get out of hand?
Decoupling these permissions into a separate authorization manager class is a good first step. In that code you could then hard code the rules for your permissions (such as "Admin" role can do action X, Y and Z, but only "Manager" role can do X or Y). But you can also have the code in the authorization manager perform dynamic look ups to check permissions that have been set in in a database (for example).
The additional benefit of doing this in code is that you can unit test it all to prove your permissions logic is implemented correctly (and thus will be properly enforced at runtime). This will be useful if your permissions do change frequently.
Also, the decoupling will help if you need to redeploy frequently (because of the frequent changes), since the code can be isolated into its own assembly.
Example:
I added new Marketing spot on some JSP page. I need to change JSP and create this spot in management center. Changes in JSP are shared through CVS, but what about Marketing Spot? It is stored somewhere in database, but I could not find solution to export this content properly neither with WCBD tool nor manually. What would you do in this case?
Thanks.
You have three options:
Manually re-create the requisite spot configuration in the other database.
Use a shared database for the development team. It is not as bad as it sounds, I have had my team use it in the past.
Use the export/import functionality. This is not recommended as the time you will spend trying to analyze all tables and dependencies may not be worth it.
Are you trying to share across development instances? A shared dev instance is a good option as mentioned above. Also taking advantage of stageprop and staging copy could be a good answer. A quick trip to infocenter shows:
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/refs/rsscopy.htm
If you use the merchant table option it will copy changes to a store. Using this utility may require turning on stage logging in the staglog table.
More on that here:
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.admin.doc/concepts/csstagingserver.htm
I'm working on a project that needs to have flexible authorization. What I mean by that is this:
My users will be divided in to client groups, so each client could have many users.
Each user needs to be able to have different roles, but the definitions of these roles needs to be able to be set on a per client basis, and ideally in a way that, say, a user with an ultra_admin role would be able to edit the roles for her client group.
I've looked in to the following:
CanCan
Declarative Auth
acl9
and a handful of others, and I can't see a way to do this in them, although I think it's probably possible in acl9 it doesn't look like it's what it was designed for.
Is there an existing authorization gem that makes this easy? Is there a reason that this isn't out there (i.e. am I missing an obvious solution that is simpler)? If it's possible with one of the above gems is there an example anywhere?
I couldn't find anything like this either, and so I rolled my own.
https://github.com/PRX/badges
I'm working on an update, and rename, which will work very much the same way and be out soon, but this version on github we use in production.
We're building an application designed to run on Windows-based servers. One of the considerations we're looking into at the moment is how to control access to the application's GUI, which allows configuration and controls the "back end" services.
In order to secure the application properly, there are several objects which will need ACLs to be applied - files, directories, Registry keys, named pipes, services etc. We need to provide administrators with some way to configure those ACLs in order to limit access to authorized users only.
One approach we have considered is to create a tool which can modify the ACLs on all those objects simultaneously, but that would be a fair chunk of work and could be fragile.
The other possible approach we're looking at is to create a custom group (e.g. "My App Users") so we can give that group the appropriate rights to each object. This means that administrators will be able to add/remove authorized users by using familiar Windows group membership tools.
So: is creating groups at install time an acceptable thing to do, or is it likely to upset administrators? I'm more familiar with the UNIX world, to be honest, where server-based apps are more or less expected to create groups, but I'm uncertain of the etiquette in the Windows ecosystem.
Also: is there a better solution to this that I've missed?
Thanks in advance!
The question is twofold - one technical, and one political. Technically a local group is fine, you can add AD or domain users into a local group and everyone's happy. In terms of whether an app should be messing with a server's security 'stance', the only reasonable answer is to pop up some kind of request telling the user what you are going to do and asking permission (make sure you also document the decision in some kind of log or entry). This also addresses everybody's legal a$$ eg if they click "no, leave my app unsecured" and get hacked).
Taking a UNIX approach, you could tell the user what you need, suggest a local group (and give the user the chance to pick another local or domain/AD group). Take a look at how (eg) Oracle installs on UNIX do it.
Since this is a server app and you might have to support silent/unattended install, make sure that the behavior can be specified in the install script and very, very sure that the behavior of the script is documented so that no one installs the program without realizing the change in security policy that the installer implements.
I think it's perfectly fine to create a local group for this purpose.
Furthermore I have not been able to come up with a better solution after giving it some thought.
Depending on the size of the implementation, groups could be the way to go.
But please keep in mind that the relevant ACLs on directories and the registry ought to be set. I do agree that setting them once to the group and then let access control be maintained by group memberships.
In regards to klausbyskov's answer, I think a local group could be fine, but consider using LDAP instead. From a security perspective you would detach the authentification process and let the Directory handle it; using kerberos.