Jetspeed 2
  1. Jetspeed 2
  2. JS2-238

Subject object is abandoned after the JAAS authentication

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.2.0
    • Component/s: Security, SSO
    • Labels:
      None
    • Environment:
      JetSpeed-2.0-M3-dev, JDK1.4.2_07, Windows XP SP2

      Description

      I want to add a customized JAAS LoginModule to implement single sign-on. So I found the JAAS configuration file, login.conf, change it like this:

      Jetspeed {
      org.apache.jetspeed.security.impl.DefaultLoginModule required debug=true;
      com.xxx.xxx.LoginModelImpl optional debug=true;
      };

      I debug my LoginModuleImpl, everything is ok, I add my principal object and a credential object to the Subject object. But when I want to retrieve them back in the portlet, I just found to principal and credential created by DefaultLoginModule.
      Mine disappeared.

      So I look through all the source code of J2. I found that the Subject object created by LoginContext is abandoned after the successfully login. The first request after the login will new a Subject object in the SecurityValve, but this subject object is not created by LoginContext, but UserManager. Then put it into session. That is the reason I lost all my own principal and credential.

      I think that is not a good idea to create a new subject object after the login. It make JAAS authentication meaningless. Why don't we just put the subject object created by LoginContext into session with the attribute "org.apache.jetspeed.security.subject", right after the login.

        Activity

        Hide
        Ate Douma added a comment -

        Works at least for Tomcat and we now have extension points available to (potentially) support other containers as well.

        Note: this feature is currently still under the security_refactoring branch but that will soon be promoted to trunk again.

        Show
        Ate Douma added a comment - Works at least for Tomcat and we now have extension points available to (potentially) support other containers as well. Note: this feature is currently still under the security_refactoring branch but that will soon be promoted to trunk again.
        Hide
        Ate Douma added a comment -

        I've finally discovered a way to solve this issue with the new security api we're currently implementing for Jetspeed 2.2, at least on Tomcat.

        The Tomcat JAASRealm implementation actually will take use the Jetspeed provided user principal for request.getUserPrincipal().
        As we already provide the UserSubjectPrincipal wrapper as user principal, getting hold of the Jetspeed provided subject is easy and so doesn't need to be loaded/created twice (on Tomcat).

        I've extended the SecurityValveImpl to first check if the current request.getUserPrincipal() does implement UserSubjectPrincipal and then simply return its containing (Jetspeed) Subject.

        And, if it doesn't (like maybe on other containers), a protected Subject resolveSubjectFromContainerPrincipal(RequestContext request, Principal userPrincipal) method will be called which can be
        extended to provide an alternative way of getting hold of the UserSubjectPrincipal (if exist and possible), which currently simply returns null.

        Show
        Ate Douma added a comment - I've finally discovered a way to solve this issue with the new security api we're currently implementing for Jetspeed 2.2, at least on Tomcat. The Tomcat JAASRealm implementation actually will take use the Jetspeed provided user principal for request.getUserPrincipal(). As we already provide the UserSubjectPrincipal wrapper as user principal, getting hold of the Jetspeed provided subject is easy and so doesn't need to be loaded/created twice (on Tomcat). I've extended the SecurityValveImpl to first check if the current request.getUserPrincipal() does implement UserSubjectPrincipal and then simply return its containing (Jetspeed) Subject. And, if it doesn't (like maybe on other containers), a protected Subject resolveSubjectFromContainerPrincipal(RequestContext request, Principal userPrincipal) method will be called which can be extended to provide an alternative way of getting hold of the UserSubjectPrincipal (if exist and possible), which currently simply returns null.
        Hide
        Ate Douma added a comment -

        Although I recognize this problem, I can't find it critical.

        There is no JAAS API which provides access to a logged on Subject other than from the LoginModule itself.

        Tomcat specifically doesn't provide access to it either so we would have to extend the Tomcat JAASRealm for it.
        And other App Servers have again other solutions.

        Doing the LoginContext.login() once more doesn't strike me as a sound solution either.

        Anyway, until someone comes up with a sound solution/patch which will work generically and/or is easy to extend for different App Servers, I'm gonna downgrade this issue to Minor.

        Show
        Ate Douma added a comment - Although I recognize this problem, I can't find it critical. There is no JAAS API which provides access to a logged on Subject other than from the LoginModule itself. Tomcat specifically doesn't provide access to it either so we would have to extend the Tomcat JAASRealm for it. And other App Servers have again other solutions. Doing the LoginContext.login() once more doesn't strike me as a sound solution either. Anyway, until someone comes up with a sound solution/patch which will work generically and/or is easy to extend for different App Servers, I'm gonna downgrade this issue to Minor.
        Hide
        Jian Liao added a comment -

        Maybe we should extend the Tomcat JAAS realm to achieve it. Or we create a special
        I think there two ways to achieve it:

        1. Extend the Tomcat JAAS realm, put subject into session with attribute "org.apache.jetspeed.security.subject" immediately after the successfully login.

        2. Call LoginContext.login() again in SecurityValve.

        Show
        Jian Liao added a comment - Maybe we should extend the Tomcat JAAS realm to achieve it. Or we create a special I think there two ways to achieve it: 1. Extend the Tomcat JAAS realm, put subject into session with attribute "org.apache.jetspeed.security.subject" immediately after the successfully login. 2. Call LoginContext.login() again in SecurityValve.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development