[I am replying to the several messages that my last post originated. I even fired up emacs to write this!]
> [James Taylor] > > I agree, and still feel that if we offer a default implementation of > authorization it should map permissions to subjects (possible via > roles) rather than to principles. A subjects permissions should be > the same regardless of how they are identified. (Of course, other > things can vary the mapping, per our discussions regarding > Scope/Context). I agree; in fact, I don't think the default implementation should have the concept of Principals at all. (James, type 100 times: "I will not write `principle' when I mean `principal'"... ;-) > > [Gonzalo Diethelm] > > > > I still don't know what you plan to do with fulcrum. Moreover, I would > > like to know if the basic functionality of TSM as I implemented it is > > good enough for your purposes: > > > > Subject getSubject(String id) > > Permission getPermission(String id) > > > > Authenticator getAuthenticator(Subject subject) > > => boolean checkSubjectCredentials(Subject subject, > > Credentials credentials) > > Authorizer getAuthorizer(Subject subject) > > => boolean checkSubjectPermission(Subject subject, > > Permission permission) > > > > Maybe the last two could be collapsed into a single call through > > TSM, so that the caller would never know about Authenticators and > > Authorizers: > > > > boolean checkSubjectCredentials(Subject subject, > > Credentials credentials) > > boolean checkSubjectPermission(Subject subject, > > Permission permission) > > [James Taylor] > > I prefer this. After some thought, me too... That slightly changes the concepts of Authorizer and Authenticator: they are a programmer-only device, and a caller of Turbine will never see them. Nice. > [James Taylor] > > We probably need to provide an implementation of authorizer which > uses roles in the classic turbine way. I agree. Since you volunteered, feel free to fire away and commit your changes into CVS! ;-) > [James Taylor] > > Only that instead of choosing one implementation we try to merge > both of your proposals into one default implementation where the > parts that are different are pluggable options. I figure if we can't > do this then are pluggability isn't good enough. That's kind of hard, since Eric's implementation adds concepts (Principal, Policy) that would not be easy to align with my proposal. > [Kurt Schrader] > > I think that this would be defeating the goal of CVS. If your > proposals are that different then I would suggest creating different > CVS branches and putting the code in the "correct" place in both of > them. I don't think that the namespace should be cluttered and used > to differentiate your proposals like this. I disagree; the proposals directory in cvs has one subdirectory for each committer. > [Chris Holman] > > I could be wrong here, but my understanding is that each principal > can be used to provide a different set of permissions/authorisation > depending on which application the Subject is logged into. A Subject > provides a single authentication object for all applications. > [Viraf Bankwalla] > > I would have assumed that the capabilities of a user are associated > with the principal rather than the subject. A prime example would > be one in which a Subject may play the role of an Admin and some > other non Admin role. Typically a principal may not play both > roles, however a Subject may. > [James Taylor] > > However this is not (IMO) a general enough interpretation to be used > for the default implementation. I personally have never worked with > an application where users get different capabilities depending on > how they login, but can certainly see cases where that would be > useful. However there are all kinds of state modifiers which can > affect whether a user has a given permission. I see these as falling > into two sets. The first is the security datastore which contains > whatever data model is used to map subjects to permissions. This is > the static model of security for an application. The other is the > Scope, which contains whatever application state may determine > whether a user has a permission at a particular time. This can > include all kinds of application dependent things like what > principal was used to authenticate, what section of the application > the user is working in, what 'project' a user is currently working > with (think scarab). All of these are application specific things > which the default security implementation needs to be abstract > enough to deal with. I was about to write a response, but James did a wonderful job summarizing my feelings about this. Yes, we have talked about creating a Scope interface that somehow describes the current "context" for a user within an application, and having an Authenticator class that takes that Scope into account to decide whether a User has or not a Permission. That concept would be, IMHO, a much more powerful mechanism to differentiate authentication than trying to assign permissions to subjects via principals. > [James Taylor] > > There will also be cases that fall completely outside of the > Subject/Permission model of security that the default implementation > will be based on. For these cases, you can implement your own > security manager to do whatever whacked out thing you want. > > Thus the goal is to provide complete flexibility at two > levels. First, an empty SecurityManager interface which allows > implementing a completely custom security model. Second, a default > implementation based on the Subject/Permission model with pluggable > components for various tasks (authentication, authorization, ...), > and likely some basic implementations of each component. Since most > applications use such a model, ideally this will make it easier to > implement application security, since you only need to replace the > components that differ from one of the provided ones. However if > your application doesn't fit into this model, it will be possible to > fit your model into turbine without needing to hack up the core. With the current caveat that Turbine's code will have to be modified, because it will call the concrete TurbineSecurityManager directly. This is a consequence of having an empty SecurityManager interface, and is a feature, not a bug... ;-) (at least for now, until we figure out whether there IS a non-empty SecurityManager interface that's generic enough). > [Scott Weaver] > > I think the whole idea behind the new security implementation is > that the end user can leverage ANY type of security service whether > it be Realms, LDAP, Turbine Classic, MS Active Directory, etc. > > As many have pointed out in recent security discussions, the new > security implementation needs to be kept as open as possible. > That's why the implementation consists of essentially empty > interfaces and a very basic security manager which, AFAIK, will > enable the user to implement multiple implantations at once. Your > recommendation of Realm based security is could (and should) be one > of the many implementations available to end developers. Once again, took the words right out of my mouth. -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>