Jason van Zyl wrote: >Hi, > >Can I suggest that we take a different approach to this problem? > >There are many different security models and I don't think it is possible to >find a single model that is going to satisfy every situation, it's just not >going to happen. > >The security models used by Scarab and SourceCast are probably the most >sophisticated security model that any application would ever need, that >being the case I think it would be rare that many applications would need >that level of sophistication. > >I think trying to accommodate aspects of all security models into a single >one is a lost cause. I think we should look for the places where security >applies to Turbine and find a way for the core to use any model that a >project wishes to use. From a simple password text file model all the way up >to a sophisticated model like Scarab's. What we currently have is too >complicated for most uses and we should allow application programmers to >choose the model they wish to use. This will also allow easier integration >into J2EE environments. > From the analysis our people is doing, we need to address three separate issues here (I said two in previous e-mails, I had not grasped it fully ;-) ):
1- Authentication 2- AccessControl 3- User Management/Profiling 1 means giving a credential to the service and getting back a (set of) Principal/Subject, you name it. 2 means that, for a certain request and a certain authenticated User (Principal/Subject/whatever), you can derive a set of Permissions that are valid. Here is where things like Permission, Group, Role, ... belong 3 means ways to create, store, ... users and information related to users , like user preferences, etc. In some cases, we will authenticate against a external source, be it JAAS, LDAP, pam, Apache,... but we will not get anything from this external resource except the fact that the Principal name (User name?) is OK with the system. Thus, we are free to implement our own groups, roles, ... In other cases, the AccessControl can be external (let us imagine a scenario where JAAS and a SecurityManager are switched on). In this scenario, java.lang.Permission and AccessController.checkPermission() are already in place. Even in this scenario, User preferences or permanent information may need to be stored in the system. Separating the service in this three components/subservices will help isolate clean interfaces between them (The work is partially done, as we have a UserManager in turbine, and also a AccessController). This will help clean any implementation we do, and will allow for easy interoperation of different implementations. It will also make audits simpler, since the code of each sub-component will be simpler and more focused. I also suggest to look deeply into JAAS, as I'm afraid that any J2EE application has already a tight security system working. > >I have no particular bias as to which security model is best, they probably >all have benefits and drawbacks but I would like to take a stab at the hooks >that would allow different models to be used. Some changes to RunData and >the addition of site policy mechanism I think can do the trick. I'm working >on finishing the UML for a new scheduler and I'll try to make some diagrams >for security model hooks. > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
