You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Reto Bachmann-Gmür <re...@apache.org> on 2012/11/28 14:51:49 UTC
Enabling security be default
Hi all,
Currently stanbol security is only enabled when stanbol is started with the
-s option. I think it would be better to start it with security enabled by
default. This follows the "priciple of least damage" as the harm caused
when a "disable security" option is forgotten is much smaller than the
potential damage when arbitrary users can suddenly act with all privileges.
Any objection to such a change?
Reto
Re: Enabling security be default
Posted by Andreas Kuckartz <A....@ping.de>.
While I did not look at the details of this concrete question I am
definitely in favor of security by default:
https://en.wikipedia.org/wiki/Secure_by_default
It is one reason why I dislike PHP compared to Java.
Cheers,
Andreas
---
Reto Bachmann-Gmür:
> Hi all,
>
> Currently stanbol security is only enabled when stanbol is started with the
> -s option. I think it would be better to start it with security enabled by
> default. This follows the "priciple of least damage" as the harm caused
> when a "disable security" option is forgotten is much smaller than the
> potential damage when arbitrary users can suddenly act with all privileges.
>
> Any objection to such a change?
>
> Reto
Re: Enabling security be default
Posted by Sergio Fernández <se...@salzburgresearch.at>.
-1
On 28/11/12 14:51, Reto Bachmann-Gmür wrote:
> Hi all,
>
> Currently stanbol security is only enabled when stanbol is started with the
> -s option. I think it would be better to start it with security enabled by
> default. This follows the "priciple of least damage" as the harm caused
> when a "disable security" option is forgotten is much smaller than the
> potential damage when arbitrary users can suddenly act with all privileges.
>
> Any objection to such a change?
>
> Reto
>
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Bertrand Delacretaz <bd...@apache.org>
> On Wed, Nov 28, 2012 at 4:09 PM, Adrian Gschwend <ml...@netlabs.org>
> wrote:
> > ...- which is related to the reason why Reto adds it: In professional
> > environments we need multi-tenancy, for having more than one tenant you
> > need some kind of security...
>
> That's *your* use case - as I explained mine differs.
>
> Multi-tenant Stanbol looks to me like a different product than the
> plain stateless engine that I and others consider, in which case a
> separate launcher might be more appropriate for the multi tenant
> variant, with a slightly different set of bundles and configs that
> enables security by default.
>
Bertrand was faster than myself - so I just have to agree with him.
What about creating another launcher configuration that has has security
enabled by default? Enabling something in Stanbol means that it is in some
launcher configuration. We are used to call the full-launcher the default
one but it was never defined to be something like default.
We could also have another Jenkins instance that could execute integration
tests against other launchers if we think it is necessary.
Best,
- Fabian
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 28, 2012 at 5:37 PM, Fabian Christ
<ch...@googlemail.com> wrote:
> ...such things have to be discussed with the whole Stanbol community.
> Until now we only know that people are interested in multi-tenancy but we
> have not decided how to achieve it within Stanbol. At least I do not know
> of any concrete plans....
Fully agreed - it looks like we need requirements/specs for that
Stanbol multitenancy and security means, unless I missed something I
don't see this anywhere.
-Bertrand
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Adrian Gschwend <ml...@netlabs.org>
> I started this discussion in July this year, thread where I first
> mentioned it was called "Stanbol architecture questions".
>
> We use this for the www.fusepool.eu project where Stanbol will play an
> important role. The work Reto did on security was the first step for
> tenants so that's why I am pushing it.
>
Yes I remember that and the work done by Reto is really appreciated. It is
nice to hear that a project uses Stanbol like this.
Anyway, such things have to be discussed with the whole Stanbol community.
Until now we only know that people are interested in multi-tenancy but we
have not decided how to achieve it within Stanbol. At least I do not know
of any concrete plans.
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Adrian Gschwend <ml...@netlabs.org>.
On 28.11.12 16:28, Fabian Christ wrote:
> It sounds like you already know how to make Stanbol multi-tenant. Maybe I
> missed something but I can not remember a discussion about that. Having
> multi-tenant would be nice but maybe there are several ways to achieve it.
> Something for another thread.
I started this discussion in July this year, thread where I first
mentioned it was called "Stanbol architecture questions".
We use this for the www.fusepool.eu project where Stanbol will play an
important role. The work Reto did on security was the first step for
tenants so that's why I am pushing it.
cu
Adrian
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Adrian Gschwend <ml...@netlabs.org>
> ok but that doesn't invalidate my remarks that people will care less if
> it's not on. In that case the question is if we have a fork with a
> different goal or "just" a multi-tenant stanbol.
>
It sounds like you already know how to make Stanbol multi-tenant. Maybe I
missed something but I can not remember a discussion about that. Having
multi-tenant would be nice but maybe there are several ways to achieve it.
Something for another thread.
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Adrian Gschwend <ml...@netlabs.org>.
On 28.11.12 16:18, Bertrand Delacretaz wrote:
> That's *your* use case - as I explained mine differs.
ok but that doesn't invalidate my remarks that people will care less if
it's not on. In that case the question is if we have a fork with a
different goal or "just" a multi-tenant stanbol.
cu
Adrian
Re: Enabling security be default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 28, 2012 at 4:09 PM, Adrian Gschwend <ml...@netlabs.org> wrote:
> ...- which is related to the reason why Reto adds it: In professional
> environments we need multi-tenancy, for having more than one tenant you
> need some kind of security...
That's *your* use case - as I explained mine differs.
Multi-tenant Stanbol looks to me like a different product than the
plain stateless engine that I and others consider, in which case a
separate launcher might be more appropriate for the multi tenant
variant, with a slightly different set of bundles and configs that
enables security by default.
-Bertrand
Re: Enabling security be default
Posted by Adrian Gschwend <ml...@netlabs.org>.
On 28.11.12 15:50, Fabian Christ wrote:
> Are you seriously trying to take part in this discussion with such a
> statement?
Well I spent several years of my life earning money with discovering bad
security practices in big company networks (which payed for that for
sure) so you kind of hit the bottom with your "If people want security
they have to do something for it" statement.
I had to take care of compromised systems in University networks where
people didn't care about doing more than the default because they didn't
want to read any documentation. Most of the time owning a company
network starts with owning a small system no one considered as important
enough to "do something for security". If we meet on another workshop I
can tell you some nice stories about that.
So I am for enabling it because:
- it forces all (code) contributors to think of it from day one, if they
never enable it they most probably don't care as long as they don't have
a need for it. So the enhancers/modules will not work properly in
security mode
- which is related to the reason why Reto adds it: In professional
environments we need multi-tenancy, for having more than one tenant you
need some kind of security. Which brings us back to point 1: if it's not
enabled by default programmers might just ignore that because it's some
extra work for them and thus the module is not properly supporting multi
tennancy
- I use lots of frameworks and while I agree that many do not enable it
I think it's the wrong way to go because you *should* think of that from
day one, even if it just means "Welcome to Stanbol, please enter a
(non-trivial) default password for administration to continue".
Little example: I use Fuseki in my setup and I have a really bad feeling
about it because I couldn't find anything about securing it so far.
cu
Adrian
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Adrian Gschwend <ml...@netlabs.org>
> > I would prefer to keep the default really simple. If people want security
> > they have to do something for it. This is true for most systems and
> > frameworks that I know about.
>
> That is wrong on so many levels.
Are you seriously trying to take part in this discussion with such a
statement?
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 28, 2012 at 3:38 PM, Adrian Gschwend <ml...@netlabs.org> wrote:
> ...That is wrong on so many levels...
Looks like your use cases for Stanbol do not match those of people
like me who disagree with Reto's proposal.
Explaining your use cases and requirements might help us understand -
I remember discussions about making Stanbol multi-tenant, I assume
that's related.
-Bertrand
Re: Enabling security be default
Posted by Adrian Gschwend <ml...@netlabs.org>.
On 28.11.12 15:09, Fabian Christ wrote:
> I would prefer to keep the default really simple. If people want security
> they have to do something for it. This is true for most systems and
> frameworks that I know about.
That is wrong on so many levels.
cu
Adrian
Re: Enabling security be default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 30, 2012 at 10:37 AM, Fabian Christ
<ch...@googlemail.com> wrote:
> 2012/11/30 Reto Bachmann-Gmür <re...@wymiwyg.com>
>
>> Where do you think would this infos best fit in?
>
> Maybe we could start with a usage scenario and link from there to any
> further readings.
>
> http://stanbol.apache.org/docs/trunk/scenarios.html
IMO, starting with usage scenarios and how-to instructions in jira
issues can also be good enough, at least initially.
Currently, searching for "security" at
https://issues.apache.org/jira/browse/STANBOL doesn't return anything
relevant to what's being discussed here, unless I missed something.
That's a bad signal in my book.
-Bertrand
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
to sum up the discussion:
We agreed to activate the security features by default in the full
launcher. Integration tests are executed using the full launcher.
As a remark: Having something activated/deactivated is always a matter of
launcher configurations in Stanbol. Other launchers may not use security by
default.
Best,
- Fabian
2012/11/30 Fabian Christ <ch...@googlemail.com>
> 2012/11/30 Reto Bachmann-Gmür <re...@wymiwyg.com>
>
>> Where do you think would this infos best fit in?
>
>
> Maybe we could start with a usage scenario and link from there to any
> further readings.
>
> http://stanbol.apache.org/docs/trunk/scenarios.html
>
> In a next step we may a have a top level folder for security
> documentation. Like we have one for components.
>
> Just a suggestion.
>
> --
> Fabian
> http://twitter.com/fctwitt
>
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/30 Reto Bachmann-Gmür <re...@wymiwyg.com>
> Where do you think would this infos best fit in?
Maybe we could start with a usage scenario and link from there to any
further readings.
http://stanbol.apache.org/docs/trunk/scenarios.html
In a next step we may a have a top level folder for security documentation.
Like we have one for components.
Just a suggestion.
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Fri, Nov 30, 2012 at 10:23 AM, Fabian Christ <
christ.fabian@googlemail.com> wrote:
> 2012/11/30 Reto Bachmann-Gmür <re...@wymiwyg.com>
>
> > but it would be useful to have the bits of
> > information developers need to know on the wiki.
> >
>
> To what "wiki" are you referring?
>
> At the moment Stanbol has its website for all docs.
>
You're right :)
Where do you think would this infos best fit in?
Reto
>
> --
> Fabian
> http://twitter.com/fctwitt
>
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/30 Reto Bachmann-Gmür <re...@wymiwyg.com>
> but it would be useful to have the bits of
> information developers need to know on the wiki.
>
To what "wiki" are you referring?
At the moment Stanbol has its website for all docs.
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Fri, Nov 30, 2012 at 10:11 AM, Fabian Christ <
christ.fabian@googlemail.com> wrote:
> 2012/11/30 Reto Bachmann-Gmür <re...@apache.org>
>
> > 3. Basically module developer need to know nothing Stanbol specific. I
> > summarized the most important java security bits on
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-stanbol-dev/201209.mbox/%3CCALvhUEUsmJ3CiDQ28pF9_TE67jcVdX48jRPg1EQLqxSOyG3C6w@mail.gmail.com%3E
> > .
> > Should I place this on the wiki?
> >
>
> +1 for documenting this on our website if it is already implemented.
>
I think the website should document the configurations of users and roles.
This shall be done as soon as the next version of the user manager is
ready. With the current version you cannot do much more than setting the
admin's password.
As for the developer documentation I don't think this belong to the website
as this is just standard java. We don't document other java standard
libraries on the website but it would be useful to have the bits of
information developers need to know on the wiki.
Cheers,
Reto
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/30 Reto Bachmann-Gmür <re...@apache.org>
> 3. Basically module developer need to know nothing Stanbol specific. I
> summarized the most important java security bits on
>
> http://mail-archives.apache.org/mod_mbox/incubator-stanbol-dev/201209.mbox/%3CCALvhUEUsmJ3CiDQ28pF9_TE67jcVdX48jRPg1EQLqxSOyG3C6w@mail.gmail.com%3E
> .
> Should I place this on the wiki?
>
+1 for documenting this on our website if it is already implemented.
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi Rupert,
Thanks for your comments.
1. It is possible to do this via the User Management tab on the felix
webconsole. While this seems to be already easier than the old way of
setting the webconsole platform a new version is on the way.
2. I agree that there should be some documentation on how to configure
users and roles. What Bundlelist to include seems quite self-evident (we
don't have this info for the other modules)
3. Basically module developer need to know nothing Stanbol specific. I
summarized the most important java security bits on
http://mail-archives.apache.org/mod_mbox/incubator-stanbol-dev/201209.mbox/%3CCALvhUEUsmJ3CiDQ28pF9_TE67jcVdX48jRPg1EQLqxSOyG3C6w@mail.gmail.com%3E.
Should I place this on the wiki?
4. Creating an own module seems overkill an pointless as the module
checking requiring the permissions would require the module and on the hand
the module by itself would be of no value.
5. It is up to the modules to decide what permission they require so it
should be in the respective tests to check for them, if they shouldn't
require any permission then we should just make sure security is enabled
when the integration tests run.
My proposal is just to enable security by default if the respective bundles
are there, this would allow developers to see how their bundles behave in a
secure contexts. This isn't just the case for the stanbol launcher but also
for most application servers. So enabling security in the full launcher
helps developer have their modules portable. I've fixed some security bugs
in engines and content-hub which would have prevented them to be usable
Java 2 security enabled application servers.
Do you see any concrete disadvantage in this?
Cheers,
Reto
On Fri, Nov 30, 2012 at 6:15 AM, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> Hi all
>
> Regarding Security I am missing the following things:
>
> 1. HOWTO configure users and passwords: I would like to have the
> possibility to do that via the Felix Webconsole (e.g. an own Stanbol
> User Management and/or Stanbol Security tab). This is simple because
> that will be the place where users will look first. So even if that is
> not possible I would suggest to add such an tab that shows the
> description of how to do it.
>
> 2. User Documentation: On the Webpage there should be an own Section
> for Security: What launchers support it. What Bundlelists to include.
> How to configure ...
>
> 3. Developer Documentation: How to add higher level Permissions to an
> Stanbol Component. With an example and Walk through. The best would be
> an example for an EnhancementEngine.
>
> 4. Definition/Implementation of Stanbol Component specific Permissions
> in own modules (e.g. a module like o.a.s.enhancer.security) that
> contains Permissions (and other useful stuff) relevant for the Stanbol
> Enhancer (e.g Execute Enhancement Engine, Enhance Content for
> Language, Enhance Content Item with a maximum size ...)
>
> 5. Integration tests that test security
>
> If those things would be available I would feel much better to vote
> about Security. Because currently my understanding is on a very
> abstract level (based on the discussion of the thread already linked
> by Fabian [1]
>
>
> best
> Rupert
>
>
> [1] http://markmail.org/message/yamwhcla3b2j4onj
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: Enabling security be default
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi all
Regarding Security I am missing the following things:
1. HOWTO configure users and passwords: I would like to have the
possibility to do that via the Felix Webconsole (e.g. an own Stanbol
User Management and/or Stanbol Security tab). This is simple because
that will be the place where users will look first. So even if that is
not possible I would suggest to add such an tab that shows the
description of how to do it.
2. User Documentation: On the Webpage there should be an own Section
for Security: What launchers support it. What Bundlelists to include.
How to configure ...
3. Developer Documentation: How to add higher level Permissions to an
Stanbol Component. With an example and Walk through. The best would be
an example for an EnhancementEngine.
4. Definition/Implementation of Stanbol Component specific Permissions
in own modules (e.g. a module like o.a.s.enhancer.security) that
contains Permissions (and other useful stuff) relevant for the Stanbol
Enhancer (e.g Execute Enhancement Engine, Enhance Content for
Language, Enhance Content Item with a maximum size ...)
5. Integration tests that test security
If those things would be available I would feel much better to vote
about Security. Because currently my understanding is on a very
abstract level (based on the discussion of the thread already linked
by Fabian [1]
best
Rupert
[1] http://markmail.org/message/yamwhcla3b2j4onj
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
I had a look at the past discussions about security and found this
suggestions from Bertrand
"It might be useful to agree on the overall Stanbol security model in a
wiki or website page before digging into the details." from [1]
I still see a lack of consensus about the Stanbol security model. At least
different people seem to have different views.
We should solve this first. Maybe this also solves the default behavior
problem.
[1] http://markmail.org/message/yamwhcla3b2j4onj
2012/11/28 Reto Bachmann-Gmür <re...@wymiwyg.com>
> On Wed, Nov 28, 2012 at 4:30 PM, Fabian Christ <
> christ.fabian@googlemail.com
> > wrote:
>
> > 2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
> >
> > > Even the stable launcher starts with many
> > > optional components.
> > >
> >
> > Maybe we should look at launchers not as a defined product. The launchers
> > we have are just for testing and do not reflect any default or standard.
>
>
> > I would expect people to create their own launchers for their specific
> > needs and use cases.
> >
> I fully agree. My suggestion is that if somebody decides to have security
> as part of their launcher they should not have to additionally enable it.
> The full launcher is there that developers can see if their component work
> together well with all the others (this includes security).
>
> Cheers,
> Reto
>
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Wed, Nov 28, 2012 at 4:51 PM, Fabian Christ <christ.fabian@googlemail.com
> wrote:
> 2012/11/28 Reto Bachmann-Gmür <re...@wymiwyg.com>
>
> > I fully agree. My suggestion is that if somebody decides to have security
> > as part of their launcher they should not have to additionally enable it.
> >
>
> Maybe I did not understand your request before: Now I understand to enable
> security I have to
>
> a) add the bundles
> b) use the -s option
>
> And now you would like to remove the -s option? So that enabling security
> is just a matter of adding the bundles and it is activated? If people do
> not want security they remove the bundles from their launchers.
>
Yes, that's correct. If in the full launcher you disable
org.apache.stanbol.commons.security no authentication weill be needed for
anything, however if you also disable
org.apache.stanbol.commons.security.fexilwebconsole authentication will be
needed for the felix console as this falls back to its' built in
authentication method, in this case the password has to be configured over
the properties of the webconsole service (as this happens for the stable
launcher).
>
> > The full launcher is there that developers can see if their component
> work
> > together well with all the others (this includes security).
> >
>
> If the above is true, I would agree with that. I have no problem of
> bloating the full launcher with everything we have. The name indicates it
> ;)
The above is true.
Cheers,
Reto
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Reto Bachmann-Gmür <re...@wymiwyg.com>
> I fully agree. My suggestion is that if somebody decides to have security
> as part of their launcher they should not have to additionally enable it.
>
Maybe I did not understand your request before: Now I understand to enable
security I have to
a) add the bundles
b) use the -s option
And now you would like to remove the -s option? So that enabling security
is just a matter of adding the bundles and it is activated? If people do
not want security they remove the bundles from their launchers.
> The full launcher is there that developers can see if their component work
> together well with all the others (this includes security).
>
If the above is true, I would agree with that. I have no problem of
bloating the full launcher with everything we have. The name indicates it ;)
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Wed, Nov 28, 2012 at 4:30 PM, Fabian Christ <christ.fabian@googlemail.com
> wrote:
> 2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
>
> > Even the stable launcher starts with many
> > optional components.
> >
>
> Maybe we should look at launchers not as a defined product. The launchers
> we have are just for testing and do not reflect any default or standard.
> I would expect people to create their own launchers for their specific
> needs and use cases.
>
I fully agree. My suggestion is that if somebody decides to have security
as part of their launcher they should not have to additionally enable it.
The full launcher is there that developers can see if their component work
together well with all the others (this includes security).
Cheers,
Reto
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
> Even the stable launcher starts with many
> optional components.
>
Maybe we should look at launchers not as a defined product. The launchers
we have are just for testing and do not reflect any default or standard.
I would expect people to create their own launchers for their specific
needs and use cases.
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Wed, Nov 28, 2012 at 3:11 PM, Fabian Christ <christ.fabian@googlemail.com
> wrote:
> I want to add: Making this the default would also be contrary to our
> discussion about having the security part optional in Stanbol.
>
I don't see the connection. Even the stable launcher starts with many
optional components. The question is not if the modules should be there but
if they should be enabled by default if they are there. I think it makes
more sense to have an option to disable them rather than needing a command
line options to enable modules you've chosen to install (or your launcher
contains). If somebody requires the modules then disabling them by mistake
can really be a substantial treat to data security and privacy.
Reto
>
>
> 2012/11/28 Fabian Christ <ch...@googlemail.com>
>
> > Hi,
> >
> > I am -1 for making this the default.
> >
> > I would prefer to keep the default really simple. If people want security
> > they have to do something for it. This is true for most systems and
> > frameworks that I know about.
> >
> > - Fabian
> >
> >
> > 2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
> >
> >> Hi all,
> >>
> >> Currently stanbol security is only enabled when stanbol is started with
> >> the
> >> -s option. I think it would be better to start it with security enabled
> by
> >> default. This follows the "priciple of least damage" as the harm caused
> >> when a "disable security" option is forgotten is much smaller than the
> >> potential damage when arbitrary users can suddenly act with all
> >> privileges.
> >>
> >> Any objection to such a change?
> >>
> >> Reto
> >>
> >
> >
> >
> > --
> > Fabian
> > http://twitter.com/fctwitt
> >
>
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
I want to add: Making this the default would also be contrary to our
discussion about having the security part optional in Stanbol.
2012/11/28 Fabian Christ <ch...@googlemail.com>
> Hi,
>
> I am -1 for making this the default.
>
> I would prefer to keep the default really simple. If people want security
> they have to do something for it. This is true for most systems and
> frameworks that I know about.
>
> - Fabian
>
>
> 2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
>
>> Hi all,
>>
>> Currently stanbol security is only enabled when stanbol is started with
>> the
>> -s option. I think it would be better to start it with security enabled by
>> default. This follows the "priciple of least damage" as the harm caused
>> when a "disable security" option is forgotten is much smaller than the
>> potential damage when arbitrary users can suddenly act with all
>> privileges.
>>
>> Any objection to such a change?
>>
>> Reto
>>
>
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 28, 2012 at 4:32 PM, Reto Bachmann-Gmür <re...@wymiwyg.com> wrote:
> On Wed, Nov 28, 2012 at 3:50 PM, Bertrand Delacretaz <bdelacretaz@apache.org
>>... Optional security features are fine as long as they don't burden the
>> simple use case and don't make the code more complex than it needs to
>> be.
>>
> The "Stateless" Stable launcher which seems to be the one suited for your
> needs has no security modules...
That would be fine then, so your proposal would be to enable security
by default *for a specific launcher*?
That's much easier to +1, but as I just said we also need a
description of what you guys are trying to achieve.
-Bertrand
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Wed, Nov 28, 2012 at 3:50 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Wed, Nov 28, 2012 at 3:09 PM, Fabian Christ
> <ch...@googlemail.com> wrote:
> > ...I am -1 for making this the default.
> >
> > I would prefer to keep the default really simple. If people want security
> > they have to do something for it. This is true for most systems and
> > frameworks that I know about....
>
> Same here - my use case for Stanbol is a stateless service that
> doesn't need any security by itself.
Stanbol security only makes a difference if the services you're using
require some special privileges (i.e. Permissions the anonymous user has
not). Is this the case for the stateless services you're using?
> If I need to control access to i I'll configure something at the network
> level or put an httpd server
> in front.
>
Ok, for the felix webconsole by checking for AllPermissions a security
check is performed even if no security policy has been set (i.e. stanbol
has been started without -s) to avoid double login with different
credential in you usecase this should be disabled.
>
> I don't think Solr, for example has security features enabled by
> default, not even sure if it does provide any security feature.
>
That's true. Solr needs to firewalled or security configured via the
web-container.
> Optional security features are fine as long as they don't burden the
> simple use case and don't make the code more complex than it needs to
> be.
>
The "Stateless" Stable launcher which seems to be the one suited for your
needs has no security modules.
Cheers,
Reto
Re: Enabling security be default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 28, 2012 at 3:09 PM, Fabian Christ
<ch...@googlemail.com> wrote:
> ...I am -1 for making this the default.
>
> I would prefer to keep the default really simple. If people want security
> they have to do something for it. This is true for most systems and
> frameworks that I know about....
Same here - my use case for Stanbol is a stateless service that
doesn't need any security by itself. If I need to control access to it
I'll configure something at the network level or put an httpd server
in front.
I don't think Solr, for example has security features enabled by
default, not even sure if it does provide any security feature.
Optional security features are fine as long as they don't burden the
simple use case and don't make the code more complex than it needs to
be.
-Bertrand
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
> > I would prefer to keep the default really simple. If people want security
> > they have to do something for it. This is true for most systems and
> > frameworks that I know about.
> >
> Well don't know so many systems. What comes to mind is the db of the world
> economic forum (WEF), which by being started the default way exposed Bill
> Gates's Credit card number ;)
>
> Otherwise even windows no longer logs me in as administrator without
> password by default.
So you are comparing Stanbol with end user products. IMO this compare does
not fit very well.
Stanbol as a project delivers components that can be used to built
different kinds of semantic systems. It is not a product ready to use out
of the box in productive environments. And I do not think it will ever be
such one. You have to integrate Stanbol at some level. Security is one
aspect of such integration work in my view.
One of the best things in Stanbol is the aspect that I can use what I want
and exclude the rest. Having security activated by default is against this
concept.
Best,
- Fabian
--
Fabian
http://twitter.com/fctwitt
Re: Enabling security be default
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Wed, Nov 28, 2012 at 3:09 PM, Fabian Christ <christ.fabian@googlemail.com
> wrote:
> Hi,
>
> I am -1 for making this the default.
>
> I would prefer to keep the default really simple. If people want security
> they have to do something for it. This is true for most systems and
> frameworks that I know about.
>
Well don't know so many systems. What comes to mind is the db of the world
economic forum (WEF), which by being started the default way exposed Bill
Gates's Credit card number ;)
Otherwise even windows no longer logs me in as administrator without
password by default.
Reto
>
> - Fabian
>
>
> 2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
>
> > Hi all,
> >
> > Currently stanbol security is only enabled when stanbol is started with
> the
> > -s option. I think it would be better to start it with security enabled
> by
> > default. This follows the "priciple of least damage" as the harm caused
> > when a "disable security" option is forgotten is much smaller than the
> > potential damage when arbitrary users can suddenly act with all
> privileges.
> >
> > Any objection to such a change?
> >
> > Reto
> >
>
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>
Re: Enabling security be default
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
I am -1 for making this the default.
I would prefer to keep the default really simple. If people want security
they have to do something for it. This is true for most systems and
frameworks that I know about.
- Fabian
2012/11/28 Reto Bachmann-Gmür <re...@apache.org>
> Hi all,
>
> Currently stanbol security is only enabled when stanbol is started with the
> -s option. I think it would be better to start it with security enabled by
> default. This follows the "priciple of least damage" as the harm caused
> when a "disable security" option is forgotten is much smaller than the
> potential damage when arbitrary users can suddenly act with all privileges.
>
> Any objection to such a change?
>
> Reto
>
--
Fabian
http://twitter.com/fctwitt