Gonzalo A. Diethelm wrote:
>Santiago, thanks for your comments.
>
We are anxious to help see a Security Manager that we can use in
Jetspeed. I will participate in the design and development effort, and I
think we can find more volunteers coming from the Jetspeed community.
>
>
>>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 feasible. I think we could work with this kind of setup.
>
>>It looks like your proposal allows for things like:
>>
>>- specifying our factory.
>>
>
>... and your entities.
>
Yes, the next point implied (I was thinking about) returning a new
PortletPermission("Slashdot","read")
>
>>- 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.
>
It is handy for things like specifying that a user has
FilePermission("/usr/local/*", "read" ), and then having checks on
FilePermission( aFile.toString(), "read" ). If aFile is beneath
/usr/local, the check will succeed, if not, it will fail, as the manager
will check if any of the User permissions imply the one checked. Also,
AllPermission.implies( aPermission ) is always true.
They use it heavily in java2, because it is not reasonable having to
specify a different permission, for instance, for each tcp port. So they
have SocketPermission("1024-*", "listen") or something similar. When you
ask for new ServerSocket(1056), the implementation builds a
SocketPermission( "1056", "listen" ) and asks the SecurityManager. The
SecurityManager looks at the PermissionCollection in the codebase
(java2) or codebase/Principal (jaas), and sees if the existing
permissions imply the asked one. I'm quoting from memory, so forgive if
the description is not precise. If you have java.security.AllPermission,
then you don't need any other Permission, as implies returns true. ;)
>
>>- 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.
>
Here, it would be important to know if turbine wants to have permissions
associated only with Users (Principal or Subject in jaas jargon), or
also with code bases (elements of the modules path, for instance). The
codebase concept could maybe be extended to velocity templates paths,
but I'm not sure how. This could tackle the velocity version of the
killer jsp I quote further down.
>
>>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.
>
Even then, there would be substantial job. For instance, to specify that
only users with the role admin can see a given navigation, a check
should be placed somewhere that would retrieve the permission associated
with the required navigation from the policy and compare it to the
actual permissions for the current User.
If you want to restrict permissions to a service, a check should be
placed everytime the service is requested. And so on and so forth.
>
>>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).
>
Yes, it is a good question. Short term, I think we can skip these
issues. In the long term, and given that in the web services and portlet
scenario a vendor can supply portlets or servlets to get executed in
your container, it should be taken into account. Maybe not so much for
turbine, but clearly for Jetspeed. I don't know about other apps using
turbine.
Let's use tomcat as an example. Under tomcat 3.1 and beneath, all
servlets and jsp pages have the same permissions as tomcat. I think
beginning in tomcat-3.2.X, you can run it with "-security", and then a
SecurityManager will be started, and a policy file will be used to limit
permissions on different servlets, jsp pages or directories. In
tomcat-4 the policies are better polished. I bet that in the future,
running tomcat with security manager will be the default.
If a ISP uses a servlet container to host servlets provided by different
customers, security starts being important. As the example in tomcat-4
docs says, a jsp page like <% System.exit(); %> can be really harmful.
If someone can put it under your jsp directory, your server is done.
As I said, in a pure turbine application you usually have control over
the whole code base. This is no longer true as/if Jetspeed evolves, and
the portlet application file "market" develops. You could buy/download a
calendaring portlet app from a third party vendor.
>
>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.
>
I'm pointing to several issues. The issue about "quality" of the APIs is
rather long term, but I'm trying to make different points:
- It is difficult to write a strong security framework. If it was
possible to reuse one, it is better. I'm not sure, though, of the
performance or other issues of the java2 security model.
- If our Security framework is a shallow layer on top of JAXP/java 2
security, other people maintain (better or worse) most of the code. So
we can concentrate on other important work, like where are security
checks to be placed (tricky for Jetspeed), which granularity of
permissions do we need, etc.
- The Servlet API already has some security elements, and tomcat has
already a SecurityManager in place.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
