2011-02-06 6 views
3

레거시 시스템에서 호스팅되는 서비스를 노출하기 위해 REST 서비스 레이어를 개발할 계획입니다. 이러한 서비스는 기존의 웹 응용 프로그램과 기본 휴대폰 응용 프로그램에서 사용됩니다.상태 기반 웹 서비스 보안

이 레거시 시스템은 초기 사용자 이름 + 비밀번호 인증 (5 초에서 10 초까지 걸릴 수있는 프로세스)이 필요한 방식으로 보호됩니다. 초기 인증 후 시간 제한된 토큰이 리턴됩니다. 이 토큰은 이후의 모든 요청에 ​​포함되어야합니다. 그렇지 않으면 요청이 거부됩니다.

보안 요구 사항으로 인해 레거시 보안 토큰을 REST 서비스 계층 외부로 반환 할 수 없습니다. 즉, REST 서비스 계층은이 토큰을 사용자 세션의 일부 양식으로 유지해야하며 그렇지 않으면 값 비싼 사용자 이름 + 암호 인증 프로세스가 레거시 시스템에 대한 모든 호출에 대해 반복되어야합니다.

REST 서비스 계층은 Java 6 + Spring 3 + Spring Security 3 스택을 사용하여 구현됩니다. 첫눈에,이 설정은 잘 동작 할 것입니다. 스프링 기반 REST 서비스는 오히려 표준 스프링 보안 구성을 사용하여 보안되고, 레거시 보안 토큰은 사용자의 HTTP 세션에 저장되며 모든 호출은 사용자 세션을 생성하여 레거시 시스템으로 보냅니다.

그러나 REST 클라이언트가 사용자의 HTTP 세션을 제대로 검색 할 수 있도록 필요한 데이터를 보내는 방법은 무엇입니까? 이는 일반적으로 JSESSIONID 쿠키를 사용하여 웹 브라우저에서 투명하게 수행되지만이 프로세스에는 브라우저가 포함되지 않습니다. 물론 REST 클라이언트는 코드 관리에 쿠키 관리 기능을 추가 할 수 있지만 모든 Spring RestTemplate, iPhone, BlackBerry 및 Android 클라이언트는이 작업을 쉽게 수행 할 수 있습니까?

대안은 REST 서비스 계층에서 HTTP 세션을 우회하고 HTTP 헤더를 통해 REST 클라이언트가 전송할 일부 키를 사용하여 식별되는 다른 사용자 세션 형태 (데이터베이스 사용)를 사용하는 것입니다. 또는 간단한 요청 쿼리. 그렇다면 Spring Security가 표준 Servlet HttpSession 대신이 대체 세션 메커니즘을 사용하도록 어떻게 구성 될 수 있습니까?

분명히 나는이 상황을 처음으로 다루는 것이 아닙니다. 내가 뭘 놓치고 있니?

감사합니다.

답변

3

쿠키에 관해서는 이상한 것이 없습니다. 그들은 단지 strings in HTTP headers입니다. 괜찮은 클라이언트 API는 쿠키 처리를 가능하게하기 위해 명시 적 구성이 필요하지만 모든 클라이언트 API가이를 처리 할 수 ​​있습니다.

쿠키를 사용하는 대신 JSESSIONID를 URL에 넣을 수 있습니다. 나는 봄 보안에 대해서는 아무것도 모르지만 실제로는 disable-url-rewriting이 명시 적으로 true로 설정되어 있지 않으면 URL 요청의 적어도 일부 유형에 대한 기본값이라고 보입니다. 그러나 이것은 ecurity weakness으로 간주 될 수 있습니다.

+0

동의. 이것은 쿠키가 발명 된 것입니다. 그것을 사용하십시오 –

+0

나는 쿠키 사용이 분명한 해결책임을 동의합니다. 내 질문은 이것이 Spring의 RestTemplate 또는 iPhone/Android/기타 기본 모바일 앱과 백엔드 REST 서비스를 통합하기위한 표준 솔루션인지 여부에 관한 질문이 많았던 것 같습니다. 예를 들어, RestTemplate으로 쿠키를 관리하는 것은 기본적으로 제공되지 않으며 추가 코드가 필요합니다. 어쩌면 내가 사용하지 않은 다른 사용자 상태 관리 체계가 널리 사용되었을 수도 있습니다. 아니면 그냥 불필요하게 복잡하게 만드는 것일 수도 있습니다 :) – Spiff

2

인증은 문제가 많습니다. 웹 표준 및 브라우저 구현과 관련하여 사소한 부분입니다. 당신은 쿠키가 "RESTful"하지만 순수한 것으로 간주되지 않는다는 점은 옳지 만, 완벽한 기능을 갖춘 브라우저에서도이 기사에 설명 된대로 꽤 많은 허위가 걸릴 수 있습니다. Rest based authentication.

불행히도 저는 모바일 개발을 전혀하지 않았으므로 최고의 절충안을 제안 할 수는 없습니다. 먼저 각 대상 플랫폼 의 인증 모델을 확인하여을 지원하는지 확인하십시오.

하나의 가능성은 모두 옵션을 제공하는 것입니다

  • HTTP 인증 (이상적 "기본"없습니다 "소화")
  • 쿠키 : 특히, 두 가지 옵션이 있습니다. 기술이나 보안의 관점에서는 분명히 이상적이지는 않지만 유용성면에서 장점을 가질 수 있습니다.