> 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.
This is a perfectly valid interpretation. In this case you would write an implementation of authorization which looks at the prinicpal that was used to authenticate the subject, and determine whether the user has a given permission based on that. 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 usefull. 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. 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. -- jt -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
