David Sean Taylor wrote: > > >>-----Original Message----- >>From: Santiago Gala [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, May 28, 2002 9:07 AM >>To: Jetspeed Developers List >>Subject: Re: Security for Portlet State (customize, maximize, >>minimize, cl ose) not working >> >> >>Glenn Golden wrote: >> >> >> >>>David - >>> >>>If you see the logic in how the default permissions work now, then >>>what's the point of having the roles and the ACL in there at all? >>> >>>As the code is curreltly written, the only part of the system that >>>actually checks against the ACL is BasePortletSet, when deciding to >>>show the pencile >>>(allowCustomize) for a set of menus or tabs - the other >>> >>> >>checks (those that >> >> >>>involve portlets) skip the ACL completely and go right for >>> >>> >>the defaults. >> >> >>> >>> >>>
>>> >>> >>I used the proxy pattern (wrapper, adapter, you name it) >>because in this >>way, only the proxies would do security checking. Thus, the >>code is much >>easier to audit and debug. >> >> >> >I suspect that the proxies are causing double the objects to be created >per request. >Im still not convinced that this is a good solution to the security >issue. (please convince me :) > Things should be first correct, and then fast. - With this approach it is easier to get it correct. - Modern VMs should not have problem with frequent creation of lightweight objects - From my inspection of logs, it looks like turbine ACL are not cached. I think this is the real performance bottleneck, as we must go to the database for each request. I don't know (yet) whose fault it is. - As a "reasoning by example", tomcat uses a HTTPRequest object internally (with setters and getters), and a final HTTPFacade class that encapsulates the "true" one, and which is the only one that the servlet sees. This is a typical security strategy. They don't use the Proxy class. I'm not sure whether they pool these objects, but we could when the implementation is functional (not right now). This is where I got "the way" :-) >If we must use proxies, they should be Java proxies. >Of course this requires 1.3. Anyone have problems with that? > > I'm not so sure. We rather should clean our interfaces, so that the security implementation is not a mess. Having three orthogonal interfases that a Portlet can implement does not look right. Making "final" the classes will enable Hotspot inlining of method calls in a security conscious way. > > >>I'm back after at least three weeks teaching intensive >>courses (one out >>of home). I will keep working on this, but I want to make >>sure that my >>changes will not interfere with current work. >> >>I have a PortletSetWrapper pending integration. It would >>store the PSML >>reference to the security entry object in addition to the proxied >>portletset to be able to handle security checks. All PSML security >>checks (except for some default mechanism) should be done there. >> >> > >Please review the commits in this area. Glenn and I did something >similar, see Glenn's commit from May 14, 2002 > > > >>Would it fit? I have been mostly disconnected. I'm catching on mail >>right now. >> >>Regards to everybody, and thanks for keeping the machine going on. >> >> > >Glad to see you back again! > > I have managed to be still working on this, in spite of continuous delays. I hope I'll survive :-) > > >>>This is inconsistent and cannot be right. >>> >>>I'm looking for a sensible statement that defines what this default >>>permissions stuff is about. >>> >>>For non-logged in users, it makes perfect sense. If we >>> >>> >>don't know who >> >> >>>the user is, we don't have an ACL, so use the default >>> >>> >>permissions set >> >> >>>for non-logged in users. >>> >>> >>> >>> >>This mismatch between logged in and anonymous users was the >>reason why I >>proposed to have a "anon" user which would be used for ACL >>checking for >>non-logged in users. In this way we save a lot of conditional >>code, and >>make it both faster and more resilient and easier to audit. >> >>I have changes for this, pending integration, as I had not completely >>clear if this change was acceptable. >> >>The only bad part would be that process for non-logged in >>users would be >>(I hope slightly) slower. But a portal needs security, and I think we >>could have handled this by optimising the security path once the >>implementation was right. >> >> You don't comment on this one, but it again makes the security code much cleaner and enables the administration of anonymous permits much in the same way as other users (user "guest", role "guest", for instance). I'm looking at the latest code, and I will try to find the problem with the caching of Turbine's ACLs. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
