I agree that we need to improve privilege-handling, but I don't agree that the best approach is to disable/bypass all API privilege checking.
Are you suggesting that re-create a duplicate application-level privilege for Managing Concepts and bypass the existing privilege for manage concepts? Should anyone using the application be able edit users if they can find the right URL that lacks the application-level privilege checking? I 100% agree with improving permission handling to make things more manageable, but I don't agree with wholesale bypassing of API privileges any more than I would propose solving a Tomcat permissions problem by running it as root. API privilege checking is there for a reason. And, while there are many cases where application-level privileges are needed/justified, there are many cases where separate application-level privileges would only be redundant. Making the changes planned in the sprint, providing an easy mechanism for granting all of the "Get" privileges (e.g., an out-of-the-box role), creating some conventions for handling application-level permissions, and having improved tools for troubleshooting privilege problems should go a long way in improving the situation without having to completely disable any API-level security. -Burke On Fri, May 18, 2012 at 11:52 AM, Mark Goodrich <mgoodr...@pih.org> wrote: > +1 for this. We also could provide a little bit of granularity by also > creating a role where every read-only API privilege check passes. > > > > ________________________________________ > From: dev@openmrs.org [dev@openmrs.org] On Behalf Of Michael Seaton [ > msea...@pih.org] > Sent: Friday, May 18, 2012 11:27 AM > To: openmrs-deve...@listserv.iupui.edu > Subject: Re: [OPENMRS-DEV] Roles and Privileges > > In this vein, here is a use-case I would like to suggest, based on many of > the great suggestions I've heard: > > * Create 2 types of privileges - API-level and Application-level > * Provide a "System Developer"-like role in which every API-level > privilege check always passes, but which Application-level privileges need > to be set > * Re-factor our Web Application to refer only to Application-level > privileges > > This would allow for implementations, if they chose, to effectively turn > off API-level privileges, but to still restrict the types of activities > that users could perform within the EMR application. We can debate around > the merits of turning off API-level privileges, and whether or not they are > necessary, but this step would go a long way to have OpenMRS "get out of > the way" until better management of API-level privileges is supported. > > I think the above could be done within a Sprint pretty easily, and modules > that currently do API-privilege checking would not be impacted, but could > migrate over to the Application-privilege checking when appropriate > > > ________________________________________ > From: dev@openmrs.org [dev@openmrs.org] On Behalf Of Mark Goodrich [ > mgoodr...@pih.org] > Sent: Friday, May 18, 2012 10:49 AM > To: openmrs-deve...@listserv.iupui.edu > Subject: [OPENMRS-DEV] Roles and Privileges > > Yesterday I ran into a real-life roles and privileges problem very similar > to the example problem I gave a week or two ago. Sine this the roles and > privileges sprint is upcoming, I figured I'd mention it here... I think > we've already got these issues covered, but wanted to reiterate since it is > a good "real-life" example. > > In the Provider Management module, the Provider Dashboard lists all of the > patients associated with a Provider. However, in the functional specs for > Provider Management, there is a requirement to have a role for users who > are able to manage providers but aren't able to view patient data. For > this role, the patients associated with a provider should not be displayed, > but, instead, the dashboard should show the number of patients that a > provider has. But, in order for the Provider Management API to calculate > this information, this role would need to have the "View Patients" > privilege, or, at least, "View Relationships" privilege. > > As was suggested earlier, one solution would be to give the user the > appropriate proxy privilege to do this calculation, but that seems like a > bad solution. > > I'd actually be fine with giving this role access to the getPatients and > getRelationships API method, as long as there was a way to do that without > giving them access to patient information via the web layer. It seems > critical to me that API-level and UI-level privileges be separated out. We > have LOTS of privileges in attempt to allow for fine-grained access > control, but those privileges are not always "grained" in a useful way. > > Actually, from a web application level, I don't think that API-level > privileges are particularly useful, except last-resort defense in the case > that UI privileges aren't properly set up. (However, I realize that they > would be critical when using a web services access model.) In fact, if I > thought that the OpenMRS web-level privileges were well enough defined, I'd > almost consider having an option/role that allows me to give a user all > API-level privileges when they access OpenMRS through the web app. > > I just set up privileges for the Provider Management module yesterday, and > what I did was define a set of UI-level privileges that I use to > hide/display certain sections of the provider dashboard. Then I created > two separate, coarse-grained API privilegs: "Provider Management API" and > "Provider Management API - Read-only" which I think should be sufficient > for my use case. > > It might be valuable to have a way to group privileges... say like a > "Patient Service API privilege group"? Of course you could do this via a > role, but a "Patient Service API" role doesn't seem to be the way role was > intended to be used. > > And finally, a big +1 for creating a module that records privilege checks > to faciliate administration. Yesterday I had to use a trial-and-error > approach to figure out exactly what privileges were required to access > certain parts of the Provider Management site so that i could define roles > appropriately. > > Take care, > Mark > > > > > ________________________________ > Click here to > unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l> > from OpenMRS Developers' mailing list > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l] > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l] > > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
