Thanks. Where can I get a copy of the Security proposal ?
- viraf --- James Taylor <[EMAIL PROTECTED]> wrote: > > > 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]> > __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
