there is also a jaas realm implementation. Mvgr, Martin
> -----Original Message----- > From: Mitchell Christensen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 17:55 > To: 'Turbine Developers List' > Subject: RE: Security Changes > > > Is any thought being given to leveraging the Realm based authorization > scheme defined by the 2.3 Servlet specification, and implemented by Tomcat > (and every other compliant servlet engine)? Tomcat currently supports > Memory based, JDBC and a working JNDI Realm implementation. It would be > nice to at a minimum have available the option of using the underlying > security Realm. > > Using Realms also enables single sign-on across webapps that is currently > not possible with the Turbine security model. > > FWIW, I do prefer the user/permission/role/group model provided > by Turbine, > but I think that could be built on top of the Realm model. > > -Mitch > > -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 07, 2002 6:19 AM > To: Turbine Developers List > Subject: RE: Security Changes > > > > > 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]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
