![]()
JAAS에 관한 기사의 첫 번째 부분이 계속됩니다. JAAS용으로 어노테이션만 사용하는 것이 가능한지, 어떤 문제가 발생하는지 알아봅시다. 이 부분에서는 어떤 Servlet API 도구를 사용하여 코드를 보다 보편적으로 만들 수 있는지 알아볼 것입니다. 그리고 읽은 내용을 요약해 보겠습니다.
계속
JAAS 기술 검토의 첫 번째 부분("
JAAS - 기술 소개(1부) " 참조)에서 우리는 JAAS 및 Servlet API의 주요 사용 사례를 살펴보았습니다. 우리는 Tomcat 서블릿 컨테이너가 JAAS 아키텍처를 사용하여 웹 애플리케이션의 보안을 관리한다는 것을 확인했습니다. "auth-method" 및 "Security Realm"에 대한 지식을 갖춘 Tomcat 컨테이너 자체는 인증 메커니즘의 필요한 구현을 제공하고 CallbackHandler를 제공하므로 로그인 모듈에서 모두 사용했습니다. 기억해야 할 유일한 중요한 점은 브라우저가 BASIC 인증을 통해 전송된 로그인 및 비밀번호 데이터를 저장한다는 것입니다. 따라서 Chrome을 사용하여 새로 스캔할 때마다
Ctrl+Shift+N을 눌러 새 창을 열어 시크릿 모드에서 작업할 수 있습니다.
주석
XML을 사용한 구성은 오랫동안 유행하지 않았습니다. 따라서 Servlet API 버전 3.0부터는 web.xml 배포 설명자 파일을 사용하지 않고 주석을 사용하여 서블릿 설정을 지정할 수 있다는 점이 중요합니다. 주석을 사용하면 보안 관리가 어떻게 바뀌는지 살펴보겠습니다. 그리고 주석을 사용하여 위에서 설명한 접근 방식을 구현하는 것이 가능합니까?
Servlet API 사양과 해당 섹션 " 주석 및 연결성 "은 주석을 이해하는 데 다시 한 번 도움이 될 것입니다 . 이 섹션에서는 서블릿 선언이
web.xml주석으로 대체될 수 있다고 말합니다
@WebServlet. 따라서 우리의 서블릿은 다음과 같습니다:
@WebServlet(name="app", urlPatterns = "/secret")
public class App extends HttpServlet {
다음으로 " 13.3 프로그래밍 보안 " 장을 살펴보겠습니다 . 주석을 통해 보안 제약 조건을 선언할 수도 있다고 나와 있습니다.
@WebServlet(name="app", urlPatterns = "/secret")
@ServletSecurity(httpMethodConstraints = {
@HttpMethodConstraint(value = "GET", rolesAllowed = "admin")
})
public class App extends HttpServlet {
이제
web.xml우리 블록은 단 하나 남았습니다
login-config. 문제는 쉽고 간단하게 교체할 수 있는 방법이 없다는 것입니다. 웹 응용 프로그램 보안 설정과 웹 서버 보안 설정이 밀접하게 연결되어 있기 때문에 프로그래밍 방식으로도 이 작업을 수행하는 간단하고 보편적인 방법은 없습니다. 이는 JAAS 및 Servlet API를 사용한 인증의 문제점 중 하나입니다. 블록에 관해 말하면
login-config이것이 인증 메커니즘에 대한 선언적 설명이라는 점을 이해하는 것이 좋습니다. 인증 메커니즘. 이를 대체할 수 있는 간단하고 보편적인 방법은 아직 없습니다. 왜냐하면... 처리는
web.xml서블릿 컨테이너 내부 깊은 곳에서 발생합니다. 예를 들어 Tomcat에서는 소스
ContextConfig.java를 볼 수 있습니다 . 따라서 Tomcat 서블릿 컨테이너의 경우에도 여러 옵션이 있으며 모두 다릅니다. 예를 들어, 임베디드 Tomcat 서블릿 컨테이너를 사용하는 경우(즉, 코드에서 웹 서버를 생성하는 경우) 여기에서 해당 옵션에 대해 읽을 수 있습니다: " 코드를 통한 기본
인증이 포함된 임베디드 Tomcat ". 또한 Embedde Tomcat을 키우는 일반적인 예는 Heroku PaaS 플랫폼 가이드 "
Create a Java Web Application Using Embedded Tomcat "에서 볼 수 있습니다. Tomcat이 임베디드 모드에서 사용되지 않는 경우 Tomcat의 경우 일반적으로 사용되는 접근 방식인 이벤트 리스너를 사용할 수 있습니다.
Tomcat에서는 " The LifeCycle Listener Component " 입니다 . 동시에 서블릿 컨테이너(우리의 경우 Tomcat)에는 자체 클래스 로더가 있을 수 있으며 단순히 클래스를 가져와 사용하는 것이 불가능하다는 점을 이해하는 것이 중요합니다.
Tomcat의 경우 " Class Loader HOW-TO " 를 이해해야 합니다 .
Undertow라는 다른 서블릿 컨테이너에서는 " Servlet Extensions " 를 사용하여 이를 달성할 수 있습니다 . 보시다시피 일부는 보다 유연한 메커니즘을 제공했지만 다른 일부는 그렇지 않았습니다. 보시다시피 단일 옵션은 없습니다. 그들은 모두 매우 다릅니다. Servlet API와 JAAS만으로 보편적인 작업을 수행하는 것이 가능합니까? 인터넷에서는 차단 없이 인증을 수행하기 위해 서블릿 필터를 사용하라는 제안을 찾을 수 있습니다
login-config. 마지막으로 이 옵션을 고려해 보겠습니다. 이를 통해 JAAS 작동 방식을 반복할 수 있습니다.
인증 필터
web.xml따라서 우리의 목표는 파일을 완전히 제거하는 것입니다 . 이를 제거하면 안타깝게도 더 이상 보안 제약 조건을 사용할 수 없습니다. 해당 처리는 서블릿 필터가 적용되는 것보다 훨씬 일찍 발생할 수 있습니다. 이는 필터 사용의 "다양성"에 대해 지불해야 하는 비용입니다. 저것들. 주석을 제거해야 하며
@ServletSecurity이전에 보안 제약 조건에서 설명한 모든 검사를 프로그래밍 방식으로 수행해야 합니다. 보시다시피, 이 옵션은 우리에게 많은 불쾌한 제한을 부과합니다. 우선
@ServletSecurity리소스에서
login-config주석 을 제거하고
web.xml. 이제 우리는 기본 인증을 구현해야 합니다. 이제 필터를 추가해 보겠습니다.
@WebFilter("/*")
public class JaasFilter implements javax.servlet.Filter {
지금까지는 간단해 보입니다. 초기화 방법을 작성해 보겠습니다.
@Override
public void init(FilterConfig filterConfig) throws ServletException {
String jaas_conf = filterConfig.getServletContext().getRealPath("/WEB-INF/jaas.config");
System.getProperties().setProperty("java.security.auth.login.config",jaas_conf);
}
보시다시피, 이제 jaas 구성 파일을 검색하기 위해 기본 JAAS 도구를 사용해야 합니다. 여기에는 큰 단점이 있습니다. 여러 애플리케이션이 있는 경우 한 애플리케이션이 다른 애플리케이션의 인증을 깨뜨릴 수 있습니다.
일반적으로 Jaas 구성 파일을 설정하는 방법은 JAAS 문서 " 부록 A: java.security 보안 속성 파일의 JAAS 설정 " 에 자세히 설명되어 있습니다 . 다음으로 필터링 방법 자체에 대해 설명하겠습니다. HTTP 요청을 수신하는 것부터 시작해 보겠습니다.
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
if (req.getUserPrincipal() != null ) {
chain.doFilter(request, response);
}
여기에서는 모든 것이 간단합니다. 주체를 사용할 수 있으면 인증에 성공한 것입니다. 다음으로, 사용자가 인증을 통과하지 못한 경우 필터의 동작을 설명해야 합니다. 그는 아직 인식되지 않았습니다. 앞에서는 기본 인증 방법인 BASIC에 대해 설명했습니다. 왜냐하면 이제 필터를 직접 작성하고 있으므로 BASIC 인증이 실제로 어떻게 작동하는지 파악해야 합니다.
" MDN web docs: HTTP 인증 "을 사용할 수 있습니다 . 그리고 "
HTTP 인증은 어떻게 작동하나요? " 기본 인증이 작동하는 방식에 대한 설명을 보면 서버가 기본 인증을 수행하려고 하는데 사용자가 데이터를 제공하지 않은 경우 서버가 특수 헤더 "WWW-Authenticate"와 오류 코드 401을 보내는 것이 분명합니다. 이에 대한 내부 방법:
private void requestNewAuthInResponse(ServletResponse response) throws IOException {
HttpServletResponse resp = (HttpServletResponse) response;
String value = "Basic realm=\"JaasLogin\"";
resp.setHeader("WWW-Authenticate", value);
resp.sendError(HttpServletResponse.SC_UNAUTHORIZED);
}
이제 이 메서드를 사용하고
doFilter메서드에 다음 코드 블록을 추가해 보겠습니다.
String secHeader = req.getHeader("authorization");
if (secHeader == null) {
requestNewAuthInResponse(response);
}
if이제 헤더가 이미 전송되었을 때 실행될 분기를 추가해 보겠습니다 .
else {
String authorization = secHeader.replace("Basic ", "");
Base64.Decoder decoder = java.util.Base64.getDecoder();
authorization = new String(decoder.decode(authorization));
String[] loginData = authorization.split(":");
try {
if (loginData.length == 2) {
req.login(loginData[0], loginData[1]);
chain.doFilter(request, response);
} else {
requestNewAuthInResponse(response);
}
} catch (ServletException e) {
requestNewAuthInResponse(response);
}
}
이 코드에 인증을 추가할 수 있습니다. 예를 들면 다음과 같습니다.
req.isUserInRole("admin") 따라서 필터를 사용하여 인증을 수행했습니다. 한편으로는 코드와 수동 처리가 많습니다. 반면에 다양성과 서버 독립성이 있습니다.
결론
이제 이번 리뷰가 끝났습니다. 이제 JAAS가 무엇인지, 주체가 무엇인지, 주체가 무엇인지 좀 더 명확해졌으면 좋겠습니다. Security Realm 및 Login Config라는 단어는 더 이상 질문을 제기하지 않습니다. 추가적으로 우리는 이제 JAAS와 Servlet API를 함께 사용하는 방법을 알게 되었습니다. 또한 Servlet API의 주석이 도움이 되지 않는 병목 현상에 대해서도 배웠습니다. 물론 이것이 전부는 아닙니다. 예를 들어, Java의 인증은 BASIC일 뿐만이 아닐 수도 있습니다.
" 13.6 인증 " 섹션의 Servlet API 사양에서 다른 유형에 대해 볼 수 있습니다 . 인터넷에서 JAAS에 대한 자세한 정보를 찾는 것은 어렵습니다. 하지만 저는 이 자료를 추천할 수 있습니다:
이 리뷰의 정보가 유용하고 이해하기 쉽기를 바랍니다. #비아체슬라프
JAAS에 관한 기사의 첫 번째 부분이 계속됩니다. JAAS용으로 어노테이션만 사용하는 것이 가능한지, 어떤 문제가 발생하는지 알아봅시다. 이 부분에서는 어떤 Servlet API 도구를 사용하여 코드를 보다 보편적으로 만들 수 있는지 알아볼 것입니다. 그리고 읽은 내용을 요약해 보겠습니다.
GO TO FULL VERSION