Santiago, thanks for your comments.
> It would be interesting if the model would allow for applications
> subclassing Permissions. For instance, in Jetspeed we would possibly
> need PortletPermission(String portlet, String mode), PSMLPermission(
> String resource, String mode) or similar classes. These should be
> propagated cleanly by turbine. We could use a similar model to
> java.security, having a implies(Permission) method to test for equality.
My idea is that you should be able to extend any of the entities
(Permission, Role, User, Application, Session) and factories, and
then define your appropriate classes in the props file. Of course,
for this to work Turbine/Fulcrum should ONLY manipulate these objects
through their interfaces.
> With the current turbine-2 model, we would be forced to use things like
> Permission("PSML-/user/admin-read"), or
> Permission("Portlet-Slashdot-edit"). Coding that much semantics in
> Strings sucks. Maybe there are alternative solutions, but I can't see
> them. Please, enlighten me ;)
I thought of doing something like this:
public class JetspeedPermission
extends FulcrumPermission // or implements Permission
{
private String portlet_;
private String mode_;
Permission(String id)
{
super(id);
portlet_ = getPortlet(id);
mode_ = getMode(id);
}
Permission(String portlet, String mode)
{
super(makeId(portlet, mode)); // build a unique id, pass it up
portlet_ = portlet;
mode_ = mode;
}
// ...
}
> It looks like your proposal allows for things like:
>
> - specifying our factory.
... and your entities.
> - calling our factory for new Permission("Portlet", "Slashdot", "read")
> - Our factory retrieves the id automagically, instantiates the
> Permission, and returns it.
Yes, something like this.
> (I think the implies() or similar method is missing to have semantics
> such as Permission("Portlet", "RSS", "read") implies
> Permission("Portlet", "Slashdot", "read"), or Permission("Portlet",
> "RSS", "*") implies Permission("Portlet", "RSS", "read").
I'm not familiar with this "implies" concept.
> - Someone (SecurityManager?) checks the Permissions against the current
> Principal (User,Session?) in the running thread (and/or codebase) and
> returns silently or throws a SecurityException
Yes.
> OTOH, I think there are very deep issues difficult to track.
I'm sure this is the case. In fact, I think we should seriously
examine JAAS to see if we would not be better off simply dropping
Turbine's security model and adopting JAAS.
> For instance, I think that java2 java.security.Permission is a class
instead
> of an interface so that getName() implementation can be made final, and
> malicious code cannot do things like creating a new Permission, and
> changing the getName to return the name of a different permission...
I didn't even consider this kind of scenario...
> I think that having Permission interfaces can be dangerous in itself. This
> is one of the reasons why I push for the use of java.security.* classes.
> I don't think we have the resources to audit the design as they have
> already done. A lot of deep issues can be laying around, waiting to byte
> us. I think it is best, in terms of design economy, to trust the java2
> security model instead of reinventing a particularly tricky wheel.
This is a very good and strong point. Maybe we could use a point by point
comparison of JAAS and Turbine's current security model, to see how they
fare in terms of FUNCTIONALITY alone. Even more: is it possible to
reimplement
Turbine's current security model using JAAS underneath?
> Elaborating on the Permission interface issues, I could create a
> Permission to be checked, and change the id to a different Permission
> after it has been stored in a PermissionSet, or something similar...
Again, I didn't even explore these possibilities. Question: do we really
care about these kinds of scenarios, taking into consideration that the
scope of Turbine if for server-based apps? (honest question).
> Thus having non-inmutable Permissions implies that they should not be
> cached anywhere in the system. The same goes on with User (I could
> impersonate any user by calling setId() on the current User...)
>
> These are random thougths. I hope you will tell me if I am way off base,
> if you think about different use cases, or if I have missed
> something here.
My ideas do not go beyond an initial architecture. Your comments are
more than welcome; hopefully we will all come up with a decision that
will help all the Turbine/Fulcrum-based projects.
> Regards, Santiago
Best regards,
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
