Uploaded image for project: 'Livy'
  1. Livy
  2. LIVY-595

Replace DEGEST-MED5 with GSSAPI(Kerberos) in the RPC sasl

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.5.0
    • Fix Version/s: None
    • Component/s: RSC, Server
    • Labels:
      None
    • Flags:
      Patch, Important

      Description

      This is a English version

      DIGEST-MD5 has been considered as a non-secure encryption mechanism in the industry, so according to the company's security requirements, it is replaced by GSSAPI (kerberos authentication);

      Initially, I just changed the configuration value of livy. rsc. rpc. sasl. mechanisms to GSSAPI, but reported an error: Failed to find any Kerberos credentails; so I started my painful journey to modify the source code (thank you very much if you have a feasible configuration plan to inform). The specific steps are as follows:

       

      1) In the Rpc and RpcServer classes, create LoginContext and login when creating client and server for sasl, and encapsulate Sasl. createSaslServer and Sasl. createSaslClient with Subject. doAs.

      2) The parameters of Sasl. createSaslServer and Sasl. createSaslClient mainly change protocol to the user name of principal (i.e. the first paragraph of principal), and server Name to the qualified name of principal (i.e. the second paragraph of principal). Other parameters remain unchanged and login succeeds.

       

      Question: Client and server can communicate, the first sendHello can succeed, but the second time Livy returns token to driver, driver unwrap error: Caused by GSSException: Defective token detection (Mechanism level: Wrap Token (new format): Cannot read all 12 bytes needed to form this token!)

       

      My analysis: I tracked livy's log. The byte array returned to driver is null and sent to driver by Chanel Rpc.SaslMessage object, when unwrap, {data is [20, 1, 0, 0], offset is 0, len is 4}, driver unwrap will report an error.

       
       
      The problem is too difficult to solve, I need help now. thinks everyone.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              yc_huawei yanchao
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 168h
                168h
                Remaining:
                Remaining Estimate - 168h
                168h
                Logged:
                Time Spent - Not Specified
                Not Specified