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!
Related
I have an application where users of my organization, who are not users of this application can register themselves in the first log. When they register, they can choose one or more app's profiles, like contract manager, supervisor etc. These profiles have specific authorization schemes per page, buttons, regions in app. The user must logoff and login again at the inicial log to see these menu's references
Do you know of any way that these menu's references could be viewed/activated in the first of all logs?
The oracle apex version is 5.1.4.
Regards.
I'm answering my own question as follows:
I do a self-criticism for the question because I consider it to have failed to take into account all aspects of information security. Even though I'm always careful about security, a solution of this kind might attend me, considering a IT's well secure work's scenario, but may not be the case for all environments.
I would consider this a valid question for security experts, who could see in the scenario that I proposed, a failure in the APEX environment, in which I have not yet seen.
I am trying to model some complex permission management system using apache shiro.
English not being my native tongue I am afraid I might be missing some of the subtleties of terms such as "Roles", "Permissions", "Rights" & "privileges".
For example lets say I want to create a system that manages resources such as printers located inside buildings.
A DB holds the information of which printer is located in what building.
Users of that system should be able to reset a printer or print to it.
Its clear to me that some users will be "Super Admins" and be able to reset and print to any printer ('printer:*:*')- I guess that we could say that those people have a "Super Admin Role".
But what if someone should be allowed to reset the printers in a specific building ('building:A:*') ? Is "Building Admin" a (prarametric) role? or is this just a permission on a specific building? How would you model this using apache Shiro?
n.b.
When tagging this Q I added the user-roles tag and it says:"A user role is a group of users that share the same privileges or permissions on a system. Use this tag for questions about how user roles work in a particular security framework, or questions about the implementation of user roles in your program."
Would I be correct to assume that based on this definition there is not such role as a "Building Admin" because being an Admin of Building A does not give you the same permissions as does being an Admin of building B?
and if so, what would be the correct terminology to describe a "Building admin"?
Have you considered using more than three tokens within the WildCardPermission format?
There is no limit to the number of tokens that can be used, so it is up to your imagination in terms of ways that this could be used in your application.
— WildCardPermission Javadoc
Instead of the domain:action:instance syntax commonly used in Apache Shiro examples and documentation, you could add another token to represent the building, e.g. printer:print,reset:*:buildingA.
The downside of this scheme is that whenever you are checking if an action is permitted on a particular printer, you'd now also have to specify the location, even though the token representing the printer instance might already uniquely identify that printer:
// let's say the role for buildingA-admin has permission of "printer:*:*:buildingA"
subject.isPermitted("printer:print:epson123:buildingA"); // returns true
subject.isPermitted("printer:print:epson123"); // returns false
Depending on your application domain, maybe a structure like buildingA:printer:print,reset:epson123 might even be more appropriate or useful.
To answer your other question regarding user roles, you'd be correct to assume that if you have both buildingA-admin and buildingB-admin roles, they are different user roles, if the permissions assigned to them are not the same.
You might conceive a general user role of Building Admin for permissions that all admins for the different buildings might have in common, to avoid duplicating those permissions across the different building-specific admin roles.
I'm just about finished with a solution built with ASP.NET MVC. Apart from a few bits and pieces, I only have security to do. I was wondering if there is some sort of starter code somewhere which I can build into my application (or build my current files into) which will do the following:
Subscription page for tenants (think they are called tenants, see note below), which will assign a administrator to the account.
A way to invite others to join and work on the tenant's data.
User groups and roles to limit what each of these other users can see/do.
Standard Login/forgot password pages
It doesn't need to handle billing, but if it does, it's an added bonus
My understanding of a tenant here is a person that signs up and then invite others to access their data. It is also be called vendor sometimes.
I'm sure there must be something out the box, because the above are features of most SaaS apps nowadays. I'm aware that I will need to add clauses to all existing queries to ensure that tenants don't see each other's data.
Any solutions that anyhow know of? Please let me know. Thank you
I m creating an application in which i have three roles.
(a) Admin
(b) Manager
(c) Supervisor
What i want is when user enter details on lo-gin page first system check whether user is whether its a valid user or not and then what kind of access he have. i think window authentication is good for this purpose now i want from you guys to tell how to should i go on this and can any one provide me a good article for it with example.
as i have create all my pages but i don't know how to communicate with database for it.
Thanks in advance..
You should take a look at the Membership Providers as these provide functionality for user authentication, and also at Role Providers that can provide functionality for managing user roles.
If you have any specific questions about how to go about implementing them, then please ask further questions here on stackoverflow.
A precursor: I've worked now in two enviroments with conflicting principals on this. I am outlining the competing ideas and would like to know which is 'correct' given the scenario described.
Scenario: Multiple applications exist on our intranet. We are implementing OpenSSO with LDAP as our authentication control and user directory. The issue comes to play is, with the LDAP authentication we know a user is allowed on the intranet but to which applications is questionable.
We intend to use LDAP to control what applications each user can access i.e. helpdesk, consultant review, report generator, survey creator etc.
The question arises in that, within each application are a significant amount of roles, and the fact that people may have multiple roles.
What is the best way to address this second area? Shoudl ALL roles be in the ldap or just the application allowances with each app database containing the more granular roles?
One approach is to use LDAP to maintain relatively high-level role information, but keep the very detailed application-specific information internal to each application.
For example, an individual might be members of LDAP groups (roles) like "employee", "help desk associate", "help desk supervisor", etc., and then the individual applications would map the high-level roles into the application-specific functions. A particular high-level role might imply access to multiple applications, and different roles would have different levels of access.
For example, a "help desk associate" might be able to create tickets, but maybe only a supervisor can delete them or run reports.
This is one of those areas where there's no one right answer. Centralizing everything in LDAP gives you better ability to report/audit individuals' access, at the cost of complicating your central LDAP schema with a lot of application-specific data. Also, depending on what existing/commercial applications you're trying to integrate, the applications may not support pulling all their fine-grained access information from LDAP.