Development Tool: Pentaho 4.5 enterprise edition
I have one issue regarding roles and permission.
I have one dashboard(enterprise one), i have added three prompts say p1, p2 and p3. Data in p1 and p3 is coming directly from DB (i.e. they are not dependent on any other parameter) whereas p2 have dependency in p1. In short we are trying to achieve cascading thing in our prompt section.
firstly i signed in as joe having roles(Admin, Authenticated and ceo). I can do cascading easily.
Then i signed in as suzy (Authenticated and cto). I can see data in p1 and p3. However I am not able to see anything on p2.
As i am able to do cascading thing as joe (in short any user with Role Admin) not as suzy..
So suggest me any possible solution.. coz as per our requirement there will be some user those will have only Authenticated / cto role.. so the cascading should work for all user, not just for user with role Admin.
Try verifying the share option or permission of each content in p2. Are you able to find and see the original report (content) in p2? You can find it when you login as joe.
Related
I have a users and permissions matrix diagram and an interaction diagram that shows which type of user role can edit/add which user role (for example, an Admin can grant access for all the users in the system, a "Normal User" can't grant roles/access to any user).
The requirement is: "Develop all needed software documentation for developers. This is an output used by developers to start working on the features". This is given in the context where we have an web app and the developers need to start working on this user/permissions roles and understand how the functionalities are tied together for each type of user.
My question is, how can I do something like this? What kind of documentation, information is needed and are there any examples, anywhere? I did business requirements documents before, but not so technical and usually this is done together with an IT lead, but given this is a test I need to create some content on my own with my own assumptions.
Thanks!
I'm developing custom security scheme for web application based on Apache Jackrabbit. I've extended standard Jackrabbit security implementation for my needs, and so far it's working correctly. But, I'm having problems with multiple principals being assigned permissions on a node.
For example, user U is a member of group G. Groups G has no read permissions on a node, but user U has read permissions. What I mean by this is, group G has jcr:read privilege set to deny, and user U has jcr:read set to allow on a node.
Based on this, I would assume that user U would be able to read the node, even if he is a member of a group which is not allowed to read. However, the node does not show up for a user U (not expected), or for any other member of group G (expected).
Could somebody help me shed some light on this? Is my assumption correct, or does Jackrabbit calculate actual permissions differently? Or is this just an error in my security implementation?
From this article :
The list of access rights applicable for the subject is constructed from:
- the rights that you assign directly to the user account
- plus all rights assigned to any of the groups that the user belongs to
Means that, Jackrabbit take group privilege instead of user's privilege. You can read the entire article, it is good for JackRabbit secutiry.
OK, so it's a badly phrased question. But it's hard to explain in a single line.
I've tried to read the Shibboleth documentation and being a newbie got out of my depth fairly rapidly. I don't really want to spend days understanding it if an expert can take half a minute to say "no chance, that won't work".
I have many groups of users, lets say (for now) that groups are different companies.
What I'd like to do is only allow users to see some fields from other companies.
For example I'm Alice in Company A and I can see that Bob in Company B has an email address bob#b.com. He can see that I'm alice#a.com
However everyone else in Company B can see that Bob has a last name and a phone number etc.
And everyone else in Company A can see my details.
To make this more complicated, lets say that Bob and I become friends and decide we want to share our information then we create a "transient" group "alice&bob". Because we are both members of that group, we can both see each others full details. (But nobody else in A can see Bob's details unless they are also friends and vice versa)
I can sort all that out in application code by querying all attributes and relationships and only showing what's relevant but for extra security I'd like to limit the disclosure of information at source.
I think I need to use attribute filters but not sure if they are able to give me this level of control. With this flexibility of being able to form relationships, will I need to build filter files on the fly and then end up with thousands of filters that Shibboleth starts to choke on because the logic is so long.
Something like the "is requester in group" filter rule :
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeRequesterInEntityGroup
The answer above is quite good, but i believe that non shibboleth users will find it confusing.
The quick answer is You really don't want to do it this way, it may be possible to do but for 100% there are better tools to do it.
Ok, full version now (sorry for being too obvious i some places).
In shibboleth architecture we can distinguish two main components.
Identity Provider IdP- which holds information about users from specific organizations.
Service Provider SP - which are generally some service or protected resource, for which we can define some access rules
In your example credentials for Alice and Bob could be stored in different IdP, because they are member of different organizations/companies, or (which isn't exactly matching the whole pattern) you can have one IdP for all users, and "company" is just one of user attributes. IdP doesn't provide you any kind of api that will give you opportunity to access users attributes for any user, apart from the one that is being authenticated.
On the other hand you have your SP, which hold some super secret resources, for which you can define policies. And in which you would like to define polices for user information.
And here lays the problem, on SP side you don't have access to whole users database, that's the way Shibboleth works. You can of course treat all users information as a resource in your SP, but why in the hell would you like to use Shibboleth if you have clear access to all users credentials on you application side?
If you store all users information on you service side I believe that any well designed relational database with some kind of authentication for your service will be better than shibboleth for this job.
Hope that helped.
This is not a job for Shibboleth or for most SAML/SSO providers, for that matter. The attribute filtering you speak of is used for filtering those attributes between the IdP and SP ... which is basically saying : let service provider or "application" B see the following attributes from IdP A.
Once you transmit the attributes to the SP on the other end, Shibboleth does not (and indeed cannot) provide you with a mechanism to prevent users of application B from seeing any data that you present to them ... in fact, they really shouldnt be able to see any data transmitted by the IdP unless you are exposing it in someway via your application.
I have a Redmine installation and would like the ability to grant a user the ability to view (and maybe update) a single issue (not all issues in the project). The catch is that the issue is reported by someone else.
Use Case:
Users A,B, and admin C
admin C creates two bug reports 1 and 2
admin C wants to grant view access to user A on bug 1
admin C wants to grant view access to user B on bug 2
User A should not be able to access bug2
User B should not be able to access bug1
Can this be done with Redmine? I have been messing around with the settings, but I don't see an easy way to accomplish this use case.
If not, are there other bug trackers that do allow for such a use case?
You have at least a couple of more options.
Create a new role 'View Own Issues'. Give it issue visibility to just created or assigned issues, flag "Issues can be assigned to this role" and enable just "View issues" and "Add notes".
Then, you can assign each issue to the proper user.
The advantage with a private issue is that you can have a set of privileged users as Reporters that will still be able to inspect the issue, since it is still public.
The downside is that just one user can be assigned to the issue, therefore you have limited freedom.
Create a subproject that represents a visibility context and add members as needed. Move the issue to the subproject. You can still see the issue at the upper level, where assigned visibility is shown by the 'Project' field.
You cannot assign view permissions on single issues in redmine.
From the top of my head, you may use one of the following approaches in your scenario:
If you have only a limited number of users, you may be able to add different trackers (ACIssues and BCIssues), create two roles (AC and BC), associate user A and C with role AC, user B and C with role BC, and set permissions so that role AC has access to ACIssues, and role BC has access to BCIssues.
Private issues work the way you describe if issue 1 is assigned to user A, and issue 2 is assigned to user B.
I know the title is a little off, but it's hard to explain the problem in a short sentence.
I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".
Authorized licenseholders which does all setup themselves.
Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)
Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them.
This is also how we do support: we login as them and then follow them along, guiding them.
Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.
So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.
Any suggestions?
(The platform is classic ASP... I said it was legacy...)
Both options you present sound unattractive to me.
A master password is probably even more dangerous than what you are doing right now
Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.
I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).
How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)
What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:
logged_user - the actual user who typed in his/her username and password
impersonated user - the user (1) is acting on behalf of
Everything you do is done with the impersonated_user's permissions and preferences.
If you are not impersonating anyone impersonated_user=logged_user.
This way you have to always log any operation with both "actual" username and "impersonated" username; for example:
2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'
sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.
I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.