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.
>
> 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.
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.
>
> -> richard
>