I don't think that having standard java security calls (as they are present in standard java libraries like java.io means bloating the code. These can be usefull both in the situation were Stanbol is accessed via web as well as when it is embedded. Fo embedded stanbol what makes the difference is wether a SecurityManager is in place or not. Currently the engines require permissions like file access or networking permissions. It is not clear to the client what permissions a certain call requires. Imho, it would be much cleaner if permission for a higher level functionality rather than for those lower level library calls would be required.
Cheers, Reto On Sep 19, 2012 9:46 AM, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote: > On Tue, Sep 18, 2012 at 7:45 AM, Rupert Westenthaler > <rupert.westentha...@gmail.com> wrote: > > ...So your proposal is to introduce "Security" on the Component level.... > > It might be useful to agree on the overall Stanbol security model in a > wiki or website page before digging into the details. > > Case A: I don't care much about access control if using Stanbol as a > stateless content enhancement engine, as long as each request is > isolated from others I'm fine. I want a lean Stanbol in this case, > maybe even embed its bundles in my Sling or other OSGi-based > application. > > Case B: the picture is very different for someone who wants to use > Stanbol as a content store, where you might need granular access > control. You could easily turn Stanbol into a complex content > management system here, with the correspondingly complex security > features. > > IMO we need to define the possible security levels to cover the > spectrum of A to B, based on use cases, before (potentially) bloating > the Stanbol codebase with things that case A doesn't need. > > -Bertrand >
