Another use case which we should support somehow would be to replace the confirmations we have on bundle:start etc... using real permissions. That may also be linked to regions, where some users may only have rights to interact with the content of a subset of regions.
2012/1/30 Guillaume Nodet <gno...@gmail.com>: > One big use case I've seen is when you have a production environment > and you want to allow people to connect to *see* things, but obviously > not everybody to make changes. And such roles should not have to be > modified when you install new bundles. Which means commands have to > be assigned into one or more predefined roles, rather than having to > change the roles whenever you deploy a new set of commands. > > Also, as I already warned, unless we agree to consider those security > bits as not secured, but rather cosmetic, the first thing to do is to > have a way to disable reflection in the gogo shell. > > On top of this very simple read or read-write mechanism, we could then > have finer grained authorization, but authorization is really not the > same as authentication / roles. > And I'm not sure using jaas for such a fine grain authorization > mechanism is a good idea. > > Fwiw, I think you're right representing the commands in a tree, but > then we should have a layer to map part of this tree to known roles. > But I think having a read and read/write orthogonal concept is needed. > > I think we can combine both. If each command is annotated with a > @Read or @Write and have those mapped to a role and then having a > layer mapping command names / scopes and have part of this tree mapped > to required roles too. > > That would allow an easy mapping of (for example) > * all write operations require an admin role > * all config operations require a deployer role > ... > > 2012/1/30 Guillaume Nodet <gno...@gmail.com>: >> Then, we're talking more about authorization than roles, which makes >> sense to me. >> But we should not mix both. So what you're wiring is more command >> level authorization, but we should not use roles to explicit those. >> >> Defining a role per command is just not scalable and new commands >> won't be able to leverage them. I think we need a mechanism that can >> support coarse grained role definition and I don't think this goes in >> that way. >> >> I may have missed something in your explanation, but I don't really >> like the idea to have one role per command. >> >> 2012/1/30 Łukasz Dywicki <l...@code-house.org>: >>> Guillaume, >>> My goal is to provide fine grained access control. Not only a read or write >>> access but also domain specific, just imagine that you have a production >>> installation and developers have read only access to Apache Camel metrics, >>> JMS Queues and OSGi bundles but also have write access to configuration. >>> >>> These changes will let you to create real profiles. Currently we do not >>> have hierarchical roles which makes management of accounts harder. All >>> changes I made in webconsole is to let you create an hierarchy where dash >>> is level separator. >>> >>> With these changes we might have something like that: >>> + root >>> + osgi >>> - list >>> - install >>> + karaf >>> + admin >>> - list / stop / start / create / destroy >>> + feature >>> - list / stop / start / install / uninstall >>> + camel >>> + context >>> - list / start / stop etc. (whole path is camel-context-list) >>> + route (same operations like for context) >>> >>> With this separation you might assign a whole node (osgi) or only leaf >>> (osgi-list). I think that limiting access rights only to two - read and >>> write for container is really too little. We do not provide access >>> profiles, but we might consider that. Although I am sure this can be done >>> separately after introduction of fine grained roles. >>> >>> Best regards, >>> Łukasz Dywicki >>> -- >>> Code-House >>> http://code-house.org >>> >>> >>> Wiadomość napisana przez Guillaume Nodet w dniu 2012-01-30, o godz. 14:30: >>> >>>> As I explained, I'm not sure which use case you're trying to achieve, >>>> but that does not address the only use case I've heard about, which is >>>> to be able to have profiles that are read-only and profiles that have >>>> read-write access. >>>> >>>> 2012/1/30 Łukasz Dywicki <l...@code-house.org>: >>>>> Hey guys, >>>>> I am about to complete some changes in webconsole. >>>>> >>>>> Currently the schema is following. >>>>> To view list of bundles you need a osgi-list role. >>>>> To install bundle you need a osgi-install role assigned and so on. >>>>> >>>>> To execute all osgi related operations, read or write, you need a "osgi" >>>>> role. If you wish assign all karaf related roles you need karaf role. To >>>>> manage instances you need karaf-admin role (karaf-admin-list to view >>>>> instances, karaf-admin-stop to stop etc), or karaf-feature (and similar >>>>> karaf-feature-list, stop, start). Does it seems reasonable? Maybe we can >>>>> align these roles with 3.0 command naming schema? >>>>> >>>>> Best regards, >>>>> Łukasz Dywicki >>>>> -- >>>>> Code-House >>>>> http://code-house.org >>>>> >>>>> >>>>> Wiadomość napisana przez Andreas Pieber w dniu 2012-01-22, o godz. 11:28: >>>>> >>>>>> +1 that we try to include this/tackle this in 3.1 >>>>>> >>>>>> Kind regards, >>>>>> Andreas >>>>>> >>>>>> 2012/1/20 Jamie G. <jamie.goody...@gmail.com> >>>>>> >>>>>>> +1 to tackling this major feature in 3.1.x. >>>>>>> >>>>>>> Cheers, >>>>>>> Jamie >>>>>>> >>>>>>> 2012/1/20 Jean-Baptiste Onofré <j...@nanthrax.net>: >>>>>>>> Hi Lukasz, >>>>>>>> >>>>>>>> Agree to include it in Karaf 3.1.0. We live like this since a "long" >>>>>>> time, >>>>>>>> so no hurry. However, I consider it's a major enhancement that we have >>>>>>>> to >>>>>>>> address in Karaf 3.1.x as it's a must have for a fully enterprise >>>>>>> compliant >>>>>>>> container. >>>>>>>> >>>>>>>> I raised a Jira about that (as you mentionned, it's KARAF-1148). >>>>>>>> >>>>>>>> Regards >>>>>>>> JB >>>>>>>> >>>>>>>> >>>>>>>> On 01/19/2012 11:16 PM, Łukasz Dywicki wrote: >>>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> One topic we started discussing last time is a better control of >>>>>>> commands. >>>>>>>>> Currently any user who can log in the Karaf remote shell is able to >>>>>>> execute >>>>>>>>> all the commands. That obviously do not fit any security standards. To >>>>>>>>> introduce improvements we need take some steps who affects current >>>>>>>>> Karaf >>>>>>>>> codebase. Because need of 3.0 release I think we can introduce these >>>>>>>>> changes in version 3.1. Putting this stuff into 3.0 will only delay >>>>>>>>> everything. That will be also good ocasion to align security in shell, >>>>>>>>> mbeans and webconsole. >>>>>>>>> >>>>>>>>> Problems we have currently are following: >>>>>>>>> - We support only an admin role. Once you have admin role you can >>>>>>>>> access >>>>>>>>> everything. Without it you cannot access anything. >>>>>>>>> - JMX security layer specify only two types of access - Read or Read >>>>>>>>> Write. >>>>>>>>> - Some MBeans comes from external projects - eg. Camel or Aries, we >>>>>>>>> can >>>>>>>>> not force these projects to introduce Karaf dependencies into >>>>>>>>> libraries >>>>>>>>> core. >>>>>>>>> - Current shell security is really simple, it do not verify command >>>>>>>>> execution context, eg what resources are involved. >>>>>>>>> - We do not have any role OR permission naming schema. >>>>>>>>> - In some areas the security stuff can be in conflict with JAAS >>>>>>>>> modules, >>>>>>>>> by default policy files can control socket access without need to >>>>>>>>> assign >>>>>>>>> roles. >>>>>>>>> >>>>>>>>> That's only few concerns I have. Currently the issue KARAF-1148 >>>>>>>>> reflects >>>>>>>>> some points from this mail, but it's far from a solution proposal. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Łukasz Dywicki >>>>>>>>> -- >>>>>>>>> Code-House >>>>>>>>> http://code-house.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jean-Baptiste Onofré >>>>>>>> jbono...@apache.org >>>>>>>> http://blog.nanthrax.net >>>>>>>> Talend - http://www.talend.com >>>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> FuseSource, Integration everywhere >>>> http://fusesource.com >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> FuseSource, Integration everywhere >> http://fusesource.com > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
