• 이 글은 Head First Servlet & JSP를 기반으로 작성되었습니다.

servlet에서는 security 관련해서 authentication, authorization, confidentiality, data integrity. 총 4가지의 주요 개념이 존재.
각각 하나하나 알아보겠음.

개념들

Authentication

• 내가 누구라고 주장하는 사람을 확인하는 절차
  • e.g.) 로그인

Authorization

• 요청에 대한 권한이 있는지 확인하는 절차
  • e.g.) 계정 로그인 후 특정 사람만 볼 수 있는 게시글을 GET 요청했을 때 체크.

confidentiality

• 허가되지 않은 자가 정보를 보지 못하도록 방지하는 것.

Integrity

• 허가되지 않은 자가 정보를 변경할 수 없도록 하는 것.

Authentication

절차

1. 요청된 리소스 확인
   요청한 리소스가 security constraint를 가지고 있나 없나 확인한다.
2. 있으면 authentication 진행
   예를들어 김아무개씨가 김아무개씨 본인인지 체크.
3. 이후 Authorization으로 넘어감
   Authentication 되었으면 이제 그걸 볼 수 있는 권한이 있는지 체크하러 Authorization 절차 밟는다.

Realm

• 일반적으로 RDBMS나 LDAP system에 authentication data를 담아놓는다.
• 하지만 서블릿의 경우 realm이라는 개념이 존재.
  • authentication 정보 저장하는 곳
• tomcat 앱 테스트 하고시으면 tomcat-users.xml에 저장.
  • 얘는 conf/directory에 저장된다.(webapp 폴더 내부에 저장 안함.)
  • 즉, webapp 내부에 배포된 모든 application에 적용된다는 의미.
  • memory realm이라고 부름.
    - tomcat이 이 파일을 startup time에 읽어서 memory로 불러오기 때문.
    예시

<tomcat-users>
	<role rolename="Guest"/>
  	<role rolename="Member"/>
  	<role username="Bill" password="coder" roles="Member, Guest" />
  ...
</tomcat-users>

authentication 적용하는 법

DD에 이렇게 적으면 됨.

<login-config>
	<auth-method>BASIC</auth-method>
</login-config>

Authentication level

• Basic
  • 암호화 안하고 인코딩만 함.
• Digest
  • 암호화 해주긴 하는데 많이 안쓰임.
  • 그래서 J2EE 컨테이너는 꼭 이 레벨 지원하지는 않음.
  • SSL 아님.
• Client-Cert
  • PKC(public key certificate) 사용.
• Form
  • 암호화 안함. 매우 보안 취약

Authorization

절차

1. role 정의

두가지로 나눠서 정의
1) Vendor-specific

<tomcat-users>
  <role rolename="Admin"/>
  <role rolename="Member"/>
  <role rolename="Guest"/>
  <user username="Annie" password="admin" roles="Admin, Member, Guest">
  <user username="Diane" password="coder" roles="Member, Guest">
  <user username="Ted" password="newbie" roles="Admin, Member, Guest">
</tomcat-users>

2) servlet-speicification

	<security-role><role-name>Admin</role-name></security-role>
	<security-role><role-name>Admin</role-name></security-role>
	<security-role><role-name>Admin</role-name></security-role>

2. resource/method constraint 설정.

DD 내부

<web-app ...>
  ...
  <security-constraint>
    <web-resource-collection>
    	<web-resource-name>UpdateRecipes</web-resource-name>
    	
        <url-pattern>/Beer/AddRecipe/*</url-pattern>
    
	    <http-method>GET</http-method>
    	<http-method>POST</http-method>
    
    </web-resource-collection>
  
    <auth-constraint>
      <role-name>Admin</role-name>
      <role-name>Member</role-name>
    </auth-constraint>
  </security-constraint>
</web-app>

• constraint 요소는 resource와 HTTP Method의 결합으로 지정
• <http-method> 명시 안해준 리소스들은 다 unconstraint다.
• 만약 아예 <http-method> 명시를 안하면 그건 모든 Http method에 대해 constraint를 하겠다는 의미.

Role name

• case-sensitive
• <role-name>*</role-name>과 <auth-constraint>를 적지 않는 것은 동일한 의미.
  • 모든 role-name에 대해 허용.
• 반대로 <auth-constraint></auth-constraint>라고 해주면 아무것도 허용 안해준다는 의미.
  • 여기서 아무것도 허용 안한다는 의미는 정확하게는 바깥에서 오는 모든 요청에 대해서를 말한다. 내부에서는 사용 가능.

일부만 authorizing

• Http method level이 아니라 method 일부에만 authorize 적용이 가능
  isUserInRole()를 적용 하면 된다.

Confidentality and Integrity

HTTPS

• 서블릿에서 https로 통신시키는 방법이 있음
• CONFIDENTIAL 사용
  코드 예시

<web-app ...>
  ...
  <security-constraint>
    <web-resource-collection>
    	<web-resource-name>Recipes</web-resource-name>
        <url-pattern>/Beer/UdateRecipes/*</url-pattern>
    	<http-method>POST</http-method>
    </web-resource-collection>
  
    <auth-constraint>
      <role-name>Member</role-name>
    </auth-constraint>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>
</web-app>

• 이 transport-guarantee에 들어갈 수 있는 속성은 3가지다
  • NONE
    • data protection 없음
  • INTEGRAL
    • data를 변경하지 못함.
  • CONFIDENTIAL
    • data를 볼 수 없음.
    • 대부분의 CONTAINER는 TLS를 사용하기 때문에 INTEGRAL을 만족시키는 것은 CONFIDENTIAL을 만족시키는 것. 그 반대도 성립.
• DD에서 <security-constraint>는 request 이후에 일어나는 것에 대해 작용된다는 것을 인지하자.
  • 다른 말로 하면 client는 <security-constraint> 를 Container가 보고 어떻게 response를 넘겨줄 지 생각할 시점에 이미 request를 만들어서 보낸다는 것.
  • 그러면 TLS를 request 보내기 전에 어떻게 결정하나?
  • 유저가 보내기 전에 TLS로 switch 시켜주면 된다.
  • 시나리오로 살펴보겠음.

TLS 없을 때(<transport-guarantee> NONE)

1. client는 authenticate 되지 않은 상태에서 request 전송
2. Container는 authenticate 되지 않은 client의 요청이므로 401 code로 응답.
3. 유저는 login 정보와 함께 request 전송.
4. authenticate 후 authorize 과정 거친 뒤 요청 처리

TLS 있을 때(<transport-guarantee> CONFIDENTIAL)

1. 유저 요청 전송
2. container는 client에 301 response 전달(TLS 통신하라고 redirect 하라는 말)
3. TLS 통신으로 동일한 요청
4. 이후 위와 동일하게 authenticate 되지 않았으므로 401 ...
5. 위와 동일.