glassfish
  1. glassfish
  2. GLASSFISH-18496

GFServerConfigProvider odd getAuthContextID ?

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: V3, v3.0.1, 3.1_b02, 3.1_ms01, 3.1_b03, 3.1_b05, 3.1_b06, 3.1_ms02, 3.1_b07, 3.1_b08, 3.1_b10, 3.1_ms03, 3.1_b12, 3.1_b13, 3.1_b14, 3.1_b15, 3.1_b16, 3.1_ms04, 3.1_b17, 3.1_b18, 3.1_b19, 3.1_b20, 3.1_ms05, 3.1_b21, 3.1_b22, 3.1_b23, 3.1_b24, 3.1_b25, 3.1_b26, 3.1_ms06, 3.1_b27, 3.1_b28, 3.1_b29, 3.1_b30, 3.1_b31, 3.1_b32, 3.1_ms07, 3.1_b33, 3.1_b34, 3.1_b35, 3.1_b36, 3.1_b37, 3.1_b38, 3.1_b39, 3.1_b40, 3.1_b41 , 3.1_b42, 3.1_b43, 3.1_ms08, 3.1, 3.1.1_b01, 3.1.1_b02, 3.1.1_b03 , 3.1.1_b04 , 3.1.1_b05, 3.1.1_b06 , 3.1.1_b07 , 3.1.1_b08, 3.1.1_b09, 3.1.1_b10, 3.1.1_b11, 3.1.1_b12, 3.1.1, 3.1.2_b01, 3.1.2_b02, 3.1.2_b03, 3.1.2_b04, 3.1.2_b05, 3.1.2_b06, 3.1.2_b07, 3.1.2_b09, 3.1.2_b10, 3.1.2_b11, 3.1.2_b12, 3.1.2_b13, 3.1.2_b14, 3.1.2_b15, 3.1.2_b16, 3.1.2_b17, 3.1.2_b18, 3.1.2_b19, 3.1.2_b20, 3.1.2_b21, 3.1.2_b22, 3.1.2_b23, 3.1.2, 4.0_b01, 4.0_b02, 4.0_b03, 4.0_b04, 4.0_b05, 4.0_b06, 4.0_b08, 4.0_b09, 4.0_b10, 4.0_b11, 4.0_b12, 4.0_b13, 4.0_b14, 4.0_b15, 4.0_b16, 4.0_b17, 4.0_b18, 4.0_b19, 4.0_b20, 4.0_b21, 4.0_b22, 4.0_b23, 4.0_b24, 4.0_b25, 4.0_b26
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      Description

      The code for getting the getAuthContextID as per the JSR196 looks very "odd" to me.

      Extract of com.sun.enterprise.security.jmac.config.GFServerConfigProvider :

      /**

      • Get the authentication context identifier corresponding to the
      • request and response objects encapsulated in messageInfo.
        *
      • @param messageInfo a contextual Object that encapsulates the
      • client request and server response objects.
        *
      • @return the authentication context identifier corresponding to the
      • encapsulated request and response objects, or null.
        *
      • @throws IllegalArgumentException if the type of the message
      • objects incorporated in messageInfo are not compatible with
      • the message types supported by this
      • authentication context configuration object.
        */
        public String getAuthContextID(MessageInfo messageInfo) {
        if (GFServerConfigProvider.HTTPSERVLET.equals(layer)) { String isMandatoryStr = (String)messageInfo.getMap(). get(HttpServletConstants.IS_MANDATORY); return Boolean.valueOf(isMandatoryStr).toString(); }

        else if (GFServerConfigProvider.SOAP.equals(layer))

        Unknown macro: { if (wsdelegate != null) { return wsdelegate.getAuthContextID(messageInfo); } return null; }

        else

        { return null; }

        }

      This will always return true or false ... which is a strange ID for a AuthContext.

      Either the code is wrong and it must be corrected, or some clarification must be written down at implementation level (IE: why are we only having two kind of AuthContextID & al in GF).

      This is put at major priority because it could endanger the JSR196 compatibility part of JavaEE compatibility.

        Activity

        Hide
        kumarjayanti added a comment -

        I would like to know your interest in looking at this code.

        The code otherwise is intentional :

        See the method :

        public static MessagePolicy[] getHttpServletPolicies(
        String authContextID) {
        if (Boolean.valueOf(authContextID)) {
        return new MessagePolicy[]

        { MANDATORY_POLICY, null }

        ;
        } else {
        return new MessagePolicy[]

        { OPTIONAL_POLICY, null }

        ;
        }
        }

        Adding a Comment on the code is definitely a good point.

        The Compatibility is not at risk because here is what the Servlet Profile of 196 says :

        3.7.1 Authentication Context Identifiers
        This profile does NOT impose any profile specific requirements on authentication context identifiers. As defined in Section 2.1.3, “Acquire AuthContext Identifier,” on page 17, the authentication context identifier used in the call to getAuthContext must be equivalent to the value that would be acquired by calling getAuthContextID with the MessageInfo that will be used in the call to validateRequest.

        Show
        kumarjayanti added a comment - I would like to know your interest in looking at this code. The code otherwise is intentional : See the method : public static MessagePolicy[] getHttpServletPolicies( String authContextID) { if (Boolean.valueOf(authContextID)) { return new MessagePolicy[] { MANDATORY_POLICY, null } ; } else { return new MessagePolicy[] { OPTIONAL_POLICY, null } ; } } Adding a Comment on the code is definitely a good point. The Compatibility is not at risk because here is what the Servlet Profile of 196 says : 3.7.1 Authentication Context Identifiers This profile does NOT impose any profile specific requirements on authentication context identifiers. As defined in Section 2.1.3, “Acquire AuthContext Identifier,” on page 17, the authentication context identifier used in the call to getAuthContext must be equivalent to the value that would be acquired by calling getAuthContextID with the MessageInfo that will be used in the call to validateRequest.
        Hide
        bjb added a comment -

        Note 2 on §1.2.3 says :
        "client runtime may be able to tell when a request is the same, based on the context (for example, stub) from which the request is made."

        Two request from different context but with value matching true will be considered as the same with the current way of doing. I understand it is a "may" and look limited to "client", but I think it should be extended to server as well.

        FYI, I am looking at the GS implementation because while implementing a JASPIC provider, I am stuck on an issue between JASPIC provider and JMAC login. Any call ends up at the default file realm !?! My understanding was that JASPIC replace the good-ole GF Realm paradigm. I've found no way to prevent jmacLogin from beeing called. It looks like I am stuck on a "Bridge profile"-like behavior for un unknown reason.

        Show
        bjb added a comment - Note 2 on §1.2.3 says : "client runtime may be able to tell when a request is the same, based on the context (for example, stub) from which the request is made." Two request from different context but with value matching true will be considered as the same with the current way of doing. I understand it is a "may" and look limited to "client", but I think it should be extended to server as well. FYI, I am looking at the GS implementation because while implementing a JASPIC provider, I am stuck on an issue between JASPIC provider and JMAC login. Any call ends up at the default file realm !?! My understanding was that JASPIC replace the good-ole GF Realm paradigm. I've found no way to prevent jmacLogin from beeing called. It looks like I am stuck on a "Bridge profile"-like behavior for un unknown reason.
        Hide
        kumarjayanti added a comment -

        If your EAR with a sun-application.xml specifies a different realm then that realm will be invoked by JMAC Login. Or if you set the default realm attribute on security-service to a different value that will also cause authentication to happen against the specified non default realm.

        Beyond that if you need flexibility in JMAC Login there is a limitation today, but if you have some suggestions on what you flexibility you want to see in there please let us know. Every container implementing JSR-196 is expected to supply its own CallbackHandler and that callbackhandler most likely will use the native facilities in the environment (in case of glassfish it is the realms).

        Alternatively since its open source you may modify the callbackhandler code for your case.

        Show
        kumarjayanti added a comment - If your EAR with a sun-application.xml specifies a different realm then that realm will be invoked by JMAC Login. Or if you set the default realm attribute on security-service to a different value that will also cause authentication to happen against the specified non default realm. Beyond that if you need flexibility in JMAC Login there is a limitation today, but if you have some suggestions on what you flexibility you want to see in there please let us know. Every container implementing JSR-196 is expected to supply its own CallbackHandler and that callbackhandler most likely will use the native facilities in the environment (in case of glassfish it is the realms). Alternatively since its open source you may modify the callbackhandler code for your case.
        Hide
        kumarjayanti added a comment -

        the AuthConfigProvider can return any value for authcontext that
        makes sense to it, and that satisfies the rule that you have already identified.

        The true/false value satisfies those rules, and is sufficient for our CFAuthConfigProvider to select an
        appropriate authmodule. In fact, I think our AuthConfigProvider is so simple, that it would have worked
        fine, even if it had returned a constant auth-context value.

        another authconfig provider might choose to return the request url, and then it could internally
        map different auth modules to different urls (within the same auth-context).

        Show
        kumarjayanti added a comment - the AuthConfigProvider can return any value for authcontext that makes sense to it, and that satisfies the rule that you have already identified. The true/false value satisfies those rules, and is sufficient for our CFAuthConfigProvider to select an appropriate authmodule. In fact, I think our AuthConfigProvider is so simple, that it would have worked fine, even if it had returned a constant auth-context value. another authconfig provider might choose to return the request url, and then it could internally map different auth modules to different urls (within the same auth-context).

          People

          • Assignee:
            kumarjayanti
            Reporter:
            bjb
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: