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