Re: rbac-integration continuum branch
+1 for the merge Emmanuel Jesse McConnell a écrit : Over the course of the past 3 weeks I've worked with joakim on the plexus-security effort to bring rbac based security to Archiva. We succeeded. Last Friday (or so) I took the continuum/trunk and created the rbac-integration branch. I wanted from to test the integration of rbac based security, using the plexus-security project, into continuum. It integrated beautifully, without a whole lot of work, in record time, and is pretty functional now ... Some of the fun things that plexus-security brings with it are: * full separation between application webapp and security (lightweight integration). * proper modularization for security components (authentication, authorization, policy, system, web, etc...) * rbac (role based access control) authorization provider. * full user management war overlay (using healthy chunk of maven-user to make it happen) * toggle-able guest user authorization. * remember me and single sign on authentication. * forced admin account creation (through use of interceptor) * key based authentication (remember me, single sign on, new user validation emails, and password resets). * http auth filters (basic and digest). * aggressive plexus utilization. * aggressive xwork / webwork integration. * xwork interceptors for force admin, auto login (remember me), secured action, and environment checks. * secured actions for all of the /security namespace and at least one continuum secured action (these are enforced by the pssSecureActionInterceptor) * all the password validation, user management stuff (again maven-user origins) * continuum-security artifact containing the actual static and dynamic roles, and a continuum role manager that merges permissions to the core system, user, and guest users * ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags. * placeholders for ldap authentication, authorization and user details retrieval using plexus ldap components * ability to re-use Acegi for authentication I think it is very usable now, its a matter of some jsp and action work to clean up some things and hide some other knobs and buttons. I'd like to get feedback and discussion from the others here about the implementation, and consider a vote to merge it to trunk after that. I believe it is stable enough to move forward with. jesse
Re: rbac-integration continuum branch
is it using maven-user? there's already all user management code there to avoid duplication in different applications. On 9/28/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: +1 for the merge Emmanuel Jesse McConnell a écrit : Over the course of the past 3 weeks I've worked with joakim on the plexus-security effort to bring rbac based security to Archiva. We succeeded. Last Friday (or so) I took the continuum/trunk and created the rbac-integration branch. I wanted from to test the integration of rbac based security, using the plexus-security project, into continuum. It integrated beautifully, without a whole lot of work, in record time, and is pretty functional now ... Some of the fun things that plexus-security brings with it are: * full separation between application webapp and security (lightweight integration). * proper modularization for security components (authentication, authorization, policy, system, web, etc...) * rbac (role based access control) authorization provider. * full user management war overlay (using healthy chunk of maven-user to make it happen) * toggle-able guest user authorization. * remember me and single sign on authentication. * forced admin account creation (through use of interceptor) * key based authentication (remember me, single sign on, new user validation emails, and password resets). * http auth filters (basic and digest). * aggressive plexus utilization. * aggressive xwork / webwork integration. * xwork interceptors for force admin, auto login (remember me), secured action, and environment checks. * secured actions for all of the /security namespace and at least one continuum secured action (these are enforced by the pssSecureActionInterceptor) * all the password validation, user management stuff (again maven-user origins) * continuum-security artifact containing the actual static and dynamic roles, and a continuum role manager that merges permissions to the core system, user, and guest users * ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags. * placeholders for ldap authentication, authorization and user details retrieval using plexus ldap components * ability to re-use Acegi for authentication I think it is very usable now, its a matter of some jsp and action work to clean up some things and hide some other knobs and buttons. I'd like to get feedback and discussion from the others here about the implementation, and consider a vote to merge it to trunk after that. I believe it is stable enough to move forward with. jesse -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: rbac-integration continuum branch
+1 from me too. I've inspected the original Continuum security, the proposed continuum-acegi branch and the rbac-integration one. This is definitely the easiest to understand and work with, and gives us the best of both worlds - a strong user model and RBAC authorization framework that integrates nicely with our web framework as well as being generally useful anywhere, and still lets you use Acegi and other toolkits for doing the authentication and obtaining roles from a variety of external stores which we don't want to write integration for. I've also done the work of setting this up from scratch and making updates on another app, and it was really easy to understand. It needs docs, but I only had to get a short walkthrough to run with it and haven't needed to dig into the code to figure out how it works which would have been one of my concerns. I'm comfortable that it's not going to hinder our ability to find contributors and will be flexible enough to make changes over time as we add new features. Nice work all. Let's give this the weekend to let people voice their opinions, then I think we should call a formal 72-hour vote and move on to the next challenge. Cheers, Brett On 28/09/2006, at 12:01 PM, Joakim Erdfelt wrote: +1 to merge this work into continuum/trunk - Joakim
Re: rbac-integration continuum branch
on a related note and the heels of the last emailsome things to ponder There are a few policy decisions that I wanted to bring up for some feedback... 1) when a project group is added, should the 'Project Developer' role for that project automatically be assigned to the admin user? I think it should, since the admin is able to just go and grant it anyway, but will that encourage making everyone and admin? should that be an option anyway? 2) when a project group is added, should the Project User role be granted to the guest user? I think so, but only if we are going to wrap these things behind authorization... which we really don't have to...which leads to following questions I suppose 3) who should be granted the role that allows for adding projects to continuum? right now that is only the system administrator. Perhaps we make a Continuum Manager role as well that grants that kind of top lvl authorization without handing full sysad rights away...I kinda like that idea. 4) how deep into continuum should the guest user be allowed? should they have access to all levels of the project group information wise, just not able to twiddle any dials or knobs? perhaps for now since continuum was always pretty open before we try and maintain the same lvl of access for guest users, just protect the knobs and buttons. In the long run these behaviors should be configurable I think, but we need to decide on some sane defaults. jesse -- jesse mcconnell [EMAIL PROTECTED]
