INTERNAL: Add ScramSaslClient

[namsic]

🔗 Related Issue

• jam2in/arcus-works#672

⌨️ What I did

• Scram 인증을 위한 ScramSaslClient를 구현합니다.
• com.bolyartech.scram_sasl 의존성을 추가합니다.
• Kafka의 ScramSaslClient 구현을 참고하였습니다.
• 기존 java client의 코드 배치나 스타일과 차이가 있는지도 확인해 주시면 좋겠습니다.

---

• 대략 아래와 같은 구현으로 SCRAM 인증 사용하여 캐시 서버와 연결할 수 있습니다.
• ScramSaslClientProvider.initialize(); 호출한 다음부터 SCRAM-SHA-256 mechanism 사용할 수 있게 되는데,
  어느 위치에 두는 것이 좋은지 잘 모르겠어서, 우선은 라이브러리 외부에서 직접 호출하는 형태로 테스트했습니다.

  private static final String[] mechanism = {"SCRAM-SHA-256"};
  private static final String username = "user01";
  private static final String password = "passwd01";

  private ArcusClient newClient(boolean useCluster, boolean useBinaryProtocol) throws IOException {
    ConnectionFactoryBuilder cfb = new ConnectionFactoryBuilder()
        .setAuthDescriptor(new AuthDescriptor(mechanism, 
        new PlainCallbackHandler(username, password)));
    
    if (useBinaryProtocol) {
      cfb.setProtocol(Protocol.BINARY);
    }

    if (useCluster) {
      return ArcusClient.createArcusClient("127.0.0.1:2181", "servicecode-01", cfb);
    } else {
      return new ArcusClient(cfb.build(), AddrUtil.getAddresses("127.0.0.1:11211"));
    }

  }

  @Test
  public void testSasl() throws Exception {
    ScramSaslClientProvider.initialize();

    ArcusClient mc = newClient(true, true);
    Thread.sleep(10000);

    assertTrue(mc.set("namsic:kv01", 30, "value01").get());
    assertEquals("value01", mc.get("namsic:kv01"));
  }

---

이 PR이 반영되는 시점부터 binary protocol 사용 시 SCRAM-SHA-256 사용할 수 있게 됩니다.
ascii protocol에서 SASL 인증 사용하려면 관련 operation을 구현해야 합니다.

arcus-java-client/src/main/java/net/spy/memcached/protocol/ascii/AsciiOperationFactory.java

Lines 149 to 155 in 5c13575

	public SASLStepOperation saslStep(SaslClient sc, byte[] challenge, OperationCallback cb) {
	throw new UnsupportedOperationException();
	}
	public SASLAuthOperation saslAuth(SaslClient sc, OperationCallback cb) {
	throw new UnsupportedOperationException();
	}

[uhm0311]

필드가 선언된 타입이 ScramClientFunctionalityImpl인 상태인데, 선언 타입으로 ScramClientFunctionality를 사용하면 구현에 문제가 있나요?

[namsic]

ScramClientFunctionality 사용하도록 변경했습니다.

그 외에도 Java의 일반적인 구현 패턴과 관련하여 문제가 있는 부분은 없는지 신경써서 확인해 주시면 좋겠습니다.

• class 위치(package)는 적절한지
• 멤버 변수에 this.를 붙이는 경우 / 생략하는 경우
• 기타 전반적인 코드 구조 및 코드 포맷

[uhm0311]

코드 스타일은 @jhpark816 님이 봐주실 겁니다.

[uhm0311]

serverNonce의 검증 부분도 ScramClientFunctionalityImpl 객체가 알아서 진행해주나요?

[namsic]

kafka의 아래 구현에 대응하는 로직이 있는지를 확인하는 것이지요?

                case RECEIVE_SERVER_FIRST_MESSAGE:
                    this.serverFirstMessage = new ServerFirstMessage(challenge);
                    if (!serverFirstMessage.nonce().startsWith(clientNonce))
                        throw new SaslException("Invalid server nonce: does not start with client nonce");

아래와 같이 처리됩니다.
https://github.com/ogrebgr/scram-sasl/blob/5f3d1cbf71e534170c9f28fcee7fa8ec6bf77291/lib/src/main/java/com/bolyartech/scram_sasl/client/ScramClientFunctionalityImpl.java#L118

        Matcher m = SERVER_FIRST_MESSAGE.matcher(serverFirstMessage);
        if (!m.matches()) {
            mState = State.ENDED;
            return null;
        }

        String nonce = m.group(1);

        if (!nonce.startsWith(mClientNonce)) {
            mState = State.ENDED;
            return null;
        }

예외를 던지지 않고 internal state 변경 후 null 반환하도록 되어 있는데,
호출하는 측에서 null check 후 예외 던지도록 변경해야 하는지는 확인이 필요해 보입니다.

[uhm0311]

호출하는 측에서 null check 후 예외 던지도록 변경해야 하는지는 확인이 필요해 보입니다.

확인해보고 알려주시면 리뷰 계속 진행하겠습니다.

[namsic]

null check 및 예외 발생시키지 않고 진행하면, 서버에 sasl 명령을 empty body와 함께 전송합니다.
그러면 서버 입장에서는 클라이언트가 올바른 데이터를 응답하지 않은 것이므로 인증 실패 처리합니다.

예외 발생시키면 Operation의 initialize()에서 RuntimeException 발생하게 되는데,
예외 발생 이후 구체적으로 어떻게 동작하게 되는지까지는 잘 모르겠지만 서버에 요청을 전송하지 않을 것입니다.

  @Override
  public void initialize() {
    try {
      byte[] response = buildResponse(sc);
      String mechanism = sc.getMechanismName();

      prepareBuffer(mechanism, 0, response);
    } catch (SaslException e) {
      // XXX:  Probably something saner can be done here.
      throw new RuntimeException("Can't make SASL go.", e);
    }
  }

결국에는 둘 모두 인증 과정이 종료되는 것은 동일하며, 후자의 동작이 더 맞는 것 같아서 예외 던지도록 변경합니다.

[uhm0311]

develop 브랜치 최신 기준으로 Operation.initialize()는 크게 3군데에서 불립니다.

• 응용의 Worker Thread
• 자바 클라이언트의 IO Thread
• 자바 클라이언트의 Auth Thread

1번은 응용의 워크로드에 따라 다르므로 넘어가겠습니다.
2번은 IO Thread가 정지되고, 아무런 연산 요청도 보내지 못해서 모든 캐시 연산이 Timeout 처리될 것 같습니다.
3번은 어떤 영향이 있을지 잘 모르겠습니다.

@oliviarla 2번의 영향에 대한 제 설명이 맞는지 확인해주시고, Exception을 전파하는 것과 하지 않는 것 중 무엇이 좋을지 검토해주세요.
@namsic 3번의 영향이 어떤지 설명해주세요.

[namsic]

• FEATURE: Implement SASL authentication for the ASCII protocol #942 에서 처리 예정이므로 닫습니다.