Jetspeed 2
  1. Jetspeed 2
  2. JS2-204

PLT.7.1.2 Portlet URL securit y not implemented and absolute URL rendering

    Details

      Description

      PLT.7.1.2 PortletURL security
      -----------------------------
      The PortalURL doesn't yet honor a request for the explicit generation of secure or non-secure PortletURLs as required by the Portlet Specification.

      Whatever the setting, a non-secure url is always generated.

      I will implement this requirement using the same solution as provided by Jeremy Boyes for the Pluto PortalDriver.
      See: http://issues.apache.org/jira/browse/PLUTO-82.

      This solution will use two different Servlet Mappings in web.xml for the JetspeedServlet: a non-secure (what we have now already: /portal/) and a secure (/secure/portal/).
      For the secure mapping a security-constraint with transport-garantee CONFIDENTIAL will be defined, effectively securing any access through this mapping.

      These mappings are, and also need be, defined in WEB-INF/conf/jetspeed.properties too.
      The AbstractPortalURL will read these properties to determine which path to use for secure and non-secure PortletURLs.

      Note, these paths will only be used when a secure url must be generated while the current request is not, or visa versa.
      This means, other mappings can still be used (we have also a /jetspeed/* mapping defined although I don't know why or if it is needed anymore) as long as there isn't a switch from secure to non-secure or visa versa.

      Absolute URL Rendering
      ----------------------
      Another problem the above solution will partly solve is the current absolute URL rendering (including the Scheme, ServerName and Portnummer in an URL) which poses problems with Proxy configurations as has been recently been reported on the list by Scott Heaberlin.
      By using different mappings for the secure and non-secure access we don't need to prefix the urls with a HTTP:// or HTTPS:// scheme anymore.

      I will also remove the Scheme, Servername and Portnummer encoding in url generation as currently is done by the JetspeedPowerTool, JetspeedVelocityViewServlet and the ContentLocatingRequestWrapper of the ContentServer.

        Issue Links

          Activity

          Hide
          Ate Douma added a comment -

          I forgot about this issue but with the new related JS2-275 issue I think its time to solve this (here or there).

          When I started looking at this issue a few months ago, I created a solution based on Pluto's: PLUTO-82.

          But, there is a side-effect which I wasn't sure about how to handle. So, I started a discussion on the Pluto dev list about it which continued in private with Jeremy Boynes (who provided the solution for Pluto).

          Below you find the relevent bits from that discussion:

          -------- Original Message --------
          Subject: Re: [jira] Resolved: (PLUTO-82) PortalURL tied to single host specified in properties?
          Date: Mon, 31 Jan 2005 17:07:22 +0100
          From: Ate Douma <ate@douma.nu>
          To: pluto-dev@portals.apache.org

          David and Jeremy,

          I've been looking at this solution as I'd like to implement the same for Jetspeed-2.
          And it works, but only one way.

          If I request a secure PortletURL Jetspeed-2 nicely switches to a secure url.
          But, if I then request a PortletURL with secure="false", I'm still running in a secure mode.
          Although I indeed now am back to the non-secure (path) url again, I'm still using the
          secure port which has been changed by Tomcat after I switched to secure mode.

          I'm not sure what the expected behavior should be according to the specs
          if I request secure="false" but this solution won't help me, using a PortletURL,
          to switch back to a non-secure mode.

          How to your your opinion(s) should it be made possible for the user to
          switch back to non-secure mode?

          Regards, Ate
          ----------------------------------

          Jeremy responded (in private, I don't think he minds me making this public):

          ----------------------------------
          The servlet spec, in SRV.12.8, says that the user data constraint (the secure bit) establishes a requirement that the request be received over a protected transport, so I believe the container is forced to bump the request to satisfy that requirement. However, it does not mandate the reverse - that a insecure request be bumped down - as it just says that the (insecure) request must be accepted on any transport, so accepting it over SSL is OK. So for sure this is compatible with the servlet spec.

          How this maps to the portlet spec I am not so sure - it says setSecure indicates if the portlet URL has to be secure or not; I believe running a "not secure" request over HTTPS is OK as it is a higher level of protection. Doing what we do here still passes the TCK.

          Now there is an argument that people /want/ to downgrade the request to eliminate the SSL processing, but I believe that would apply more to URLs generated by the portal (such as images, layout) rather than to portlet content. I could well be wrong there though.


          Jeremy
          ----------------------------------

          My response to that:
          ----------------------------------
          > The servlet spec, in SRV.12.8, says that the user data constraint (the secure bit) establishes a requirement that the request be received over a protected transport, so I believe the container is forced to bump the request to satisfy that requirement. However, it does not mandate the reverse - that a insecure request be bumped down - as it just says that the (insecure) request must be accepted on any transport, so accepting it over SSL is OK. So for sure this is compatible with the servlet spec.

          Agreed.

          > How this maps to the portlet spec I am not so sure - it says setSecure indicates if the portlet URL has to be secure or not; I believe running a "not secure" request over HTTPS is OK as it is a higher level of protection. Doing what we do here still passes the TCK.

          Good to hear.

          > Now there is an argument that people /want/ to downgrade the request to eliminate the SSL processing, but I believe that would apply more to URLs generated by the portal (such as images, layout) rather than to portlet content. I could well be wrong there though.

          That is what concerns me most.
          Because if you have image URLs only defined context relative like /images/whatever
          these are retrieved under SSL processing.
          I'd say using relative URLs for images is the most common usage so this
          problem (the request URL staying under SSL) will apply to those too.

          Anyway, I'll have to think about this and will check with the other Jetspeed-2 committers
          what they have to say about it. This solution is rather nice and I don't like it to have
          to specify the default (non-SSL) port number somewhere in the portal configuration.
          ----------------------------------

          And finally, the last response from Jeremy:
          ----------------------------------
          >> Now there is an argument that people /want/ to downgrade the request to eliminate the SSL processing, but I believe that would apply more to URLs generated by the portal (such as images, layout) rather than to portlet content. I could well be wrong there though.
          >
          >
          > That is what concerns me most.
          > Because if you have image URLs only defined context relative like /images/whatever
          > these are retrieved under SSL processing.
          > I'd say using relative URLs for images is the most common usage so this
          > problem (the request URL staying under SSL) will apply to those too.
          >

          That's what I'm not sure about - these are PortletURLs so they are being generated by the portal/portlet-container anyway. There is nothing to stop you writing a image URL directly to the output stream, and I would have thought running image request through the portal was fairly inefficient and would tend to be avoided. Given the portlet application is full blown web application it can produce URLs that are relative to its context and not to the portal's.

          > Anyway, I'll have to think about this and will check with the other Jetspeed-2 committers
          > what they have to say about it. This solution is rather nice and I don't like it to have
          > to specify the default (non-SSL) port number somewhere in the portal configuration.
          >

          Yeah - there's also the problem with port redirection which means the application may not actually know the true SSL port.


          Jeremy

          Show
          Ate Douma added a comment - I forgot about this issue but with the new related JS2-275 issue I think its time to solve this (here or there). When I started looking at this issue a few months ago, I created a solution based on Pluto's: PLUTO-82 . But, there is a side-effect which I wasn't sure about how to handle. So, I started a discussion on the Pluto dev list about it which continued in private with Jeremy Boynes (who provided the solution for Pluto). Below you find the relevent bits from that discussion: -------- Original Message -------- Subject: Re: [jira] Resolved: ( PLUTO-82 ) PortalURL tied to single host specified in properties? Date: Mon, 31 Jan 2005 17:07:22 +0100 From: Ate Douma <ate@douma.nu> To: pluto-dev@portals.apache.org David and Jeremy, I've been looking at this solution as I'd like to implement the same for Jetspeed-2. And it works, but only one way. If I request a secure PortletURL Jetspeed-2 nicely switches to a secure url. But, if I then request a PortletURL with secure="false", I'm still running in a secure mode. Although I indeed now am back to the non-secure (path) url again, I'm still using the secure port which has been changed by Tomcat after I switched to secure mode. I'm not sure what the expected behavior should be according to the specs if I request secure="false" but this solution won't help me, using a PortletURL, to switch back to a non-secure mode. How to your your opinion(s) should it be made possible for the user to switch back to non-secure mode? Regards, Ate ---------------------------------- Jeremy responded (in private, I don't think he minds me making this public): ---------------------------------- The servlet spec, in SRV.12.8, says that the user data constraint (the secure bit) establishes a requirement that the request be received over a protected transport, so I believe the container is forced to bump the request to satisfy that requirement. However, it does not mandate the reverse - that a insecure request be bumped down - as it just says that the (insecure) request must be accepted on any transport, so accepting it over SSL is OK. So for sure this is compatible with the servlet spec. How this maps to the portlet spec I am not so sure - it says setSecure indicates if the portlet URL has to be secure or not; I believe running a "not secure" request over HTTPS is OK as it is a higher level of protection. Doing what we do here still passes the TCK. Now there is an argument that people /want/ to downgrade the request to eliminate the SSL processing, but I believe that would apply more to URLs generated by the portal (such as images, layout) rather than to portlet content. I could well be wrong there though. – Jeremy ---------------------------------- My response to that: ---------------------------------- > The servlet spec, in SRV.12.8, says that the user data constraint (the secure bit) establishes a requirement that the request be received over a protected transport, so I believe the container is forced to bump the request to satisfy that requirement. However, it does not mandate the reverse - that a insecure request be bumped down - as it just says that the (insecure) request must be accepted on any transport, so accepting it over SSL is OK. So for sure this is compatible with the servlet spec. Agreed. > How this maps to the portlet spec I am not so sure - it says setSecure indicates if the portlet URL has to be secure or not; I believe running a "not secure" request over HTTPS is OK as it is a higher level of protection. Doing what we do here still passes the TCK. Good to hear. > Now there is an argument that people /want/ to downgrade the request to eliminate the SSL processing, but I believe that would apply more to URLs generated by the portal (such as images, layout) rather than to portlet content. I could well be wrong there though. That is what concerns me most. Because if you have image URLs only defined context relative like /images/whatever these are retrieved under SSL processing. I'd say using relative URLs for images is the most common usage so this problem (the request URL staying under SSL) will apply to those too. Anyway, I'll have to think about this and will check with the other Jetspeed-2 committers what they have to say about it. This solution is rather nice and I don't like it to have to specify the default (non-SSL) port number somewhere in the portal configuration. ---------------------------------- And finally, the last response from Jeremy: ---------------------------------- >> Now there is an argument that people /want/ to downgrade the request to eliminate the SSL processing, but I believe that would apply more to URLs generated by the portal (such as images, layout) rather than to portlet content. I could well be wrong there though. > > > That is what concerns me most. > Because if you have image URLs only defined context relative like /images/whatever > these are retrieved under SSL processing. > I'd say using relative URLs for images is the most common usage so this > problem (the request URL staying under SSL) will apply to those too. > That's what I'm not sure about - these are PortletURLs so they are being generated by the portal/portlet-container anyway. There is nothing to stop you writing a image URL directly to the output stream, and I would have thought running image request through the portal was fairly inefficient and would tend to be avoided. Given the portlet application is full blown web application it can produce URLs that are relative to its context and not to the portal's. > Anyway, I'll have to think about this and will check with the other Jetspeed-2 committers > what they have to say about it. This solution is rather nice and I don't like it to have > to specify the default (non-SSL) port number somewhere in the portal configuration. > Yeah - there's also the problem with port redirection which means the application may not actually know the true SSL port. – Jeremy
          Hide
          Ate Douma added a comment -

          I'm very sorry to report that I've lost the changes I already made for this issue after my laptop crashed a few months ago.
          I've been looking through all my backups but alas, I have been unable to recover it.

          This has now to be redone... (for which I currently don't have the time yet)

          Show
          Ate Douma added a comment - I'm very sorry to report that I've lost the changes I already made for this issue after my laptop crashed a few months ago. I've been looking through all my backups but alas, I have been unable to recover it. This has now to be redone... (for which I currently don't have the time yet)
          Hide
          Ate Douma added a comment -

          The patch provided for JS2-275 by Santiago more or less resolved this issue already, and it is now possible to switch between secure mode and non-secure modes,
          although this currently only works using standard port transitions (80->443 and 443->80).
          See: https://issues.apache.org/jira/browse/JS2-275#action_12318383

          The solution I originally intended to provide still would be a more complete and generic one, but has become harder to implement now that there are so many different servlet paths through which the portal can be invoked. Tthere isn't enough time left before the 2.1 release to start working on that, and actually I haven't heard anyone asking for it either.

          As we now do have a solution for this issue, this isn't a bug anymore, so I'm closing this one.

          Maybe for a next release we should reconsider if the more generic solution really is needed. If so, we can create a new enhancement ticket for it.

          Show
          Ate Douma added a comment - The patch provided for JS2-275 by Santiago more or less resolved this issue already, and it is now possible to switch between secure mode and non-secure modes, although this currently only works using standard port transitions (80->443 and 443->80). See: https://issues.apache.org/jira/browse/JS2-275#action_12318383 The solution I originally intended to provide still would be a more complete and generic one, but has become harder to implement now that there are so many different servlet paths through which the portal can be invoked. Tthere isn't enough time left before the 2.1 release to start working on that, and actually I haven't heard anyone asking for it either. As we now do have a solution for this issue, this isn't a bug anymore, so I'm closing this one. Maybe for a next release we should reconsider if the more generic solution really is needed. If so, we can create a new enhancement ticket for it.

            People

            • Assignee:
              Ate Douma
              Reporter:
              Ate Douma
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development