Re: Portlet security

[EMAIL PROTECTED] wrote: I don't think Java 2 would really fit our needs. Currently, Java 2 provides code-source based access controls (access controls based on where the code originated from and who signed the code), but it lacks the ability to additionally enforce access controls based

Re: Portlet security

Santiago, The problem is that the built-in code is per-process (read: per-JVM) and it not the required per-thread which we need for Jetspeed. So we couldn't use the internal stuff without extending the Jetspeed code to do the ACL checking. Let me be *very* clear: The Jetspeed code *must*

Re: Portlet security

Santiago, I agree that it is possible to implement the PortletAccessControl interface based on JAAS, JAAS provides the Subject.doAs() method that allows to execute code under the identity of a particular user (I know the details of how to do this). There are cases and environments where it is

Re: Portlet security

Steve Freeman escribi: Santiago, The problem is that the built-in code is per-process (read: per-JVM) and it not the required per-thread which we need for Jetspeed. So we couldn't use the internal stuff without extending the Jetspeed code to do the ACL checking. Let me be *very* clear:

Re: Portlet security

[EMAIL PROTECTED] wrote: Santiago, I agree that it is possible to implement the PortletAccessControl interface based on JAAS, JAAS provides the Subject.doAs() method that allows to execute code under the identity of a particular user (I know the details of how to do this). There are

Re: Portlet security

I don't think Java 2 would really fit our needs. Currently, Java 2 provides code-source based access controls (access controls based on where the code originated from and who signed the code), but it lacks the ability to additionally enforce access controls based on who runs the code. We need

Re: Portlet security

on 2/24/01 6:45 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Using the Turbine groups, roles, permissions etc to determine whether the access is allowed is just one special case. Often, customers have their own user / group / access control management databases and tools, so often custom

RE: Portlet security

Craig Berry wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 22, 2001 6:18 AM We also have plans in this direction, I think we should agree on a common interface for what we do. Absolutely. That's why I threw out a skeletal proposal for

Re: Portlet security

Jon Stevens wrote: on 2/22/01 4:17 PM, "Santiago Gala" [EMAIL PROTECTED] wrote: All of the java.security.* framework is interface based. So is Turbine's. I really don't see a need to use java.security.* when Turbine has a *MUCH* more complete implementation of a security framework

Re: Portlet security

We also have plans in this direction, I think we should agree on a common interface for what we do. Some first thoughts on this topic ... I think there are actually two points where access control must be applied: - Customization - users should only be offered portlets that they are allowed

RE: Portlet security

There was a proposal in the cvs tree at one time, don't know if enough has changed to make it invalid, but integration with turbine's security model was in there... -Original Message- From: Craig Berry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 21, 2001 11:20 AM To:

Re: Portlet security

[EMAIL PROTECTED] wrote: We also have plans in this direction, I think we should agree on a common interface for what we do. Some first thoughts on this topic ... I think there are actually two points where access control must be applied: - Customization - users should only be

RE: Portlet security

You can find the other security proposal in the build: /jetspeed/proposals/0004.txt viewable-by group="foo" role="bar" perm="baz" / is this permission under the portlet definition? I believe it would be better to use an ACL approach, to represent the permission association between the

Re: Portlet security

on 2/22/01 3:52 PM, "David Sean Taylor" [EMAIL PROTECTED] wrote: Im not sure if Torque can persist to XML files. My guess is that it always needs to go thru a JDBC driver... yup. the design is JDBC based persistence. saving out to a XML file doesn't buy you anything since you can do that by

Re: portlet - security proxy?

As of now, we do not have the facility to check the credentials in the portlet. But it is in the proposal list in CVS.Please do check http://www.working-dogs.com/jetspeed/cvsweb/index.cgi/jetspeed/docs/proposal Though Turbine supports it is just for portal. Not for portlet.. So once the