2009-04-07 6 views
1

웹 서비스가 바깥 쪽을 향하고 있지만 유효 한 클라이언트에서 요청이 왔는지 확인하기 위해 확인 시스템을 생성해야합니다. 웹 서비스에 대한 클라이언트 고유의 확인 번호 생성

는 이제 다음과 같이 원래의 웹 서비스가 정의되어 있다고 가정 해 봅시다 :

[OperationContract] 
public void Service.RequestMethod (string clientId, int reqNumber, 
    string reqText) 
{ 
    // do stuff with the parameters 
} 

내가 요청이 실제로 clientId 매개 변수에 의해 지정된 클라이언트에서 온 있는지 확인하려면.

현재 나의 계획은 다른 매개 변수를 메서드 서명에 추가하여 체크섬을 제공하는 것입니다.

[OperationContract] 
public void Service.RequestMethod (string clientId, int reqNumber, 
    string reqText, string reqChecksum) 
{ 
    // verify reqChecksum, then 
    // do stuff with the parameters 
} 

나는 체크섬이 승인 된 클라이언트에 의해 계산 된 것을 확인하는 기능이 필요합니다. reqNumberreqText 매개 변수와 클라이언트와 서버에서 모두 알 수있는 클라이언트 별 "암호"로 계산해야합니다.

사실상, 그것은해야한다 :

private bool VerifyChecksum(int reqNumber, string reqText, 
    string clientPassword, string reqChecksum) 
{ 
    // hash reqNumber, reqTxt, and clientPassword 
    // ensure it matches reqChecksum 
} 

사람이 해시 함수 또는 전체 모델에 대한 제안 사항이 있습니까?

메시지 별, 클라이언트 별 및 추측하기 어려움 (높은 엔트로피)이 필요합니다.

답변

1

아마도 MAC 일종의 제품을 찾고 계실 것입니다. MD5와 같은 것. MD5의 전반적인 개념은 "일부"데이터에 적용하여 가치를 얻는 것입니다. "일부 데이터"부분이 모든 사람에게 알려지지 않는 한 값을 재현하는 것은 거의 불가능합니다.

+0

나는 그것이 뭔가 특별한 것으로 불릴 것이라고 생각했습니다. 감사. – Damovisa

1

왜 표준 웹 서비스 인증 방법 중 하나를 사용하지 않습니까? 널리 알려지고 널리 구현 된 솔루션을 선택할 수 있으며 매개 변수와 인증 정보를 모두 전달하여 인터페이스를 방해하지 않습니다.

인증 된 클라이언트가 둘 이상의 'clientId'를 전달할 수있는 경우 여전히 인증 문제가있을 수 있지만 여기에도 많은 알려진 해결책이 있으며 이는 전적으로 귀하의 측면입니다. 예를 들어 수용 가능한 모든 (userId, clientId, methodname) 조합을 나열하고 다른 모든 것을 금지하는 ACL 구현까지 갈 수 있습니다.

+0

좋은 제안이지만 기존 인증 방법을 사용하는 것은 어려울 수 있습니다. 메소드가 여러 위치에서 다양한 방법 (SOAP, REST, Remoting)으로 호출 될 가능성이 있습니다. 자유롭게 접근 할 수있는 한 "암호"가 목표입니다 ... – Damovisa