incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <henry.st...@bblfish.net>
Subject Re: -1 Against CLEREZZA-479 commits (was Re: logging in with undereferenceable webid)
Date Wed, 11 May 2011 08:57:55 GMT

On 11 May 2011, at 08:57, Reto Bachmann-Gmuer wrote:

> I can confirm that I now longer have all permission when using an webid that
> cannot be dereferenced or where the key in invalid. In both cases I don't
> get an error message but seem to be user anonymous. So I suspend my -1 at
> the current stage.

Cool :-)

> 
> Still I'm sceptical about the current partial solution of the issue. I'm
> puzzled by the creation of a test suite requiring such massive changes to
> the system under test. I understand a test-suite might require adding some
> hooks to the tested system, but here it seems a major redesign is being done
> to the whole authentication system for clerezza to be testable with the
> suite being implemented. I don't think I'm opposing to this changes but I'd
> like them to be under smaller issues describing their scope.

WebID is quite a big improvement to the authentication process, as will 
become evident when people start using it (and after we solve a couple of minor 
issues left over). It uses TLS which is not what any of the auth systems you had were
using, and it is a very different animal. Not only that but WebID is all about
making TLS user friendly. TLS until now was deployed in a centralised way by large
army based organisations where user friendliness is not at all a priority -
quite the opposite in fact.  So even people working regularly with TLS are surprised
about how we are using it: since we are

  1. making it decentralised
  2. making it friendly

A key to making it friendly, is to not reject people without explanation when 
something does not work. Imagine you go to a shop to buy some shoes, and on arriving 
as you are  about to enter, the whole thing shuts down with barbed wire and armed 
guards, dogs barking and you are told to get out of the way. That is the user 
experience of a simple  out of the box implementation of TLS. What we are doing
here is different: when you arrive at the shop instead of shutting everything down:
we can let you walk around parts you are allowed to access  - the tills and the 
stocks area is out of bounds (everything ANONYMOUS can not access) - and if you want more

we can tell you why your credentials are not accepted: your passport is out of date 
for example, or it is clearly a fake one. We could go even further and if you try to
force your way into the till area, we could build you a fake till area, and allow
you to think you are taking over - that is known as a honeypot. The more subtle 
parts of the army use those a lot.

> 
> Question regarding the latest commit:
> Implementation of AuthenticationMethod can now add principals to the
> subject, I assume that with this one can log-in with multiple authentication
> methods to gain more permission (e.g. standard set of permission from the
> webid, occasionally entering password for admin rights), what I don't
> understand is why the implementation of AuthenticationMethod remove
> principals (the anonymous principal) that is already associated to the
> subject.

I suppose that if the authentication system were a Partially Ordered Set, with 
ANONYMOUS at the bottom (like Nil is the bottom of the scala class hierarchy) then 
there would be no need to remove ANONYMOUS. This may be the case, in which
case removing anonymous may not be necessary. 


> 
> Sorry I meant that one should do
>> :f install
>> mvn:org.apache.clerezza/platform.security.foafssl.test/0.1-incubating-SNAPSHOT
>> :f install mvn:org.bouncycastle/bcmail-jdk16/1.46
>> 
> I'm looking forward to a documentation of the test suite.

There are two parts: there is a human readable version which is quite easy 
to understand, and there is the Machine readable version with an ontology 
that is already partly documented by EARL at W3C and that the WEbID XG 
will document too.

Here the nice thing is that we are also being friendly to machines :-)

> I'd recommend to
> use clerezza commands rather than felix-commmands with :f

perhaps we should have 
:z for clerezza specific commands

I think it is good to have something memorable to distinguihs those
from user functions people may want to add later.

Btw. I am starting to see the use of having some scripts at startup
be loaded to improve my work environment. Any way to do that?

> 
>> 
>> then one needs to start the test suite.
>> 
> What does this mean? starting the first of the bundles above?

yes

> 
> 
>> I need to do something so that at least the second install is not
>> necessary.
>> 
>> 
>>> anyway, the page says:
>>> java.security.PrivilegedActionException:
>> javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target
>> yes, that's what it things say when they are not installed recently.
>> I think you told me that is now how it used to happen at some point. Any
>> idea where one should look to fix that?
>> 
> Well, I think this occurs when acting as client. Afaik we rely solely on
> traditional PKI with jvm CA configuration there (I have some code somewhere
> to turn this verification off, but obviously this isn't a real solution)

Ah ok, so what we need to do is make SSL connections started by clerezza
work... I'll look into that.
> 
> 
> 
>> 
>>> 
>>> This is an improvement, since it is what will allow automated testing of
>>> the whole thing.
>>> As I understood you want a tool to test an arbitrary webid
>> implementation. This shouldn't require changes to our implementation as any
>> WebId complaint implementation is supposed to pass, and clearly before it
>> was at least closer to WebId compliance as it now.
>> 
>> Well yes, but the test suite really helped me debug this. For one you can
>> now login with a false certificate and it will tell you exactly why it
>> failed.
>> 
> I'm not sure, this sounds like something which should be part of clerezza
> rather than an optional test-suite

agree. But the UI needs to be improved.

> 
> 
>> Imagine what you would have to do without such a test suite and you had a
>> field problem, with some user telling you that he could not log in? Good
>> luck.
>> 
>> The UI of the test suit certainly can be improved. I'd love some help
>> there.
>> 
> Haven't been using the test-suite yet, is it documented somewhere?

There were 900 lines of code there. Can't do everything here. We had 
to write a paper for http://d-cent.org/fsw2011/ and for the W3C 
http://www.w3.org/2011/identity-ws/ Identity in the browser. 
The paper we submitted there has been accepted btw.

It is very easy to understand. It explains in broken english what
is wrong with your certificate.
> 
> 
>> 
>> If you are so keen on security, please allow me to think about it and fix
> it,
>> So keen on security? This whole module is about providing a cryptographic
> proof of identity, now this is not working.
> 
> It is working now. Thanks for pointing out the issue.
>> I just mean you could give me a few hours of slack to solve the issue.
>> 
> sure, but having small issues (as well as competence with the source-control
> tool used) allow to easily revert to last approved version while the issue
> is being solved.

Well I am getting more familiar with git. I was able to apply one patch
in a stack of patches that I had been working on.

> 
> 
> 
>> 
>>> And not in a way to deny users access that should have access (which
>> would be bad) but by giving access even with a clearly broken proof and
>> allowing anybody to do staff which requires asmin permission. I don't think
>> I'm being particularly picky if I ask you to act immediately.
>> 
>> It's done.
>> 
>>> 
>>> and I'd suggest removing the Apache Felix Web Management Console which
>> has a
>>> different admin password than the main admin - so you told me - and which
>> is
>>> bound to leave a back door in every Clerezza installation. That seems
>> easy to
>>> fix.
>>> Not true, it requires the knowledge that the password has to be changes
>> there, but it's not a back-door in every installation, this is not to say
>> this shouldn't be changed.BUT: What has this to do with the topic, open an
>> issue and remove a few lines from storageless parent for a quick fix.
>> 
>> Since you have put the heat on me, I just thought I'd give you something to
>> do while I fix the problem :-)
>> 
> 
> You mean I'm obviously lacking work if I have time to complain about a
> blatant security whole?

"hole"

No, just that there is another blatant security hole that should also be
fixed. :-) So all the arguments you are applying to me above should be applied there too.



> 
> Reto

Social Web Architect
http://bblfish.net/


Mime
View raw message