rbac-integration continuum branch
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 -- jesse mcconnell [EMAIL PROTECTED]
Re: rbac-integration continuum branch
+1 to merge this work into continuum/trunk - Joakim Jesse McConnell wrote: > 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
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]
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
On 28 Sep 06, at 9:28 AM 28 Sep 06, Carlos Sanchez wrote: is it using maven-user? there's already all user management code there to avoid duplication in different applications. Joakim, to the best of my knowledge used bits and pieces from Maven User but the implementation in plexus-security package is better in my opinion and has been worked on by more people (I've looked at it and agree though a critique of some things in p-sec in general is coming from me). Myself, Jesse, and Joakim were involved and the speed with which p-sec was integrated into Continuum is a testament to its ease of use. The user management is part of that system. 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: security policies was: rbac-integration continuum branch
Forking a separate thread here. On 28/09/2006, at 12:04 PM, Jesse McConnell wrote: 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? I think it should. I don't think it would encourage making someone an admin. 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 What is the project user role? This one will depend on the system, really. I think maybe assigning it by default but allowing it to be removed (or making it configurable at the time of addition) is a good idea. Do all users inherit the roles of the guest? Maybe in this case the roles and permissions are getting mixed up. Really, when you start assigning roles to a guest user, aren't you saying that the project permissions should be open to everyone? 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. +1. This doesn't seem to be in place in the SVN version I'm using, BTW. The add project stuff appears to everyone. 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? That's basically how it is configured now. I think it's good. Cheers, Brett
