2011-03-15 4 views
11

웹 서비스에서 인증 및 권한 부여를 수행하는 가장 좋은 방법은 무엇입니까?JAX-WS, 인증 및 권한 부여 - 방법?

역할 기반 액세스 제어가 필요한 일련의 웹 서비스를 개발 중입니다. 메트로 SOAP, EJB가없는 단순한 Java 사용하기.

  • 사용자 이름과 암호를 사용하여 한 번만 사용자를 인증하고 싶습니다. 데이터베이스와 일치시킵니다. 후속 통화에서.
  • 나는 어떤 종류의 세션 관리를 사용하고 싶습니다. 로그인시 클라이언트에 검색된 세션 ID가 모두 호출로 제공 될 수 있습니다.

지금까지 :

  • 읽기 authentication using a database -하지만 응용 프로그램 수준 유효성 검사를 할;
  • Read application authentication with jax-ws -하지만 인증 메커니즘을 매번 수행하고 싶지는 않습니다.

  • SOAP 처리기를 사용하여 모든 메시지를 가로 채고, 메시지와 함께 제공된 일부 세션 식별자 토큰을 사용하여 핸들러에서 권한 제어를 수행 할 수 있다고 생각합니다.이 식별자는 저장된 식별자와 일치 할 수 있습니다. 로그인 웹 메소드에서 데이터베이스.

    편집

을 :

내가 아직 몇 가지 질문이 있습니다

  • 어떻게 웹 메소드의 이름을 알 수가 호출되는?
  • 어떤 토큰을 사용해야합니까?
  • 통화간에이 토큰을 전달하는 방법은 무엇입니까? 대답 ag112 때문에 @의

편집 2

: 내가 글래스 피시를 사용하고

.

WS-Policy와 WS-Security를 ​​사용하여 메시지를 암호화하고 서명합니다. 상호 인증서 인증 사용. 메시지 수준의 사용자에 대한 인증 및 권한 부여와 함께 응용 프로그램 간의이 메시지 수준 보안을 보완하고 싶습니다.

저는 서비스를 개발 중이고 클라이언트를 거의 알지 못하고 단지 다른 언어로 만들 수 있습니다.

이 시점에서 가장 중요한 것은 사용자를 인증하고 인증하기 위해해야 ​​할 일을하는 것입니다. 클라이언트 응용 프로그램을 구현하는 가장 쉬운 방법입니다.

+1

질문에 대한 답변을 알고 계십니까? BTW, 좋은 질문이라고 생각합니다. 응답이 많지 않은 것에 놀랐습니다. JAAS에 익숙하지 않지만 http://drdobbs.com/web-development/208402532에서이 기사를 찾았습니다. 네가 올바른 방향으로 갔나 봐. 건배! –

+0

마침내 도움을 주셔서 감사합니다! 나는 네가 말한대로 대답을 만들었다. 가능한 한 빨리 당신이 추천 한 페이지를 읽어 주실 것입니다, 다시 한번 감사드립니다! –

답변

2

모든 도움을 얻은 후에, 나는이 대답을 단순화하고 토론 된 모든 아이디어를 요약합니다.

질문

2 개 요건이 있습니다

  • 메시지 수준의 보안을;
  • 1 회 인증.

ag112 도움말을 사용하면이 방법을 사용하기가 어렵습니다.따라서 결론은 다음과 같습니다.

  • 메시지 수준 보안의 경우 사용자마다 자격 증명 (SOAP 헤더에 넣음)을 보내십시오.
  • 한 번만 인증하려면 전송 수준 보안을 사용하고 세션 관리를 수행하십시오.

나는 메시지 레벨이 가장 큰 필요 조건 이었기 때문에 첫 번째 것을 선호했다.

0

으로 지금까지 진행에, 나는 내 자신의 질문에 대답 조언 @unhillbilly 다음, 아무 대답이 없었다 :

어떻게 호출되는 웹 방법 의 이름을 알고;

SOAP 처리기를 사용하여 본문의 첫 번째 요소의 이름을 찾습니다.

어떤 종류의 토큰을 사용해야합니까?

각 세션을 나타내는 128 비트 토큰을 사용하기로했습니다. Webservices는 계속 세션없이 진행되며 핵심은 인증 용도로 사용됩니다.

통화간에이 토큰을 전달하는 방법.

결과 웹 페이지에는 토큰이 있으며 이후의 각 호출에서 토큰은 매개 변수입니다.

더 나은 대답이 있습니까?

+1

관련 매개 변수없이 API를 오염시킬 필요없이 메시지 헤더에 토큰을 저장할 수 있습니다. 이것이 대부분의 프레임 워크에서 처리하는 방법입니다. – mericano1

1

OpenEJB으로 이동할 수도 있습니다.

WSAS와 함께 JAAS를 사용했습니다.

링크가 유용하기를 바랍니다.

4

@ 루이스 : 여기 내 의견이 있습니다.

문제에 대한 정확한 해결책은 기대하는 웹 서비스 클라이언트의 종류, 웹 서비스 클라이언트 시스템, 응용 프로그램 서버 등을 제어 할 수 있는지에 따라 다르지만, 웹을 제어 할 수 없다고 가정하면 서비스 클라이언트는 HTTP 전송을 통한 SOAP 메시지 일뿐입니다. 여기에 가능한 솔루션이 있습니다.

