REST 백엔드 / Ajax Front End Application의 인증 및 인증 시스템 설계 방법

REST 백엔드 / Ajax Front End Application의 인증 및 인증 시스템 설계 방법

저는 새로운 프로젝트를 시작하고 있습니다. 여기서 우리는 휴식이 가능한 백엔드와 AJAX 폰트엔드를 만들 계획입니다.저는 제가 가지고 있는 모든 자원과 다양한 HTTP 동사들이 무엇을 할 것인지, 그들의 URI와 그 자원들의 JSON 표현을 파악하는 것에 초점을 맞추어 문제에 접근하고 있습니다.

백엔드를 확보하기 위한 최적의 디자인을 찾고 있습니다.여기 제가 고려한 디자인 목록이 있습니다.아래에 나와 있지 않은 대체 디자인과 장단점 추천을 찾고 있습니다.이 시스템은 Spring 3.0과 함께 구현될 예정이며, Spring Security 3.0일 수도 있습니다. SSL은 시스템의 많은 부분에 사용되지만 모든 부분에 사용되는 것은 아니기 때문에 일부 요청은 SSL에 오고 일부 요청은 그렇지 않을 수 있습니다.

옵션 1: HTTP 세션 사용

표준 로그인 화면을 표시하고 서버측 세션을 생성한 후 Tomcat이 jsessionid 쿠키를 다시 보내도록 하고 모든 XHR 요청 시 ajax 클라이언트가 JSESSIONID 쿠키를 포함하도록 합니다.이 옵션은 다음과 같은 이유로 잘못된 접근 방식인 것처럼 느껴집니다.

• REST 규칙에 위배되는 연결 상태가 가득 차게 됩니다.
• 백엔드를 여러 개의 개별 WAR 파일로 분할할 수 있으면 백엔드에 여러 개의 HTTP 세션을 가질 수 있습니다. 그렇다면 이 접근 방식은 작동하지 않습니다.오늘날 백엔드를 여러 개의 앱으로 분할할 수 있는 기능은 필요하지 않지만, 그런 가능성이 있는 디자인을 선호합니다.

옵션 2: 이 작업을 수행하는 오픈 소스 Java 기반 보안 라이브러리 찾기

Spring security 이외에 다른 Java 라이브러리를 찾지 못했습니다. 권장 사항은 매우 감사드립니다.

옵션 3: OAuth와 같은 기존 프로토콜을 사용해 보십시오.

제가 OAuth를 간단히 살펴본 결과, 각 사이트가 자체 사용자 데이터베이스를 가지고 있는 사이트 전반에 걸쳐 인증을 위해 설계된 것으로 보입니다.이 시스템에서는 모든 백엔드 ajax 서비스에서 글로벌 사용자 데이터베이스를 공유하고자 합니다.

옵션 4: SAML 및 Shiboleth 사용

이 옵션은 과도하게 사용되고 설정 및 유지보수가 매우 복잡해 보입니다.

옵션 5: 요청할 때마다 사용자 이름과 암호를 보냅니다.

따라서 사용자가 요청할 때마다 사용자 이름과 암호를 보내야 하는데, 이는 프론트엔드 AJAX 앱이 사용자 이름과 암호를 자바스크립트 개체로 저장해야 한다는 것을 의미하며, 사용자가 페이지에서 벗어나 탐색하면 사용자 이름/암호 콤보가 사라지고 사용자가 다시 로그인해야 할 수도 있습니다.저는 프론트 엔드가 사용자 이름과 비밀번호를 쿠키에 넣으려고 시도하는 것을 원하지 않습니다. 그것은 보안을 구성하는 것이기 때문입니다.

옵션 6: 자체 인증/인증 프로토콜 구현

사용자가 사용자 이름/비밀번호 조합을 제시한 후 돌려받을 수 있는 REST 서비스를 만들고 보안 토큰을 요청할 때마다 서비스로 다시 보내야 합니다.보안 토큰은 서비스에 의해 디지털 서명되며 만료 시간을 갖게 됩니다.토큰은 대부분의 작업에만 유용합니다. 보안이 높은 작업에는 작업을 확인하기 위한 포트로 새 로그인 화면이 필요합니다.

