Java EE에 대한 RESTful 인증

Java EE에 대한 RESTful 인증

Java EE 응용 프로그램에서 사용자를 완전히 인증하는 데 사용할 수 있는 옵션을 평가하는 데 시간을 할애했습니다.

따라서 아래에 나열된 옵션이 유효한지 장점 또는 단점에 대한 설명과 함께 제안해 주십시오.인증 방법을 실행할 수 있는 세부 정보가 누락되었을 수 있습니다.또는 제가 놓친 다른 옵션이 있을 수도 있습니다(다시 말하지만 우리는 엄격하게 Java EE에 대해 이야기하고 있으므로 EE 호환 방식으로 수행될 수 없는 경우 쿼리 인증이 필요하지 않습니다.

다이제스트/기본 인증

 <security-constraint>
     <web-resource-collection>
        <web-resource-name>admin</web-resource-name>
        <url-pattern>/protected/*</url-pattern>
     </web-resource-collection>
     <auth-constraint>
        <role-name>admin</role-name>
     </auth-constraint>
</security-constraint>
<login-config>
    <auth-method>DIGEST/BASIC</auth-method>
    <realm-name>as-defined-secuity-realm</realm-name>
</login-config>

이점

1. 이것은 REST 친화적인 인증 방법입니다.AJAX 통화를 통해 인증 자격 증명을 보낼 수 있습니다.과 함께 합니다.Authorization: Basic/Digest QWxhZGRpbjpvcGVuIHNlc2FtZQ== 증명이 로그인 화면이 됩니다. 을 가지고 살 수 BASIC길입니다.잘못된 자격 증명의 경우 사용자에게 보기 흉한 브라우저 로그인 화면이 표시됩니다. 만약 당신이 그것을 가지고 살 수 있다면 BASIC/DIGEST 인증이 당신을 위한 길입니다.

2. 다이제스트의 경우 서버에 전달된 문자열은 MD5 암호화 문자열이며, 이는 Basic('user:password' 문자열의 Base64 인코딩)보다 확실히 더 안전하지만, 그럼에도 불구하고 해독할 수 있습니다.따라서 보안 측면에서 BASIC은 FORM 인증만큼 안전하며 DIGEST가 가장 안전합니다.결론적으로 사이트가 완전히 HTTPS인 경우(예를 들어 HTTP를 통해 일부 리소스를 가져오면 제3자가 권한 부여 헤더를 볼 수 있기 때문에) BASIC/DIGEST를 사용해도 안전합니다.

3. 쉽게 설정할 수 있습니다.

단점들

1. 로그아웃은 구현하기 어렵습니다.여기와 여기를 보세요.사용자를 인증하는 AJAX 요청이 있는 것은 확실하지만, 사용자를 로그오프하는 "AJAX?" 요청이 있어야 브라우저 로그인 창이 다시 나타납니다.그나저나 nice servlet 3.0 request.logout() 메서드는 이 경우 제대로 작동하지 않습니다.
2. 세션 시간 초과는 구현하기 매우 어렵습니다.세션 만료가 발생하지만(서블릿 컨테이너의 작업) 브라우저는 다음 요청 시 인증 헤더를 전송하여 재인증을 트리거합니다.
3. 개인화된 로그인 페이지가 없습니다.없음.
4. 인증된 세션을 추적하기가 어렵습니다.

FORM 기반 인증

 <security-constraint>
     <web-resource-collection>
        <web-resource-name>admin</web-resource-name>
        <url-pattern>/protected/*</url-pattern>
     </web-resource-collection>
     <auth-constraint>
        <role-name>admin</role-name>
     </auth-constraint>
</security-constraint>
<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>as-defined-security-realm</realm-name>
    <form-login-config>
        <form-login-page>/auth/login.html</form-login-page>
        <form-error-page>/auth/error.html</form-error-page>
    </form-login-config>
</login-config>

간단히 말해서, 사용자가 액세스하는 경우protected/*url. 로그인 페이지가 응답에 포함됩니다.따라서 사용자가 기대하는 콘텐츠 대신 로그인 페이지가form-login-page한 로 ( Permanently됩니다. 암호가 정상이면 처음 요청한 사람에게 전달됩니다(302 페이지가 영구적으로 이동됨).protected/*url. 비밀번호가 NOK이면 사용자에게 오류 페이지로 (302 Paged Moved Permanently) 전달됩니다.

이점

1. 개인화된 로그인 페이지 - 이것이 가장 인기가 많은 것 같습니다 :)
2. 로그오프는 구현하기 쉽습니다.HttpSession을 무효화하거나 request.logout() 메서드(Servlet 3.0)만 호출하면 됩니다.
3. 세션 시간 초과
4. IF 및 ONLY 로그인을 위해 별도의 페이지를 갖는 것을 수락하는 경우에만 이 방법이 사용자를 위한 해결책입니다.

단점들

1. REST 비우호적 (저는 휴식의 체계를 파고들지 않을 것이며 서버 측 상태를 유지하는 것은 RESTful 토론이 아닙니다.우리는 JAVA EE 방식으로 REST 인증을 분석하고 있으며, 인증된 모든 주체에 대해 서버 측 상태가 항상 유지됩니다.FORM 인증을 사용할 때 정말 나쁜 점은 브라우저 간에 일관된 동작을 할 수 없다는 것입니다.그리고 이 모든 것은 일부 브라우저가 AJAX 응답 기능에서 처리하는 302 리디렉션과 다른 브라우저는 전체 페이지를 리디렉션하기 때문입니다(내비게이션 표시줄에서 URL 변경).자세한 내용은 여기 및 여기.당신은 그 302 리다이렉트를 처리할 수 없기 때문에 당신을 위한 폼과 REST 인증이 없습니다!

프로그램 인증

인증을 위한 URL을 설정합니다.이 URL 뒤에는 로그인 모듈(JAAS 방식)을 인스턴스화하고 자격 증명과 함께 HttpServletRequest.login(user, pass) 메서드를 호출하는 서블릿이 있을 수 있습니다.로그인이 실패할 경우 401/403 응답을 생성해야 합니다.

web.xml에 security-constraint를 지정하기만 하면 구현할 수 있습니다.

<security-constraint>
     <web-resource-collection>
        <web-resource-name>admin</web-resource-name>
        <url-pattern>/protected/*</url-pattern>
     </web-resource-collection>
     <auth-constraint>
        <role-name>admin</role-name>
     </auth-constraint>
</security-constraint>

서버 측에서는 호출자를 인증하는 RESTFull 서비스를 설정하기만 하면 됩니다.다음은 몇 가지 샘플 코드입니다.

@Path("/auth")
@ApplicationPath("/rest")
public class AuthenticationRestFacade {

@POST
@Path("/login")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public User login(User loginInfo, @Context HttpServletRequest request) throws LoginException, ServletException {

    // nasty work-around for Catalina AuthenticatorBase to be able to 
    // change/create the session cookie 
    request.getSession();
    request.login(loginInfo.getName(), loginInfo.getPassword());

이점

1. 맞춤형 로그인 페이지입니다.
2. AJAX/REST 호환
3. 로그아웃 URL(로그아웃하도록 URL을 설정한 경우)
4. 세션 시간 초과(컨테이너 관리)
5. 응답에서 로그인 데이터(사용자 이름, 이메일, 역할, 그룹 등)를 반환할 수 있습니다(로그인 성공 후 다른 통화를 수행할 필요가 없기 때문에 매우 좋습니다).

단점들

1. 코드 작성이 좀 필요합니다.
2. 응용 프로그램이 401/403 응답을 처리하고 로그인 창을 표시할 수 있어야 합니다.

결론적으로 가장 실행 가능한 옵션은 다음과 같습니다.

1. 세션 시간 초과나 로그아웃에 대해 신경 쓰지 않는 경우 --> DIGEST
2. 위의 내용이 사용자에게 적용되지 않고 내장된 로그인 페이지(또는 모달 패널과 같은 페이지)가 필요하지 않으며 인증을 위해 한 페이지만 사용해도 됩니다. --> FORM
3. 위의 내용이 귀하에게 적용되지 않고 세계의 모든 유연성과 호환성을 원하는 경우에는 PROGRAMMATIC 접근 방식을 따릅니다.로그인/로그아웃 URL을 정의해야 하며 클라이언트 코드가 401/403 응답을 처리할 수 있어야 합니다(쉽지 않습니다).

실행 가능한 대안을 제시해 주시기를 진심으로 기대하고 있습니다.왜냐하면 지금 당장은 프로그램적인 접근법을 따르는 것이 싫기 때문입니다.

제 경험으로는, REST 서비스와 JSP나 JSF와 같은 서버 측 MVC 모두에서 동시에 작동하는 Java EE 인증 및 인증 서비스를 사용하는 시스템을 구현하는 것은 어렵습니다.제 모든 경험은 MVC 부분에 대해 폼 기반 인증을 사용하고 REST 서비스에 대해 일종의 토큰 인증(OAuth, Kerberos, LTPA)을 사용하는 쪽으로 기울고 있습니다.REST 서비스에 Form 또는 Basic 인증을 사용하는 것은 일반적으로 구현하기 어려웠지만, 우리는 이를 수행했고 두 개의 프로젝트에서 잘 작동합니다.

또한 기본 서버 구현에 따라 다릅니다.

아마도 이것들이 RESTful인지는 논쟁의 여지가 있지만, 적어도 다음 사항을 다루는 것이 좋을 것입니다.

케베로스는?윈도우즈 AD와 같은 인증 서버를 사용하는 중...

공개 키 인증서는 어떻습니까?클라이언트에서 제공한 인증서를 사용하여 사용자를 식별하는 중...

토큰은?OpenID와 같은 타사 토큰 발급자...

언급URL : https://stackoverflow.com/questions/16711119/restful-authentication-for-java-ee