Re: Security in Continuum
I can talk about acegi as I'm committer there: acegi provides three points of security - filter level, protect urls by using web filters - method invocation level - instance level (ACL) 1. filter level By adding filters to the webapp you can control what patterns of urls require what user roles This is transparent to your application so it doesn't matter what web framework do you use. 2. method invocation level You can specify what methods and classes a user is allowed to call based on the user roles, mostly used with spring managed beans 3. instance level (ACL) For each instance of an object you can define if the user rights, that's the same as a file system where files have user, group and everybody permissions, in fact this is the sample used in one of the Spring books. This is accomplished using Aspectj JoinPoints. http://www.acegisecurity.org/docbook/acegi.html#acls The best feature about acegi is that it almost doesn't interfere with your application. Authentication can be done using web forms, http basic, certificates, ... For the backend you can use LDAP, database, container managed users, JAAS, CAS (single sign on),... It also provides a lot of goodies like password encryption, forcing https, remember me, ... and everthing through configuration so you don't need to change code to enable/disable them About the concern of using spring, if you don't configure acegi through spring IOC you'll need to instantiate the objects and make the callbacks that spring does after. You'll still need some spring interfaces and utils that acegi depends on. Hope this helps. On 1/11/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > Hi, > > In 1.1, we have decided to rework all security features. > > I tried to use osuser but this framework is crappy : > - UserManager is a final class that load a osuser config file, we can't set > parameters with plexus > because all initialization phase are done in constuctor that read config file > - need to duplicate code between Authenticator and AccessProvider > - all providers interface extends a base provider interface that require some > methods without > relation with provider must do > > I looked at berkano too. This project use actually dao pattern and hibernate > and permission doesn't > seems to be supported > > I looked at seraph too. This project seems to be interesting, it's used by > confluence and jira. It > seems we have all we need in it but it require to be used in a web app > environment, so i think we > can't use it if we want to use security framework in a standalone app in > future. > > jaas: i think we need a more high level framework. I'd prefer to use a plugin > where jaas can be plugged > > acegisecurity: this framework seems to be the more advanced. The most > important problem for its > usage, it's that required spring framework. I don't like to include in > continuum a new IOC container > only for this feature especially with a 2Mo jar. Can we exclude easily spring > dependency from acegi > by writing a mockimplementation? Can we use it in a standalone app? > > last possibility : we can write our own security framework. If we choose it, > we'll can start with > features required by continuum (user, group, general and per project > permission schemes) and we'll > add more functionalities later if we need more. > > What do you think about all these frameworks? > Which do we choose? > > Emmanuel > >
Re: Security in Continuum
On Wed, 2006-01-11 at 19:13 +0100, Emmanuel Venisse wrote: > Hi, > > In 1.1, we have decided to rework all security features. I haven't looked at osuser in particular yet, but I still think it might work for us. Anyway I'm suggesting the following strategy: 1) Make a set of Continuum-specific interfaces: * ContinuumAuthentication has a login( username, password ) and a logout() method * ContinuumAuthorization canExecute( authenticationToken, protectedResourceId ) * ContinuumUserManager User and Group object CRUD methods, addUserToGroup() and the likes. 2) Make a LDAP implementation of these interfaces and include Apache Directory in Continuum as the default database or write a Derby-specific implementation as that's what we're already shipping with. The advantage by including Directory is that we have one less implementation to write and it's easier to migrate to a proper LDAP database as you can connect to the Directory service and dump the existing database. The disadvantage is the increased size of the Continuum binary distribution. I'm currently not sure how big the Directory server is in terms of bytes. The binary ApacheDS distro[1] is 10MB but I really doubt all of that is required. It shouldn't be really hard to write a Derby implementation and it will probably be the fastest implementation. By following this strategy we isolate Continuum from the implementation as the interfaces are Continuum-oriented and should be pretty stable from day one, and we can add JAAS implementations later on. By having a standalone (Derby), LDAP and JAAS implementation I think that we've covered all possible integration points. I'd guess that 90% of all people wanting authenticate with an external system would use LDAP anyway. Thoughts? [1]: http://cvs.apache.org/dist/directory/apacheds/ -- Trygve
Re: Security in Continuum
Seraph also wraps around osuser, I believe. I think that standalone should be a secondary concern (a nice to have). I think as long as it can be backed by the same permissions data, the web part is the "hard part" we don't want to have to reproduce and maintain. I'd go with further investigation on Acegi. IIRC they only use Spring utilities and the injection is clean. If that's true, we could maybe minijar it, or provide patches to them to split it out in some way. Thanks! - Brett Emmanuel Venisse wrote: > Hi, > > In 1.1, we have decided to rework all security features. > > I tried to use osuser but this framework is crappy : > - UserManager is a final class that load a osuser config file, we can't > set parameters with plexus because all initialization phase are done in > constuctor that read config file > - need to duplicate code between Authenticator and AccessProvider > - all providers interface extends a base provider interface that require > some methods without relation with provider must do > > I looked at berkano too. This project use actually dao pattern and > hibernate and permission doesn't seems to be supported > > I looked at seraph too. This project seems to be interesting, it's used > by confluence and jira. It seems we have all we need in it but it > require to be used in a web app environment, so i think we can't use it > if we want to use security framework in a standalone app in future. > > jaas: i think we need a more high level framework. I'd prefer to use a > plugin where jaas can be plugged > > acegisecurity: this framework seems to be the more advanced. The most > important problem for its usage, it's that required spring framework. I > don't like to include in continuum a new IOC container only for this > feature especially with a 2Mo jar. Can we exclude easily spring > dependency from acegi by writing a mockimplementation? Can we use it in > a standalone app? > > last possibility : we can write our own security framework. If we choose > it, we'll can start with features required by continuum (user, group, > general and per project permission schemes) and we'll add more > functionalities later if we need more. > > What do you think about all these frameworks? > Which do we choose? > > Emmanuel >
Re: Security in Continuum
On Jan 12, 2006, at 2:25 PM, Emmanuel Venisse wrote: David Blevins a écrit : On Jan 11, 2006, at 10:13 AM, Emmanuel Venisse wrote: Hi, In 1.1, we have decided to rework all security features. I tried to use osuser but this framework is crappy : [...] I looked at seraph too. This project seems to be interesting, it's used by confluence and jira. It seems we have all we need in it but it require to be used in a web app environment, so i think we can't use it if we want to use security framework in a standalone app in future. Interesting, if you look at the dependencies for seraph, it's clearly using osuser. - http://opensource.atlassian.com/seraph/dependencies.html osuser is use only for the DefaultAuthenticator, if you don't use it, you don't need osuser. Wonder if "writing our own" option couldn't mean writing our own wrapper for osuser. not exactly. osuser would can be supported by a provider of our own. But if we decide to write it, it must be extensible with providers like other framework(osuser, seraph...) and ldap, jaas... I can't believe i forgot about this. http://jpam.sourceforge.net/documentation/ Then we could do real security and not java-toy security only usable by continuum. I've got a shared LDAP directory up on ci.gbuild.org right now which we use instead of /etc/passwd files for logging into the various gbuild machines. There is a j2eetck group that we put people in if they are allowed to see tck related stuff. Would be excellent if we could use that exact setup in continuum to lock off certain projects to only be visible to that or other groups. I've had to setup cron jobs to build the various things that are tck private -- made an attempt to put up a non-public continuum install for that, but it was too much of a pain. -David Emmanuel
