컨텍스트 : SSO로 여러 애플리케이션을 지원하는 클라우드 플랫폼을 만들고 있습니다. 내가 인증을 위해과 에 대한 키 클로크를 사용하고 있습니다. (API 게이트웨이) Keycloak 스프링 보안 어댑터을 통해 Netflix Zuul을 인증합니다.마이크로 서비스에서 마이크로 서비스 호출, 대기열 메시지로부터의 인증
각 마이크로 서비스에는 올바른 JWT가 포함 된 Authorization 헤더가 필요하며이 헤더에서 요청을 처리 할 사용자 이름 (하위)이 사용됩니다. 각 microservice-microservice 호출은 먼저 Netflix Zuul을 통과해야하며, Stateless 헤더를 전달하여 상태 비 저장 유효성 검사를 유지해야합니다. 이 전략은 모든 마이크로 서비스가 간접적으로 마이크로 서비스를 호출하는 사용자 (하위)를 알 수 있도록합니다.
문제점/질문 1 : 마이크로 서비스가 대기열 메시지에서 호출되는 경우 어떻게됩니까? 내가 가진 한 가지 아이디어는 메시지 + userInfo와 관련된 정보를 대기열에 저장하고 그런 종류의 메시지를 처리하는 전용 마이크로 서비스를 작성하는 것입니다.이 특수 마이크로 서비스는 대기열에서 userInfo를 읽고 메시지를 처리해야합니다. .
업데이트 1 : 다른 포럼의 전자 메일 회신에 따라 JWT를 대기열에 저장하는 것은 쉽게 채굴 될 수 있으므로 좋지 않습니다. 이전 특별 microservice은 헤더에 JWT를 받게 될 또 다른 정상 microservice를 호출하고자하는 경우 발생하는하지만, :
문제/질문이? 이 특수 마이크로 서비스가 사용자 자신을 가장하고 정규 마이크로 서비스를 호출 할 수있는 JWT를 만들어야합니까?
내가 생각한 또 다른 해결책은 원래 JWT를 대기열에 저장하는 것이지만 나중에 대기열에서 특수 마이크로 서비스를 호출하면 어떻게됩니까? JWT가 더 이상 유효하지 않으면 (만료 됨) 호출 된 마이크로 서비스가 요청을 거부합니까?
가능한 해결책 :
내가 내 사용자 (인증 코드 흐름) 내 서비스 (클라이언트 자격 증명을 부여)에서 요청을 인증한다 (주앙 안젤로 토론마다 업데이트, 아래 참조) 두 요청 모두 페이로드에 사용자 정보를 포함해야합니다. 요청이 사용자로부터 왔을 때 페이로드 사용자 정보가 JWT 소유권과 일치하는지 확인해야합니다. 요청이 서비스에서 오는 경우 해당 서비스를 신뢰해야합니다 (내 통제하에있는 한).
대단히 감사합니다. 감사.
안녕하세요 João, 1) 마이크로 서비스는 항상 JWT는 사용자 또는 다른 서비스에서 제공됩니다. 방금 테스트를 수행 한 결과, 사용자와 비교 한 마이크로 서비스에 대한 JWT의 차이점 중 일부는 클레임을 포함하지 않으며 JWT에 "클라이언트 ID"필드가 포함되어 있으면 "clientId" clientId "는 사용자가 아니라 서비스입니다. 또는 "aud"필드에 의지 할 수 있습니다. "aud"가 사용자를 인증하기 위해 클라이언트 이름에 해당하면 사용자가 아닌 경우 사용자가 다른 서비스입니다. –
2) 호출이 사용자 ("aud"또는 "aud")인지 확인하면 서비스가 투명한 방식 (서비스 또는 사용자 호출)으로 요청을 처리 할 수 있도록 페이로드에 항상 userId를 보내야하는 것으로 보입니다. "clientId"페이로드 필드를 "하위"또는 "preferred_username"으로 확인하여 페이로드의 값이 해당 작업을 수행하는 사용자와 일치하는지 확인할 수 있습니다. 하지만 서비스의 경우 페이로드에 지정된 사용자를 신뢰하면됩니다. –
그렇습니다. 하나의 접근 방식 일 것입니다. 사용자가 입력 할 때 입력 내용의 유효성을 검사하여 다른 사용자를 위조하지 않고 자신의 서비스에서 왔을 때 신뢰하도록하십시오. 모든 마이크로 서비스가 사용자의 통제하에 있다고 가정하면 적절한 접근 방법 인 것 같습니다. 또한 액세스 토큰 및/또는 새로 고치기 토큰을 저장하는 것이 나중에 사용자가 오프라인 일지라도 나중에 전화를 수행 할 수 있도록하는 것보다 간단합니다. –