From: "Gerard van Enk" <[EMAIL PROTECTED]> > Also if people have comments about the project, let us know so we can > talk about it next thursday.
As usual I'm interested but won't be able to attend - due to the fact that I'm currently working in Maastricht 60% of the time. Therefore I submit my comments here: Documentation: - Most of the documentation on the security project website is presented as outdated, and the status of the remaining documents is uncertain. - There is no comprehensive documentation of ContextSecurity. The only document with a usable level detail and completeness is in the mailinglist archives and in dutch: http://www.mmbase.org/archive/developers/msg04542.html - Finally, think about this: how secure can a security mechanism be when it is not properly documented? Speaking for myself, if I can't point a system administrator to a comprehensive set of documentation, I can't convince him/her that it's safe. This being the case the security mechanism falls short of achieving its goals. Context security: - I think the idea of context security is powerfull and very useful. Currently its main weakness is it depends on the use of an xml-file for definition of users/groups/contexts. It would be a considerable improvement in its design if the actual bussiness logic (authentication/authorization) would be separeted completely from the data acces logic (storage/retrieval of users/groups/contexts). In that case it would be much easier to create a ContextSecurity implementation that stores all configuration data in database tables. >From what I've heard, CloudSecurity provides this possibility, by implementing the bussiness logic again. I think this is not the way to go, considering the duplication of functionality, the waste of effort and the risk of new bugs being introduced. Speaking for myself, a ContextSecurity refactoring along these lines would be much more useful for me. Performance - The way security is implemented in the bridge has a severe impact on performance of multilevel-search. In fact so severe that security has to be turned off to keep performance acceptable when the size of tables grows beyond a certain limit (VPRO has experienced this, amongst others). I think this situation is not acceptable, and the way security is implemented needs to be rethought with performance in mind. To address this, I have this proposal: Firstly, make it a requirement of authorization implementations that type and owner is the only information that is needed of a node, in order to decide what access rights a certain user has. (ContextSecurity fulfills this requirement, as opposed to implementations that rely on relations of the node.) Secondly, augment the multilevel-search code to always retrieve this information with all nodes it reads (like it always retrieves the nodenumbers now). As a result, the multilevel-search will be able to retreive al information needed for authentication without the need to perform additional database queries. This will reduce the performance penalty of security to more acceptable levels. Rob van Maris Developer Finalist IT Group Java Specialists ------------------------------------------------------------- Amsterdam, The Netherlands Office: +31 20 5962321 (Direct) Mobile: +31 651444006 Fax: +31 20 5962331 -------------------------------------------------------------
