On Wed, Sep 19, 2012 at 10:55 AM, Reto Bachmann-Gmür <r...@apache.org> wrote: > 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.
I agree with that ... > Imho, it would be much > cleaner if permission for a higher level functionality rather than for > those lower level library calls would be required. > But exactly when we start to introduce this higher level permissions we need to think about how to do it. This was also the reason for all my questions. I wanted to get a better feeling of what is possible/feasible. > Cheers, > Reto > On Sep 19, 2012 9:46 AM, "Bertrand Delacretaz" <bdelacre...@apache.org> >> 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. >> That might be very useful >> 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. >> let me give some additional use cases Case C: A user can upload its own vocabulary and use it for enhancing his content. However might not want other users to access his vocabulary. Case D: A user might want to use an EnhancementEngine that requires some authentication with an external service. Case E: A user might only be able to read/query a Vocabulary on the Entityhub. An other user might also be able to modify it (create/modify/delete entities). >> 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. True. This was also the reason why I created an own BundleList for authentication. To make it users not interested in (B) easier to skip this feature. best Rupert -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
