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