이 접근 방식의 문제는 완전한 시간 낭비처럼 보이는 또 다른 보안 프로토콜을 개발해야 한다는 것입니다.

저만 이 문제에 직면한 것이 아니라고 확신합니다. 스택 오버플로 커뮤니티에서 아직 찾지 못한 옵션 및 도구를 가리킬 수 있기를 바랍니다.

아파치 시로를 보세요.애플리케이션 간 세션을 공유하는 데 사용할 수 있는 세션 관리 기능을 갖춘 인증 시스템입니다.이것이 가장 쉬운 일일지도 모릅니다.

또는 Spring Security(또는 Shiro)를 웹 앱 간에 공유되는 Recember Me 쿠키와 함께 사용할 수도 있습니다(같은 HTTP 도메인에 있는 한).remember me cookie는 옵션 6에 있는 당신의 토큰과 유사합니다.쿠키에 유통기한을 설정하시면 세션 쿠키처럼 짧게 살 수도 있고 일반인처럼 오래 살 수도 있습니다.

Jasig CAS - Single Sign-On for the Web을 살펴볼 수도 있습니다.REST API 및 프로토콜(Proxy Tickets)을 통해 옵션 6에서 설명한 것처럼 AuthN 사용자에게 백엔드 서비스를 제공할 수 있습니다. http://www.jasig.org/cas

잠깐...AJAX 클라이언트를 지원하는 애플리케이션은 Spring Security(CAS를 즉시 지원)로 보호되고 사용자가 AJAX 클라이언트에 내장하는 Proxy Granting Ticket을 가져옵니다.AJAX 클라이언트가 PGT를 사용하여 REST 서비스에 대한 프록시 티켓을 가져옵니다.스프링 시큐리티로 보호됩니다.REST 서비스는 기본 자격 증명을 터치하지 않고도 인증된 userId를 얻습니다.

또는 서버에 PGT를 유지하고 AJAX 호출을 사용하여 Proxy Ticket을 검색한 다음 AJAX 클라이언트에서 REST 서비스를 호출하는 데 사용할 수 있습니다.

휴식 애플리케이션을 확보하는 것으로 알고 있기 때문에 서문을 쓰기 위해서는 보안 공급자가 -Authentication -Authorization -Auditing의 세 가지 개념(3A)으로 구성되어 있음을 알아야 합니다.

이 세 가지를 함께 구현하려면 -SSO 프로바이더 -Session Store -Open Id 패턴 -사용자 자격 증명 통합 등의 도구를 제공해야 합니다.

저는 ACL(Spring ACL)을 사용하여 인증 서비스와 인증을 위한 oauth2를 제공한 적이 있습니다.이 둘을 함께 연결하는 채널이 하나 있고 스코프(oauth2 스코프)가 있지만 문제는 스코프가 role_votter, cache_strategy, black_list 또는 role_base strategy, 예외 권한, white_list...와 같은 권한 모듈을 구현하기에 충분히 유연하지 않다는 것입니다.(그러나 @EnableGlobalMethodSecurity를 사용할 수 있습니다.)

제 경우에는 인가 서버를 oauth2 인증 서버를 위한 리소스로 사용했습니다(http://projects.spring.io/spring-security-oauth/docs/oauth2.html), 를 보십시오. 그런 다음 인가를 확인하기 위해 두 지점을 고려했습니다. 처음에는 프론트엔드에 ACL을 발행하고 프로그래머가 ACL 개념까지 동적으로 페이지를 설계하도록 강요했습니다.두 번째는 Aspect를 사용하는 백엔드 온 서비스 계층(BLL)입니다. 하나의 휴식이 호출될 때 말이죠.현재 사용자가 액세스 제어를 충분히 할 수 있는지 확인하기 위해 서비스 키를 Actee로 보냈습니다. 감사를 위해서는 모든 요청을 모니터링해야 합니다. 즉, 게이트웨이나 브로커에서 수신자를 사용해야 합니다.

언급URL : https://stackoverflow.com/questions/4981045/how-to-design-authentication-and-authorization-system-for-rest-backend-ajax-fr