On 2/17/11 7:53 PM, Michael Hollatz wrote:
> On 02/18/2011 12:59 AM, Richard S. Hall wrote:
>> On 2/17/11 5:27 PM, Michael Hollatz wrote:
>>> On 02/17/2011 04:09 PM, Richard S. Hall wrote:
>>>> On 2/16/11 18:56, PostMasteR wrote:
>>>>> I just took another look inside the spec and found the
>>>>> ServicePermission
>>>>> (Core R4.2 - 5.10.1) very useful, but I didn't see any mention of the
>>>>> reverse direction that I would like to use.
>>>>>
>>>>> The basic use case I have here is simply that I have some application
>>>>> modules which itself are split up into several bundles, e.g.:
>>>>>
>>>>> User module:
>>>>> * API
>>>>> * EJB impl
>>>>> * JPA impl
>>>>> * Client model
>>>>> * WebService
>>>>>
>>>>> 1.) only the EJB Impl is allowed to consume the service exported by the
>>>>> JPA impl bundle
>>>>> 2.) The JPA impl is not allowed to consume any of our application level
>>>>> services (of course, it is the lowest level)
>>>>> 3.) The WebService is only allowed to consume the service exported by
>>>>> the EJB impl bundle by using the interfaces from the API bundle and the
>>>>> client model implementation classes from the "Client model" bundle
>>>>>
>>>>> That are the basics that I would like to start with. I hope that such a
>>>>> setup doesn't sound too strange. :)
>>>> You should be able to use ServicePermission to grant bundles the right
>>>> (or deny the right) to only use services from bundles with a given
>>>> symbolic name or signed by a given bundle signer. I think this should do
>>>> what you want.
>>>>
>>>> For example, you could grant EJB Impl the right to consume services from
>>>> JPA Impl. As long as you grant it no other rights, then it can only see
>>>> services offered by JPA Impl (or you can limit it to specific service
>>>> types from the JPA Impl).
>>> Well, and that's the part what I would like to reverse. For example I
>>> would like to specify inside bundle "JPA Impl" that only the
>>> corresponding "EJB Impl" (maybe based on the bundles symbolic name) may
>>> consume the service it exports. So exactly the other way round the
>>> specification does.
>>>
>>> This is more or less an idea to enforce some design/architectural
>>> considerations and to prevent any third-party implementation to break it
>>> just because it has specified some additional permission by itself.
>> You can't have a bundle specify what permissions can be granted to
>> another bundle. First, permissions are generally a management decision,
>> not a developer decision. From a design point of view, this would also
>> make the bundles difficult to reuse in different scenarios.
> Well, I completely agree here.
>
>> You should define a security policy that enforces your architectural
>> considerations. If you use bundle signing, you can use local permissions
>> in the EJB impl bundle to make sure it is never granted more than
>> permission to get the JPA Impl service (local permissions define the
>> maximal set of permissions a bundle may receive, but it is in the bundle
>> itself since it is also a form of permission auditing).
>>
>> From your words above ("because it has specified some additional
>> permission by itself") seems to imply some misunderstanding about how
>> permissions are assigned. Bundles do not assign permissions to
>> themselves. Local permissions can say what a bundle wishes to receive,
>> but that is all. The security policy defined by the management agent
>> specifies which permissions bundles actually get.
> Hm, somehow I assumed that bundles can contain their own "policy file"
> which would be merged with the global one using the permission admin
> service. But reading the spec again they only cover local permissions as
> you already mentioned.'
Yep. Local permissions are like a wish list for the bundle, but it might
not get everything it asks for depending on the security policy, but it
will never get more than what it asks for which is enforced by the
framework.
>> All that being said, though, you could implement your own security
>> policy bundle that used the extender pattern to probe bundles that
>> contain permission policies, then you could probably do something like
>> what you want. However, I'm not sure it is a good idea.
> OK, what I'm looking for is more or less something like a dynamic
> firewall, just opening and closing ports on demand and specify, which
> sources are allowed to access them. So if I deploy a bundle containing a
> service implementation I want to register that service and additionally
> grant permission(s) to use this service (the basic permission policy
> should be rather basic and not get too complex) using the permission
> admin service.
Right, treat the services as your ports and the specifically define
which bundles can access them.
> Well, using the extender model I really could implement for what I'm
> looking for.
>
> And although I agree on the design part, in OSGi from a bundles point of
> view all available services are at the same level, but not from the
> application point of view. The semantic and architecture is not
> reflected by that. So I thought that the kind of permissions I am
> looking for is the best thing I can do to prevent things like unwanted
> cross-component communication and by-passing the business logic layer of
> a component by directly accessing its persistence service.
Yes, this is true, although you can use service registry hooks to hide
services from bundles too. There is some work in the area inside the
OSGi Alliance around subsystems. Also, iPOJO provides a composite
component concept which lets you model architectural issues like you
describe.
-> richard