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 on who runs the code. That is true. You get this with JAAS standard extension. Your previous sentence reminded me of the Pistoia book, who says (page 670): "The Java 2 SDK provides a mean to enforce access controls based on *where code came from* and *who signed it*. The need for such access controls derives from the distributed nature of the Java platform, where , for instance, a remote applet may be downloaded over a public network and then run locally. "The Java 2 SDK, however, still lacks the means to enforce similar access controls based on *who runs the code*. To provide this type of access control, the security architecture of the Java 2 SDK requires additional support for authentication (determining who's actually running the code), and requires extensions to the existing authorization components to enforce new access controls based on who was authenticated. "The Java Authentication and Authorization Service (JAAS)(see http://java.sun.com/security/jaas/) extends the security architecture, providing mechanisms to authenticate subjects, execute code on behalf of subjects, and grant permissions to subjects. The result is that access control policies can be based on both what code is being executed and who is executing that code. (IBM Java 2 Network Security, Prentice Hall) We need to protect portlet instances based on the identity of the user from whom a request to display them or perform other actions on them originates. There may be lots of portlet instances that share the same portlet code and can have different customizations for different users. That is precisely my point. We should use code in java.security. to ensure that the Principal on behalf of which the request is being run has the right permissions to run the code. Or, we may need to use doPrivileged() to ensure that actions can be performed even if the portlet code executes with less privileges than Jetspeed code itself. There is plenty of code there for doing these things, and it would be a pain to reimplement it, specially since I seriously doubt that we can do a better job that they have already done. I point specifically to the Principal and Group implementations, and also to java.security.acl.Owner, java.security.acl.ACL. In JAAS, the classes in javax.security.auth.* could be useful again. I think the right thing to do is to specify an interface in JetSpeed that defines what we need and let the PortletInvoker use this interface. This will allow to plug whatever seems appropriate to a portal implementer - be it JAAS or some code that directly uses a policy database or policy files (see Figure below). +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +-+-+-+---+-+ | Portlet Access | | Portlet Invoker |-| Control I/F| +-+---+-+ ++ | Aggregation | Customization | Other Views | | +-+---+-+ v ++ +| Access Control | ||Provider| +|++ |++ ++ The portlet access control interface in JetSpeed needs to allow the PortletInvoker to find out whether a given Subject (User) may perform a given Action (display, edit, config, ...) on a given Object (Portlet). 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 Access Control Providers will be required. Best regards, The framework in Java 2 offers interfaces for doing this kind of things, allowing easy integration in J2EE code. What I'm trying to say is that we should not reinvent wheels. We have code for permissions, access control, privileged code, guarding (or sealing) objects, and the Principal interface for authentication purposes. (+ Subject and others in JAAS). I just refer you to the example in tomcat 3.2 (jsp/security) to show how we already have: request.getUserPrincipal() request.isUserInRole(String role) already implemented, working and (supposedly) integrated in J2EE security (EJB containers, etc.) This API is part of servlet 2.2, and I think we should build on top of it. Authentication
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* initiate the ACL processing. JAAS allows you to plug in new auth mechanisms. It still has the problem as per the above statement. Thomas, I've looked into the built-in mechanisms for my own work. The framework consists of a set of interface classes. Sun provides a default implementation as the com.sun.* classes (I forget the rest of the naming, it's been awhile). Suffice it to say that the framework is very flexible and will allow us to implement the security mechanisms as we see fit. We just need to plug in the right classes. Steve -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 more advantageous to use an authorization mechanism other than JAAS. The PortletAccessControl interface does not mean to reinvent things, it is just to provide an abstraction of what the PortletInvoker needs (decision whether a given user may perform a given action on a given portlet instance) and allows pluggable implementations to meet this need. +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +-+-+-+---+-+ | Portlet Access | | Portlet Invoker |-| Control I/F| +-+---+-+ ++ | Aggregation | Customization | Other Views | | +-+---+-+ v No-op ++ Custom +| Access Control | J2EE/JAAS +||Provider| ||++ |++ ++ The AccessControlProvider implementations can map the simple checkPermission(user, action, portletInstanceID) call to JAAS/J2EE calls or to other authorization mechanisms. In a J2EE/JAAS provider, of course all the J2EE/JAAS functionality can be used as you say. For service projects, it should be possible to write custom AccessControlProviders implementing the PortletAccessInterface which might for example do database querys against the customer's policy databases; that was the main reason to define the PortletAccessControl I/F. Probably, there also should be a no-op implementation of the PortletAccessControl interface that has a checkPermission method that always returns true to avoid imposing the JAAS access control runtime and configuration overhead on portals that only have public content. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Santiago Gala wrote: [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 on who runs the code. That is true. You get this with JAAS standard extension. Your previous sentence reminded me of the Pistoia book, who says (page 670): "The Java 2 SDK provides a mean to enforce access controls based on *where code came from* and *who signed it*. The need for such access controls derives from the distributed nature of the Java platform, where , for instance, a remote applet may be downloaded over a public network and then run locally. "The Java 2 SDK, however, still lacks the means to enforce similar access controls based on *who runs the code*. To provide this type of access control, the security architecture of the Java 2 SDK requires additional support for authentication (determining who's actually running the code), and requires extensions to the existing authorization components to enforce new access controls based on who was authenticated. "The Java Authentication and Authorization Service (JAAS)(see http://java.sun.com/security/jaas/) extends the security architecture, providing mechanisms to authenticate subjects, execute code on behalf of subjects, and grant permissions to subjects. The result is that access control policies can be based on both what code is being executed and who is executing that code. (IBM Java 2 Network Security, Prentice Hall) We need to protect portlet instances based on the identity of the user from whom a request to display them or perform other actions on them originates. There may be lots of portlet instances that share the same portlet code and can have different customizations for different users. That is precisely my point. We should use code in java.security. to ensure that the Principal on behalf of which the request is being run has the right permissions to run the code. Or, we may need to use doPrivileged() to ensure that actions can be performed even if the portlet code executes with less privileges than Jetspeed code itself. There is plenty of code there for doing these things, and it would be a pain to reimplement it, specially since I seriously doubt that we can do a better job that they have
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: The Jetspeed code *must* initiate the ACL processing. If I understand correctly, it is because we need to act on behalf of a different (Subject/Principal,younameit) for each incoming request -- potentially new thread. JAAS allows you to plug in new auth mechanisms. It still has the problem as per the above statement. I think doAs() will work correctly, but I could be wrong. Still, JAAS *requires* jdk1.3, and I don't think we can throw away jdk1.2 compatibility yet. I noticed it today. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 cases and environments where it is more advantageous to use an authorization mechanism other than JAAS. I agree. And JAAS is not available in jdk1.2. But in some cases it can be the simplest way to get authorization (if the Application Server uses it). The PortletAccessControl interface does not mean to reinvent things, it is just to provide an abstraction of what the PortletInvoker needs (decision whether a given user may perform a given action on a given portlet instance) and allows pluggable implementations to meet this need. My concern was that the discussion looked like the whole Java security framework was going to be ignored. I agree that we will need to write those abstractions.I just felt concerned about compatibility. Specially since we are running on top of a servlet container, and we do not have full control of the VM. +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +-+-+-+---+-+ | Portlet Access | | Portlet Invoker |-| Control I/F| +-+---+-+ ++ | Aggregation | Customization | Other Views | | +-+---+-+ v No-op ++ Custom +| Access Control | J2EE/JAAS +||Provider| ||++ |++ ++ The AccessControlProvider implementations can map the simple checkPermission(user, action, portletInstanceID) call to JAAS/J2EE calls or to other authorization mechanisms. In a J2EE/JAAS provider, of course all the J2EE/JAAS functionality can be used as you say. My whole point was to try to keep these interfaces as close as possible to java.security, to avoid problems in the future. Specially when the abstractions are quite similar. For service projects, it should be possible to write custom AccessControlProviders implementing the PortletAccessInterface which might for example do database querys against the customer's policy databases; that was the main reason to define the PortletAccessControl I/F. Probably, there also should be a no-op implementation of the PortletAccessControl interface that has a checkPermission method that always returns true to avoid imposing the JAAS access control runtime and configuration overhead on portals that only have public content. a NullPortletAcessController will be a very good thing for some implementations. Also, a Controller that runs on top of whatever servlet engine authentication, using just request.getUserPrincipal() request.isUserInRole(), plus configuration info (container and Jetspeed), looks like a reasonable alternative. J2EE/JAAS will be needed for some other implementations. I repeat that I was feeling concerned because nobody had expressed that we would look at the java/javax. apis, not that I think that we should do everything just with them. Regards, Santiago -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 to protect portlet instances based on the identity of the user from whom a request to display them or perform other actions on them originates. There may be lots of portlet instances that share the same portlet code and can have different customizations for different users. I think the right thing to do is to specify an interface in JetSpeed that defines what we need and let the PortletInvoker use this interface. This will allow to plug whatever seems appropriate to a portal implementer - be it JAAS or some code that directly uses a policy database or policy files (see Figure below). +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +-+-+-+---+-+ | Portlet Access | | Portlet Invoker |-| Control I/F| +-+---+-+ ++ | Aggregation | Customization | Other Views | | +-+---+-+ v ++ +| Access Control | ||Provider| +|++ |++ ++ The portlet access control interface in JetSpeed needs to allow the PortletInvoker to find out whether a given Subject (User) may perform a given Action (display, edit, config, ...) on a given Object (Portlet). 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 Access Control Providers will be required. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Santiago Gala wrote: -- 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 than just java.security. -1 on java.security.* The need to use java.security framework comes from: - being able to reuse security support very well studied and engineered (java.policy, doPrivileged(), checkPermission() ) inside the VM and get fine grained support for cehcking permissions or specifying privileged actions. The java code is already there. It is a matter of using it. Now that java2 is our target, the effort is more than justified. - being able to integrate in J2EE framework servlet containers simply (EJB, JDBC, ...) - being able to integrate in a given corporate environment. java.security.Principal is the standard way to deliver privileges. I think TurbineUser should implement Principal. - surviving in a securityManaged servlet container. As an example of this, the admin portlet in Jetspeed will throw a SecurityException if standard security is on (ReadPropertyPermission on). It the turbine framework is based on these objects, it will get cached in the proper level and treated as a security exception. If not, it will be processed as a standard error. Also, the thread pool will have problems with calls trying to set thread priority or stopping threads. I'm not saying that you drop turbine security. I agree it is cood (nice typo=cool+good :). What I'm saying is that turbine should use the interfaces and methods there, for instance as a way to handle users ( java.security.Principal user.getPrincipal() ) or as a way to check for permissions (doPrivileged() and checkPermission() ). Also that we use the standard exceptions for security based exceptions, so that try-catch is simpler to program and we can survive when a SecurityManager is in effect in the servlet container. Don't you think that ignoring java security will bring problems in the future? -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To
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 Access Control Providers will be required. Best regards, That is why Turbine's is interfaced based and pluggable (ie: factory based). You can easily provide your own back end implementations. thanks, -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 discussion. 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 to use - Access to portlets - before displaying a portlet or allowing to perform an action on it, the portal needs to check whether the user still has access rights In either case, the access decision should be obtained via the same interface. Definitely need both, yes. That's what motivated my proposal of using getPortletSet as a filtering chokepoint, as anything using the portlets for any purpose will go through that API. That's one of the relevant points, it would involve access control in customization and display of portal pages which contain a set of portlets. However, this would not control access to portlets that does not go through aggregation or customization, e.g. via the maximized URL for a portlet. Some initial ideas how this may work - I think we need something like this in addition: +-+-+-+ +-+ | Portlet | Portlet | Portlet |...| Portlet | ++ +---+ | Access Control | |Portlet Invoker|-| Check I/F | +-+---+-+ ++ | Aggregation | Customization | Other Views | +-+---+-+ Every call to a portlet should go through an access control component. That component may have methods like public void service(PortletID id, String user/groupID, PortletRequest portletReq, PortletResponse portletRsp) public void actionPerformed(PortletID id, String user/groupID, ActionEvent actionEvent) ... etc. (Note that this is just for illustration, this is not intended as a concrete proposal) The PortletInvoker should make the required checks using the access control interface for checking permissions and then invoke portlets like this portlet.service(portletReq, portletRsp) actionPerformed(actionEvent) ... if the permission check was successful. All aggregation modules, customizers and other components in JetSpeed should invoke portlets only through the portlet invoker. This ensures that the invoker can always apply proper access control checking, calling the currently configured service via the JetSpeed access control interface. [snip] To accommodate usage of either store, JetSpeed should define an interface to check permissions, i.e. a call like checkPermission(user, portletID, action) or checkPermission(group, portletID, action) "action" may be something like display, edit, config, ... Makes sense. There should be pluggable services implementing this interface, e.g. one using settings in jetspeed.jcfg, one using a database, one using an authorization engine, etc. One option to implement the pluggable services would be Turbine Services, i.e. we would have Turbine Authorization Services that would be invoked through the JetSpeed Authorization Interface. I like the pluggable service model, and it should definitely be a Turbine service. That would most likely be a service that would be pert of the JetSpeed code base implementing the generic Turbine service interface and adding the portlet access control methods defined in the JetSpeed access control interface. -- Craig Berry - (310) 570-4140 VP Technology GlueCode 1452 Second St Santa Monica CA 90401 Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 than just java.security. -1 on java.security.* The need to use java.security framework comes from: - being able to reuse security support very well studied and engineered (java.policy, doPrivileged(), checkPermission() ) inside the VM and get fine grained support for cehcking permissions or specifying privileged actions. The java code is already there. It is a matter of using it. Now that java2 is our target, the effort is more than justified. - being able to integrate in J2EE framework servlet containers simply (EJB, JDBC, ...) - being able to integrate in a given corporate environment. java.security.Principal is the standard way to deliver privileges. I think TurbineUser should implement Principal. - surviving in a securityManaged servlet container. As an example of this, the admin portlet in Jetspeed will throw a SecurityException if standard security is on (ReadPropertyPermission on). It the turbine framework is based on these objects, it will get cached in the proper level and treated as a security exception. If not, it will be processed as a standard error. Also, the thread pool will have problems with calls trying to set thread priority or stopping threads. I'm not saying that you drop turbine security. I agree it is cood (nice typo=cool+good :). What I'm saying is that turbine should use the interfaces and methods there, for instance as a way to handle users ( java.security.Principal user.getPrincipal() ) or as a way to check for permissions (doPrivileged() and checkPermission() ). Also that we use the standard exceptions for security based exceptions, so that try-catch is simpler to program and we can survive when a SecurityManager is in effect in the servlet container. Don't you think that ignoring java security will bring problems in the future? -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 to use - Access to portlets - before displaying a portlet or allowing to perform an action on it, the portal needs to check whether the user still has access rights In either case, the access decision should be obtained via the same interface. The latter is required to cover the case that a user has selected a portlet some time ago, when he was allowed to use it but meanwhile an administrator has revoked his access rights. Putting the info in the jetspeed.jcfg file is one option. Other options are putting this info in a database or in some kind of authoritzation engine , e.g. Policy Director or Siteminder. To accommodate usage of either store, JetSpeed should define an interface to check permissions, i.e. a call like checkPermission(user, portletID, action) or checkPermission(group, portletID, action) "action" may be something like display, edit, config, ... There should be pluggable services implementing this interface, e.g. one using settings in jetspeed.jcfg, one using a database, one using an authorization engine, etc. One option to implement the pluggable services would be Turine Services, i.e. we would have Turbine Authorization Services that would be invoked through the JetSpeed Authorization Interface. Best regards, Thomas Thomas Schaeck Portal Architect IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: [EMAIL PROTECTED] Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany The GlueCode team is preparing to pursue portlet-level security for Jetspeed -- that is, the ability to make portlets visible to only certain users. Of course, we want to build this on the existing Turbine group/role/permission scheme. Our initial thought is that adding attributes in jetspeed-config.jcfg of roughly this form viewable-by group="foo" role="bar" perm="baz" / would be a good way to encode the permissions. In the absence of any such attributes, the default would be viewable by all. A reasonable "choke point" at which to limit access to portlets would appear to be PortletConfig.getPortletSet(). The set returned could be filtered to remove portlets for which the user does not have permission. This would suffice to control access both to portlets on the portal page, and listing of portlets on the customization page (which we're working to extend, by the way). Thoughts on this approach, please? -- Craig Berry - (310) 570-4140 VP Technology GlueCode 1452 Second St Santa Monica CA 90401 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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: Jetspeed Mailing List (E-mail) Subject: Portlet security The GlueCode team is preparing to pursue portlet-level security for Jetspeed -- that is, the ability to make portlets visible to only certain users. Of course, we want to build this on the existing Turbine group/role/permission scheme. Our initial thought is that adding attributes in jetspeed-config.jcfg of roughly this form viewable-by group="foo" role="bar" perm="baz" / would be a good way to encode the permissions. In the absence of any such attributes, the default would be viewable by all. A reasonable "choke point" at which to limit access to portlets would appear to be PortletConfig.getPortletSet(). The set returned could be filtered to remove portlets for which the user does not have permission. This would suffice to control access both to portlets on the portal page, and listing of portlets on the customization page (which we're working to extend, by the way). Thoughts on this approach, please? -- Craig Berry - (310) 570-4140 VP Technology GlueCode 1452 Second St Santa Monica CA 90401 -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED] --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 offered portlets that they are
allowed to use
- Access to portlets - before displaying a portlet or allowing to perform
an action on it, the portal needs to check whether the user still has
access rights
In either case, the access decision should be obtained via the same
interface.
The latter is required to cover the case that a user has selected a portlet
some time ago, when he was allowed to use it but meanwhile an administrator
has revoked his access rights.
Putting the info in the jetspeed.jcfg file is one option. Other options are
putting this info in a database or in some kind of authoritzation engine ,
e.g. Policy Director or Siteminder.
To accommodate usage of either store, JetSpeed should define an interface
to check permissions, i.e. a call like
checkPermission(user, portletID, action) or
checkPermission(group, portletID, action)
"action" may be something like display, edit, config, ...
We could use java.security.Permission (in general all of the java.security.*
framework).
We could write
org.apache.jetspeed.security.DisplayPermission,
org.apache.jetspeed.security.EditPermission,
org.apache.jetspeed.security.XXXPermission,...
This should be integratable with Turbine now, and with any java enterprise
application, allowing
code like the following (in tomcat/examples/jsp/security) to be gracefully extended by
turbine/jetspeed.
--- (from tomcat examples)
You are logged in as remote user b%= request.getRemoteUser() %/bbrbr
%
if (request.getUserPrincipal() != null) {
%
Your user principal name is b%= request.getUserPrincipal().getName() %/bbrbr
%
} else {
%
No user principal could be identified.
%
}
%
(...) including roles and acl.
There should be pluggable services implementing this interface, e.g. one
using settings in jetspeed.jcfg, one using a database, one using an
authorization engine, etc. One option to implement the pluggable services
would be Turine Services, i.e. we would have Turbine Authorization Services
that would be invoked through the JetSpeed Authorization Interface.
All of the java.security.* framework is interface based.
--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/
List Help?: [EMAIL PROTECTED]
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 portlet and role, and decouple the security def. from the portlet def. Look at the Turbine schema, the TURBINE_ROLE_PERMISSION table. Once the new architecture is formalised, we can identify entities needing security, possibly portlets, panes, templates. Turbine already gives us users, groups and roles. I was working on security wrt psml files. Will psml files be around in the next release? :) To accommodate usage of either store, JetSpeed should define an interface to check permissions, i.e. a call like checkPermission(user, portletID, action) or checkPermission(group, portletID, action) Turbine already does a lot of the work for you wrt users and groups: @see turbine.util.security.AccessControlList turbine.util.SecurityCheck turbine.util.TemplateSecurityCheck From rundata, you can make checks like this: data.getACL().hasPermission(permission) or use the utility classes There should be pluggable services implementing this interface, e.g. one using settings in jetspeed.jcfg, one using a database, one using an authorization engine, etc. One option to implement the pluggable services would be Turine Services, i.e. we would have Turbine Authorization Services that would be invoked through the JetSpeed Authorization Interface. I like that (authorization service) I like making use of the role-permission approach already defined in Turbine. The problem is that portlets and other jetspeed objects are stored in a JCFG registry, where users and groups are defined in the database. I know its very easy to edit the JCFG file, but mine is getting very large and unmanageable. Plus I have multiple configurations Has anyone ever considered storing the registries in a database? Using Torque, we could still define our object model in XML Schema, and deploy to whatever JDBC datastore we want. Im not sure if Torque can persist to XML files. My guess is that it always needs to go thru a JDBC driver... -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 having a JDBC-XML export. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: http://www.mail-archive.com/jetspeed@list.working-dogs.com/ List Help?: [EMAIL PROTECTED]
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 proposal is implemented we can do it. Anbunidhi Mahalingam - Original Message - From: "Ivanova, Jordanka" [EMAIL PROTECTED] To: "'JetSpeed'" [EMAIL PROTECTED] Sent: Tuesday, October 24, 2000 9:58 PM Subject: portlet - security proxy? I am looking for information on how portlet can authenticate user for remote service using the same credentials that he/she logged with in the portal. Like a portlet that connects to email/web space site and retrieves the data given the password and id are identical with the portal's. If you have any links or info please email. Thanks, Dannie -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED] -- -- Please read the FAQ! http://java.apache.org/faq/ To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: http://java.apache.org/main/mail.html Problems?: [EMAIL PROTECTED]
