Hi Sergio,
> Stanbol is a a set of RESTful components for semantic content management. > Therefore, using it I'd expect whatever security it could be provided, > should be something optional on top of those components; i.e., enabling > security should not affect the behaviour. > What do you mean by not affecting the behaviour? Denying access to someone because they don't have the required permission is an effect on the behaviour. And what does it has to do with Stanbol aiming to be RESTful? If Stanbol didn't aim at being RESTful but would simply be a set of HTTP endpoints then one could argue that security could quite easily be provided at the level of an HTTP Proxy. But apart that this isn't so easy as the proxy has to be reconfigured for any change of the API or else services might be inaccessible or unprotected it would only allow for very course grained restrictions. Many services should just return more limited results depending on the access right of the user. The sparql enpoint might well be available but which graphs can actually be queried depends on the user making the request. > > I don't have much details how this aspect is being implemented. But what's > clear is it does affect the behaviour of the components, and how other > people are using Stanbol > What is clear is that it does unveil some bugs. Mostly bugs that are not shown by integration tests as there are no integrations tests accessing remote services. > > Therefore, I vote +1 to what Bertrand proposed, until the design of such > security mechanism is agreed and can be guaranteed would not affect the > internal behaviour, which in the end in the purpose of the project. > Again, what "internal behaviour"? Java code written without thinking about security does security relevant stuff. E.g. Accessing a file requires a particular permission. As stanbol components should be runnable in secured context (this includes application servers) they should not missbehave in this case. Unfortunately some of code does (see the mail regarding catching security exception I wrote an hour ago). If you think asking that this is fixed is a violation of the "internal behavioural freedom" of a component then the usability of Stanbol components is severly limited. Cheers, Reto > > Cheers, > > > > On 05/04/13 13:51, Rupert Westenthaler wrote: > >> Hi all, >> >> My viewpoint is as follows: >> >> * Disabling Security as default: Stanbol is still not functioning to >> 100% if the Security-Manager is enabled hence IMHO deactivating this >> feature is the logical consequence. >> >> * Enabling Security for IntegrationTests - because when you change >> things, than it is good to validate if it runs if an SecurityManager >> is present. Sometimes small changes do break security stuff (e.g. if a >> library that loads stuff via context classloader is imported from a >> different bundle the SecurityManager might say NO) ... meaning that >> even configuration changes might break code ... so having those things >> tested is important (unless we decide to not support SecurityManager >> stuff at all - like it is done my Solr, Tika ... but this was part of >> [1] and I accept the decision) >> >> To ensure that Stanbol is 100% working with the Security-Manager >> enabled is not only the question of fixing all those components. It >> will also require to test all those components during the >> integration-tests and as all those components depend on some external >> services this is not an easy thing to achieve. Because (1) this would >> also mean that failures of remote services would fail the >> integration-tests and (2) it will no longer allow to complete the >> integration-tests while offline. >> On the other side having not all component tested with active >> SecurityManager would make it very possible that some minor change >> (such as a version upgrade of a dependency) could break an component >> without noticed by the Developer nor the Jenkins build. >> >> To Summarize: As long as there are no solutions for those things I >> would really like to have security deactivated by default. This means >> that users that are not bordered with it will not run into problems >> they would not need to boarder with. Users that do need (use) the >> security features will run into those problems. Those users will also >> more likely understand those issues and report/patch them. >> >> WDYT >> Rupert >> >> p.s. >> On Fri, Apr 5, 2013 at 9:59 AM, Adrian Gschwend<ml-...@netlabs.org> >> wrote: >> >>> WTF >>> >> >> I hope the this stand for "Want To Fix" otherwise I would recommend to >> think twice before hitting the send button if the receiver includes a >> public mailing list ... >> >> >> >> -- >> | Rupert Westenthaler rupert.westentha...@gmail.com >> | Bodenlehenstraße 11 ++43-699-11108907 >> | A-5500 Bischofshofen >> > > -- > Sergio Fernández > Salzburg Research > +43 662 2288 318 > Jakob-Haringer Strasse 5/II > A-5020 Salzburg (Austria) > http://www.salzburgresearch.at >
