David Sean Taylor wrote: >>First, tell you that I'm not dead, just overwhelmed and >>trying to catch >>up with mail (and the large amount of conflicting commits that I'm >>getting lately :-) >> >> > >What 'conflicting commits' .... > > I have lots of changes (too many) regarding:
link lifecycles (I have JetspeedTemplateLink having request scope). Current Jetspeed instantiates tons of copies. I'm not sure if a portlet scope would be nice. This has conflicted a lot with Paul latest changes. I had no time to view his changes to try to get a merged proposal. security Group portals (again changes in xxxLink, but also in other places) Cleaning it slowly. > > >>I'm still working on the security stuff, and I've noticed a problem: >> >> >>The classes for security appear in two (really four) >>different places, >>namely >> >>org.apache.jetspeed.om.profile[.psml] >>and >>org.apache.jetspeed.om.registry[.base] >> >>I need to unify Security and Psml/BaseSecurity and Role and >>Psml/BaseRole, so that they can be handled in the same way throughout >>Jetspeed. This is crucial for the Decorator/Proxy/Wrapper for >>PortletSets, which should include the constraints to enable dynamic >>checking. >> >> > >I believe we should require Java 1.3, and use Proxies in order to do the >proxy pattern correctly. >I've been using 1.4 with Jetspeed all week with no problems at all. > > This is a strong requirement. Here we are deploying in iPlanet XXX (I think 3). I'm not sure if it runs on 1.3 or 1.2.2. Lots of people will have corporate policies about App servers. I'm -1 on this one until I'm sure that I'm allowed to upgrade. I don't know other people. >IMO, security proxies should be turned off by default and that we should >not suffer performance hits for an optional feature such as >interceptor-based security checks during aggregation. > > >I am -1 for integrating om.profile with om.registry, they are two >different entities. >Registry entries are portlets, PSML entries are PortletInstances. >Far too much work. We should concentrate on getting out a stable release >in the next month. > > It's not integrating. It's just using the same Security and Role (castor) classes. If you look at the PSML and Registry, they are flat beans, and barely used if used at all. The syntax and the semantics should be the same (I think). WRT work, it is just renaming a few imports. I've tried it already. Using the same classes saves methods in JetspeedSecurity checkPermission( entity, rundata, Security) meaning check the permissions of the given entity (Portlets) within the given request context, and the given constraints. >As for security, we have to base our next security model (Jetspeed 2) on >J2EE and not Turbine. >Whether or not its better is open to argument, but it is standard and it >looks like the Portlet API will most likely mirror the Servlet API for >security. > > If you look at the archives, I pressured a lot the turbine people to follow this track earlier this year. In fact I have said several times in mail here and in turbine-dev that Turbine should return java.security.Principal and use Permission classes, that we should use the standard java.security calls and mechanisms. But I got no success :-( I have been thinking a lot about this, and have an idea on how to use completely standard Java APIs to implement security checks, using just JAAS and some (a bit hackish, but right) design ideas. It would be as fast (or slow) as standard java security. >In 1.3x, I'd also like to see portlet aggregation completely based off >the portlet instances (psml), and drop the portlet config and generation >of PortletSets for every aggregation. > Please elaborate on this one. PortletConfig should be killed ASAP, but something similar to PortletSets mimicking the PSML structure is still needed. That it is parsed for every request or just once (between customizations) is a different problem. If you want to avoid security checks during aggregation, this object should be inmutable, and security checked statically during construction, and once at the start of the request. But then permissions would have session scope. >However I believe its too much work for now, unless you all (the >Jetspeed team) are willing to commit to this effort as a team. Do we >need to have a vote on this? > > > >>I'm asking your permission for doing this. I thought about package >>org.apache.jetspeed.om.security.markup for both the >>interfaces and the >>base implementations, but I'm open to other names. >> >>What do you think? >> >> > >-1 pending a vote and commitment to do this effort as a team from all >voting developers. >The PSML services are now working very well in both Database and File >System implementation. >I am strongly -1 on changing this just to support an optional feature. > > OK. I'll rethink about it. But only Microsoft considers security an optional feature :-) > > >>A possible alternative, that simplifies less the Object Model, is to >>keep using the current one and store turbine ACL instead, but >>it couples >>Jetspeed more with Turbine. >> >> > >+1 caching the ACLs for obvious performance reasons. >I was under the impression that Turbine did this anyway. > > I think the problem is that the way we ask for the ACL makes turbine rebuild them every time, or something similar. I'm not yet sure. >Jetspeed 1.3x is already hopelessly coupled to Turbine. > > > >>I don't think that distinguishing Psml mappings from Registry >>mappings >>WRT security makes a lot of sense. >> >> > >Not sure if I agree. The registry defines Portlets. PSML defines Portlet >Instances. >They are two different entities and IMO require different semantics. > > I'm just speaking about the beans (castor-created) that represent the structure in memory. Both are security constraints. The objects can be the same, only the way they are handled should be different. >I personally don't see the need to check security during content >aggregation and prefer that this check is made during customization >(placing portlet instances on the page). > > Unless PortletSets are inmutable this opens hundreds of potential security holes. And nothing in Jetspeed APIs is inmutable. >David > > > >> >>-- >>To unsubscribe, e-mail: >><mailto:jetspeed-dev-> [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]>
