Ok, thank you Karl. Since permissions will be added by a specific bundle (I'm gonna call it: the "policy" bundle), I wonder what's happen if others bundles are installed before? Permissions will not be checked for them?
I imagine a case where I add conditions to have only signed bundles in my application. To remove permissions is quite easy so? Just remove the policy bundle from application... :-/ Do I miss something? Regards, Anthony -----Original Message----- From: Karl Pauls [mailto:[email protected]] Sent: vendredi 25 février 2011 17:32 To: [email protected] Subject: Re: Felix security pretty much, yes. It will be ConditionInfo and PermissionInfo tuples but yes, you need to get them into the CPA. That said, if you look at folder chapter14 of the book examples there is a bundle that reads in a policy file and does the work of putting it into the cpa for you. regards, Karl On Fri, Feb 25, 2011 at 5:18 PM, Muller, Anthony <[email protected]> wrote: > Just to be sure, I have to write a specific bundle which will define > permission in this start() method by adding *PermissionInfo instances to > ConditionalPermissionAdmin, right? > > Thanks, > Anthony > > > -----Original Message----- > From: Karl Pauls [mailto:[email protected]] > Sent: vendredi 25 février 2011 15:09 > To: [email protected] > Subject: Re: Felix security > > Yes, however, you need to enable security for the complete application > but you can give allpermission to everything on the outside (including > the felix framework), start felix and install the framework.security > bundle. From that point on you can use the conditional permission > admin to limit the permissions of the bundles that are running inside > of felix. > > regards, > > Karl > > On Fri, Feb 25, 2011 at 2:01 PM, Muller, Anthony <[email protected]> > wrote: >> One more questions about this subject: is it possible to enable security >> when Felix framework is embedded? >> >> Anthony >> >> -----Original Message----- >> From: Muller, Anthony [mailto:[email protected]] >> Sent: vendredi 25 février 2011 13:49 >> To: [email protected] >> Subject: RE: Felix security >> >> Thanks I'm going to look to these very interesting information. The book you >> wrote seems perfect for me. >> >> If you have other pieces of information/tutorial/sample, don't hesitate to >> share please! >> >> Regards, >> Anthony >> >> >> -----Original Message----- >> From: Karl Pauls [mailto:[email protected]] >> Sent: vendredi 25 février 2011 11:29 >> To: [email protected] >> Cc: Muller, Anthony >> Subject: Re: Felix security >> >> Hi Anthony, >> >> yes, what you want to do is possible and OSGi provides what you need. >> You might want to have a look at the ConditionalPermissionAdmin >> Service. A (somewhat outdated but still relevant) starting point to >> OSGi and Java Security could be: >> >> http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications.pdf >> >> we have a page on the security provider for felix (needs some updating >> but mostly to say that the framework.security provider is released by >> now): >> >> https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Framework+Security >> >> and last but not least, the upcoming OSGi in Action book has a full >> chapter on OSGi and Java Security - you could get it from the early >> access at manning.com (full disclosure: I'm one of the authors). The >> code examples of that chapter are available at: >> >> http://code.google.com/p/osgi-in-action/ >> >> regards, >> >> Karl >> >> On Fri, Feb 25, 2011 at 11:18 AM, Muller, Anthony >> <[email protected]> wrote: >>> Hello, >>> >>> I'd like to get information about how to secure an osgi application based >>> on Felix. >>> >>> 1) The main idea would be that only signed bundles could be deployed into >>> the application. But I have no idea if it's possible and how to do that.... >>> >>> 2) Another question: is it possible to add some restrictions to some >>> bundles (like a bundle cannot create a new thread) ? >>> >>> Thanks and regards, >>> Anthony >>> >> >> >> >> -- >> Karl Pauls >> [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Karl Pauls > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