메시지 수준 또는 전송 수준에서 세션 관리 & 인증을 수행 할 수 있습니다. 즉, SOAP 토큰에 세션 토큰 및 인증 토큰 정보가 있거나 표준 HTTP 세션 및 HTTP 인증 메커니즘을 사용할 수 있습니다.

물론 전송 계층 솔루션이 HTTP 인 경우 전송 계층 솔루션은 훨씬 간단하고 업계 표준입니다. 메시지 수준의 경우 ws-security와 같은 ws 사양을 사용할 수 있습니다. 각 웹 서비스 요청은 고유 한 HTTP URI로 식별되는 간단한 HTTP GET/POST입니다. 일반적으로 jax-ws 메트로 환경에서 WSServlet은 모든 웹 서비스 호출에 대한 엔트리 서블릿이며 결국 올바른 서비스 공급자 구현 클래스에 대한 호출을 위임합니다. 응용 프로그램이 웹 서버에 배포되므로 J2EE 웹 컨테이너에서 제공하는 모든 세션 및 인증 기능을 활용할 수 있습니다.

역할 기반 액세스 제어를 찾고 있으므로 web.xml에서 표준 <web-resource-collection> 표준을 사용하여 특정 HTTP URI의 경우 어떤 역할을 수행할지 지정합니다. 인증을 할 수있는 JAAS 로그인 모듈을 사용하여 JAAS 주체에 역할을 채 웁니다. SOAP XML에 사용자 이름/암호가 제공되면 JAAS 로그인 모듈은 SOAP XML을 검색/구문 분석하여 해당 정보를 검색 할 수도 있습니다. JAAS/app 서버는 auth 토큰을 자동으로 생성하여 쿠키로 저장하므로 이후의 각 요청이 인증 프로세스를 다시 거칠 필요가 없습니다. 이것은 모두 J2EE 표준입니다. 이것에 관해 인터넷에서 많은 도움을 얻을 수 있습니다.추가 세부 정보를 제공 할 수 있도록 앱 서버를 알려주십시오.

SOAP 메시지 레벨 세션 관리, 인증 & 인증 프로세스를 사용하려는 경우 자세한 내용을 제공하기 위해 클라이언트 측에 대한 자세한 정보를 얻을 수 있습니까?

EDIT1 : 메시지 보안, 즉 암호화와 서명은 각 메시지는 서버와 클라이언트 사이를 이동하는 일이 필요합니다 : 그럼 내 더 생각 여기에, 귀하의 추가 입력을 기반으로. 여기서 메시지 인증 - 일단 수행하고 이후 호출을 위해 클라이언트에 세션 토큰/인증 토큰을 제공하려는 경우.

여전히 남아 있습니다. 첫 번째 인증의 SOAP 응답에 고유 한 세션 식별자를 넣으면 클라이언트가 SOAP 응답 XML을 구문 분석하고 클라이언트가 이후 SOAP 요청에서 매번 세션 식별자를 보내야합니다. 또는 세션 관리를 클라이언트에 투명하게 유지하려면 클라이언트에서 사용자 이름/암호 토큰을 처음으로 보내야하며 이후 호출에 사용자 이름/암호 토큰이 필요하지 않습니다. 이 경우 전송 기반 세션 관리에 의존해야합니다. HTTP 쿠키

이제 가장 적합한 것은 사용 사례에 따라 다릅니다. 예상되는 유스 케이스 흐름을 알려주시겠습니까? 다른 시스템 (웹 서비스 클라이언트)이 시스템에 둘 이상의 서비스 호출을하는 방법은 무엇입니까? 다른 시스템 사용자가 주도하고 있습니까/일부 백그라운드 프로세스입니까? 첫 번째 서비스 호출만으로 인증 프로세스를 거치는 정확한 요구 사항은 무엇입니까?

추 신 : Glassfish 서버는 메시지 수준 인증을 자동으로 활성화/비활성화하는 메시지 인증 공급자를 구성하는 방법을 제공합니다.

EDIT2 : 클라이언트 응용 프로그램에 사용자 자격 증명을 저장하고 웹 서비스 서버에 해당 사용자 자격 증명이 필요하지 않은 것으로 알고 있습니다. OAuth는 사이트 A가 사이트 B에서 사용자의 개인 데이터에 액세스 할 수 있도록하는 공개 표준 프로토콜입니다. 사이트 A는 특정 만료 시간이있는 인증 토큰을 얻습니다. 따라서 사용자 자격 증명 또는 jsession ID의 암호화 된 토큰을 포함하는 토큰을 사용하면 재 인증이 필요하지 않습니다. 클라이언트 응용 프로그램 쪽에서 토큰을 유지할 위치 만 결정하면됩니다. 전송이 HTTP 프로토콜 인 경우 토큰을 쿠키로 유지할 수 있습니다.

매번 사용자 인증 정보를 전달하는 것이 쉽고 간단 해 보입니다.

+0

감사합니다. 내 질문을 업데이트했습니다. –

+0

@ 루이스 피 : 자세한 정보 및 쿼리 업데이트 :) – ag112

+0

고객이 다양한 서비스를 사용합니다. 단일 시간 인증에 대한 내 생각은 클라이언트 응용 프로그램이 사용자에게 자격 증명을 요청할 수 있도록 허용하고이를 저장할 필요가 없었습니다. OAuth와 같은 것 (나는 생각한다). 그러나 모든 호출에서 사용자 이름/암호를 보내는 것이 더 쉬울 수도 있고이를 메시지 수준 보안에 통합 할 수도 있습니다. –

관련 문제