Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2, 2.1.1, 2.1.4, 2.2
    • Fix Version/s: 2.2
    • Component/s: Tomcat
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      Several problems:
      1. UserDataPermissions are not getting evaluated by jacc due to the check for Subject in handler data.
      2. Subject is never set into handler data (also a problem in jetty, dunno about openejb).

      3. TomcatGeronimoRealm is calling ContextManager.setCallers before permission checks. This is wrong.

        Activity

        Hide
        David Jencks added a comment -

        This is as fixed as its likely to get. run-as roles are pretty well unspecified so anyone using them doesn't have too much to complain about when something goes wrong. Maybe servlet 3 will make rules clearer.

        Show
        David Jencks added a comment - This is as fixed as its likely to get. run-as roles are pretty well unspecified so anyone using them doesn't have too much to complain about when something goes wrong. Maybe servlet 3 will make rules clearer.
        Hide
        Jarek Gawor added a comment -

        Updating versions as it probably will not get fixed for 2.1.4.

        Show
        Jarek Gawor added a comment - Updating versions as it probably will not get fixed for 2.1.4.
        Hide
        David Jencks added a comment -

        I'm sure this won't get fixed in 2.0.x and doubt it will get fixed in 2.1.x

        Show
        David Jencks added a comment - I'm sure this won't get fixed in 2.0.x and doubt it will get fixed in 2.1.x
        Hide
        Donald Woods added a comment -

        SVN updates need to be ported to 2.1.4 and 2.0.3

        Show
        Donald Woods added a comment - SVN updates need to be ported to 2.1.4 and 2.0.3
        Hide
        Joe Bohn added a comment -

        move fix version to 2.1.3 from 2.1.2

        Show
        Joe Bohn added a comment - move fix version to 2.1.3 from 2.1.2
        Hide
        David Jencks added a comment -

        work done on this issue in code:
        trunk rev. 670236
        Improved run-as tests in testsuite
        trunk rev. 670237

        The behavior in the tests agrees between jetty and tomcat but I don't think it's right. With this scenario:
        user logs in in role foo
        Servlet1 configured with run-as role baz
        forwards to servlet2 with no run-as role
        calls ejb
        the ejb sees only role foo. In other words forwarding to servlet 2 has erased the run-as information from servlet 1.

        In addition there's a questionable case:
        in the above scenario, should servlet 2 see foo or baz? Currently it sees foo.

        -------------------------------------------------

        (1) is fixed; we install either the actual or default subject before checking WebUserDataPermissions and never call the non-jacc tomcat code
        (2) is invalid, the Subject comes directly from ContextManager
        (3) seems to be the only way to get form auth to work. I think it's causing the behavior I think is wrong noted above.

        Show
        David Jencks added a comment - work done on this issue in code: trunk rev. 670236 Improved run-as tests in testsuite trunk rev. 670237 The behavior in the tests agrees between jetty and tomcat but I don't think it's right. With this scenario: user logs in in role foo Servlet1 configured with run-as role baz forwards to servlet2 with no run-as role calls ejb the ejb sees only role foo. In other words forwarding to servlet 2 has erased the run-as information from servlet 1. In addition there's a questionable case: in the above scenario, should servlet 2 see foo or baz? Currently it sees foo. ------------------------------------------------- (1) is fixed; we install either the actual or default subject before checking WebUserDataPermissions and never call the non-jacc tomcat code (2) is invalid, the Subject comes directly from ContextManager (3) seems to be the only way to get form auth to work. I think it's causing the behavior I think is wrong noted above.

          People

          • Assignee:
            David Jencks
            Reporter:
            David Jencks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development