Whiteship's Note


스프링 시큐리티 3.0.0 M1 배포



참조 편역 요역: http://blog.springsource.com/2009/06/03/spring-security-300m1-released/

http://www.springsource.com/download 에서 직접 다운로드 할 수도 있고, 메이븐을 사용한다면, http://maven.springframework.org/milestone 메이븐 저장소를 추가하면 M1 의존성을 추가할 수 있다. JDK 1.5 이상, 스프링 3.0이 필요함.

표현식-기반 접근 제어

스프링 EL 기반 권한 관리를 지원한다. 메서드 애노테이션이나 웹 시큐리티에서 표현식을 사용할 수 있다. 속성이나 보터(voter)-기반 매커니즘에 비해 새로운 조합을 꾀할 수 있다. 다음은 웹 시큐리티에서 시큐리티 네임스페이스를 사용하는 간단한 예제다.

<http>
   <intercept-url pattern="/secure/**" access="hasRole('ROLE_SUPERVISOR') and hasIpAddress('192.168.1.0/24')" />
   ...
</http>

hasRole('ROLE_SUPERVISOR')은 사용자의 권한 목록을 확인하고 사용자가 해당 롤을 가지고 있다면, true를 반환한다. 여기에 IP를 확인할 수 있는 새로운 표현식을 추가했다.

@Pre와 @Post 애노테이션

메서드 시큐리티는 웹 요청을 수락하거나 거부하는 것과는 달리 조금 더 복잡하다. 메서드 시큐리티에 표현식을 사용해서 좀 더 다양한 기능을 제공하기 위해, 4개의 새로운 애노테이션을 추가했다. 이 애노테이션들을 사용하여 메서드 호출 전과 후에 특정 로직을 실행할 수 있다. 이 기능을 사용하려면 global-method-security 네임스페이스 엘리먼트에 새로운 속성을 사용해야한다.

<global-method-security pre-post-annotations="enabled"/>

가장 유용한 것으로 @PreAuthorize가 있는데, 이 애노테이션은 메서드를 실제로 실행할지 말지 여부를 제어한다. 예를 들어(예제 애플리케이션의 Contacts에서) 다음 메서드를 보자.

@PreAuthorize("hasRole('ROLE_USER')")
public void create(Contact contact);

이것은 ROLE_USER라는 롤을 가진 사용자만 접근을 허용한다는 뜻이다. 별 다른게 없다.

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(Contact contact, Sid recipient, Permission permission);

이번에는 메서드 인자를 표현식에서 참조하고 있다. 해당 contact에 대해 현재 사용자가 admin 권한이 있는지 확인한다. hasPermission() 표현식은 애플리케이션 컨텍스트를 통해서 스프링 시큐리티 ACL 모듈과 연결되어 있다.(어떻게 연결되어 있는지는 Contacts 예제를 통해 살펴보기 바란다.) 메서드 인자를 표현식 변수로 참조할 수 있다. 스프링 EL의 모든 기능을 사용할 수 있기 때문에 인자의 속성에도 접근할 수 있다. 따라서 특정 사용자의 이름이 contact의 이름과 대응할 경우로 제한하고 싶을 때 다음과 같은 표현식을 사용할 수도 있다.

@PreAuthorize("#contact.name == principal.name)")
public void doSomething(Contact contact);

여기서는 내장된 표현식 principal을 사용했다. 이 것은 현재 스프링 시큐리티의 Authentication 객체를 기반한 것으로 시큐리티 컨텍스트에서 가져온 것이다. Authenticatino 객체에 직접 접근하려면 authentication 표현식이름을 사용할 수도 있다. 메서드 호출 후에 권한 작업을 수행할 수 있는데, 이 때는 @PostAuthotize 애노테이션을 사용하고, 반환값은 "returnObject"로 참조할 수 있다.

필터링

스프링 시큐리티는 컬렉션과 배열 필터링을 이미 제공하고 있었는데, 이제는 표현식을 사용할 수도 있다.

@PreAuthorize("hasRole('ROLE_USER')")
@PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')")
public List getAll();

여기서 filterObject는 반환하는 컬렉션에 들어있는 각각의 요소들을 지칭하고, 해당 요소에 대한 사용자의 권한이 read 이거나 admin이 아닌 것은 컬렉션에서 빼낸다. @PreFilter를 사용해서 메서드 호출 전에 필터링을 할 수도 있지만, 거의 사용하지 않는듯 하다. 문법은 같은데, 인자에 두 개 이상의 컬렉션이 있을 때 filterTarget 속성을 사용하여 어떤것을 사용하는지 지칭한다.

코드기반 재구성

3.0에서 대부분의 코드는 spring-security-core.jar로 들어갔다. 몇 년에 걸쳐 여러 기능이 추가되다보니 의존성간에 CR(circular reference)도 생기고 복잡한 의존성 구조가 되어버렸다. 또한 여러 jar에 나눠져서 들어간 패키지가 OSGi에서 말썽을 일으킨다는 이슈도 있었다. 이로인해 유지보수 오버헤드가 발생했고, 그 걸과 3.0에서 코드기반을 재구성하기로 결정했다.

프로젝트 JAR 파일

- 이 부분은 별도로 포스팅. 여기서는 생략.

이로인해 코드를 순회하며 참조하거나 이해하기 쉬워졌다.

스프링 시큐리티 3.0 JAR 의존성

패키지 구조

더이상 CR도 없고 훨씬 깔끔해졌다.


기타 변경사항

클래스 이름 변경: 이름들이 훨씬 명시적으로 바꼈군요.
AbstractProcessingFilter -> AbstractAuthenticationProcessingFilter
AuthenticationProcessingFilter -> UsernamePasswordAuthenticationProcessingFilter
AuthenticationEntryPoint -> LoginUrlAuthenticationEntryPoint
ObjectDefinitionSource -> SecurityMetadataSource
HttpSessionContextIntegrationFilter -> SecurityContextPersistenceFilter

인증 성공 또는 실패시 리다이렉션/포워딩: 인증 성공 또는 실패시에 브라우저가 이동할 목적지를 제어하는 방법 제공.
AuthenticationSuccessHandler
AuthenticationFailureHandler
http://jira.springsource.org/browse/SEC-745

레퍼런스 매뉴얼과 웹 사이트 업데이트: 아직 작업 중이지만 몇 개 챕터(네임스페이스, 기술 개요)는 업데이트 했다. 프로젝트 사이트의 FAQ도 업데이트 해서 몇몇 발표 비디오와 온라인 기사를 참조할 수 있다.

결론

스프링 EL을 사용하여 기능이 좀 더 풍부해졌고, 코드기반을 깔끔하게 정리했다.
JIRA 변경로그
커뮤니티 포럼
JIRA 이슈
top

  1. Favicon of http://ryys1993.tistory.com BlogIcon 윤성철 2009.06.08 17:47 PERM. MOD/DEL REPLY

    으아 언제나 느끼는거지만 정말 대단하셔요~~

    도데체 저런 그림은 어떻게 그리시는건지~ ^^

    머리에 쏘옥 쏙 들어오네요 ^^.

    저런 그림은 뭘로 그리시는지요? ^^..

    그림판은 아닐텐데 ^^.. 혹시 이클립스 플러긴이 있는건가 흐헉..

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2009.06.08 18:17 신고 PERM MOD/DEL

    절대로 제가 그린게 아니구요.
    원문에 있던거 퍼온거에요.
    오해를 불러일으켜 죄송합니다~

    아마도 이클립스에서 무슨 플러긴으로 자동 생성한 그림이겠거니 추측해 봅니다.

  2. Favicon of http://ryys1993.tistory.com BlogIcon 윤성철 2009.06.09 12:44 PERM. MOD/DEL REPLY

    직접 그리시지 않으셨다 하여도.. 위 기사를 쉽게 접할수 있게 해주시는것에 대해

    매우 감사합니다.

    사실 영어 울렁증때문에 --;;; ㅋ....

    앞으로 영어 공부좀 해야할거같아요 ^^.

    오늘 날 무지 꿀꿀스럽지만

    즐거운 날 되세요~...

    Favicon of http://whiteship.me BlogIcon 기선 2009.06.09 14:03 PERM MOD/DEL

    넵 ㅎㅎㅎ
    시원하고 좋네요. 좋은 하루 되세요~

Write a comment.


스프링 시큐리티 맞춤확장(customization) - 파트 1. UserDetail 또는 GrantedAuthority 맞추기



참조 및 번역: http://blog.springsource.com/2009/01/02/spring-security-customization-part-1-customizing-userdetails-or-extending-grantedauthority/

이번 글은 스프링 시큐리티 맞춤확장과 관련된 실용적인 예제 중심의 여러 작은 글들의 시리즈 중 첫 번째 글이다. 이번 맞춤확장 요구 사항은 상상에서 온 것이 아니라 전부 현장에서 요구한 것이다.

다음과 같은 요구사항이 있다고 가정해보자. 역할(role) 목록이 있고 각각의 역할은 비즈니스 기능(business function) 목록을 가지고 있다.(아래를 참조하라.)

ROLE_ADMIN
  BF_QUOTE_CREATE
  BF_POLICY_CREATE
  BF_POLICY_DELETE

ROLE_AGENT
  BF_QUOTE_CREATE
  BF_POLICY_CREATE

ROLE_USER
  BF_QUOTE_CREATE

필요한 기술은 권한 결정을 ROLE과 BF 모두를 가지고 결정할 수 있어야 한다는 것이다.

예를 들어:

ROLE_ADMIN이라는 역할을 가진 사용자는 해당 역할로 보호하고 있는 모든 리소스에 접근할 수 있어야 한다.

<sec:authorize ifAllGranted="ROLE_ADMIN">
    <p><a href="http://www.google.com">Google</a>
</sec:authorize>

또는

@Secured("ROLE_ADMIN")
public void foo()
    . . .
}

또한 해당 사용자는 해당 역할이 가지고 있는 비즈니스 기능으로 제한하고 있는 모든 리소스에도 접근할 수 있어야 한다.

<sec:authorize ifAllGranted="BF_POLICY_DELETE">
    <p><a href="http://www.google.com">Google</a>
</sec:authorize>

또는

@Secured("BF_POLICY_DELETE")
public void foo()
    . . .
}

이 요구사항을 다루는 방법은 몇 가지가 있다. 그 중 하나는 RoleHierarchy를 만들고 RoleHierarchyVoter를 사용하여 역할의 계층 구조를 순회하는 것이다. 이 접근 방법의 단점은 현재 스프링 시큐리티 2.0.4 구현체의 태그 라이브러리(security: authority ...)가 AccessDecisionManager를 통해서 의사 결정을 하고 있지 않으며 게다가 어떤 Voter도 제한하고 있는 HTML 엘리먼트에 대한 결정을 할 때 Role을 신경쓰지 않는다. 하지만 스프링 시큐리티의 놀라운 유연함과 맞춤확장 힘으로 인해 이 요구사항을 매우 간단하게 해결할 수 있다.
스프링 시큐리티의 가장 큰 잇점 중 하나는 어떻게 Principal(UserDetail 객체)을 생성하는지 맞춤확장 할 수 있다는 것이다. UserDetail 객체를 만들 때 GrantedAutorities 목록을 생성한다. 이 목록은 나중에 리소스를 제한하고 있는 GrantedAutority와 비교해볼 때 사용된다.
맞춤확장을 하는 또 한 가지 방법은 UserDetail 객체를 생성할 때 GrantedAuthorities 목록을 수정하는 것이다.

아래에서 제공하고 있는 예제에는 두 개의 프로퍼티 파일이 있다.(간단하게 하려고 프로퍼티 파일을 사용했지만, 여러분은 쉽게 그것을 DB나 LDAP으로 바꿀 수 있을 것이다.)

파일 하나는 users.properties로 사용자를 role에 맵핑한다.

oleg=powder,ROLE_ADMIN

다른 파일 하나는 role-to-db.properties로 각각의 role에 비즈니스 기능 목록을 맵핑한다.

ROLE_ADMIN=BF_QUOTE_CREATE,BF_POLICY_CREATE,BF_POLICY_DELETE

이제 필요한 작업은 UserDetailsService 구현체를 정의하여 위 두 개의 프로퍼티 파일을 사용하여 GrantedAUthorities 목록을 만들고 그것을 UserDetails 객체에 주입하는 것이다. 이 작업은 GrantedAuthorityImpl같은 GrantedAuthority 인터페이스 구현체를 재사용할 수 있으며 매우 간단하다. 하지만, 우리는 이때 (디버깅 또는 다른 의도로) 비즈니스 기능을 표현하는 GrantedAuthority의 상위(parent) GrantedAuthority를 추적할 수 있도록 하고 싶다.
이 두 가지 목적을 달성하기위해 GrantedAuthorityImpl을 확장하는 BusinessFunctionGrantedAuthority 클래스를 정의하고 모든 상위 GrantedAuthority 객체에 대한 목록을 담고 있게 했다.

public class BusinessFunctionGrantedAuthority extends GrantedAuthorityImpl {
    private List<GrantedAuthority> parentAuthorities;
        . . .
}

그런 다음 UserDetailsService 구현체를 만들었고 loadUserByNames(..) 메소드를 구현하여 다음 작업을 수행하도록 했다.

1. users.properties 파일 내용을 기반하여 UserAttribute 객체를 만든다. UserAttribute는 role을 나타내는 GrantedAuthority 목록을 담고 있다.
2. role-GrantedAuthorities 목록을 순회하면서 각각의 role-GrantedAuthorities 마다 BusinessFunctionGrantedAuthority를 만들고 그것을 미리 만들어둔 GrantedAuthority 목록에 추가한다.
  2-1. 각각의 BusinessFunctionGrantedAuthority에 parent GrantedAuthority를 추가한다.
3. 전체 GrantedAuthority 목록을 가지고 있는 최종 UserDetail 객체를 만든다.

그런 다음 AuthenticationProvider를 스프링 시큐리티 설정 파일에 정의한다.

사용자 삽입 이미지

노트: AuthenticationProvider에 커스텀 UserDetailService 구현체 ComplexAuthorityUserDetailsService 클래스(더 자세한 내용은 샘플 코드를 살펴보라.)를 주입했다.

리소스를 보안하고 배포한 다음 http://localhost:8080/spring-security-sample-grantedAuthority/index.jsp에 접속하라.

로그인한 뒤 여러분은 GrantedAuthorities 목록을 볼 수 있을 것이다.

사용자 삽입 이미지

여기서 여러분은 비즈니스 기능을 나타내는 GrantedAuthority가 해당 비즈니스 기능을 가지는 상위 GrantedAuthorities 목록도 보여주고 있다는 것을 확인할 수 있을 것이다.
index.jsp를 살펴보고 어떻게 security:authorize 태그를 사용ㅇ하여 role과 비즈니스 기능 목록을 사용하여 HTML 엘리먼트를 제한하는지 살펴보라
이게 끝이다. 여러분은 최소한의 맞춤확장으로 쉽게 Principal 구조를 확장하고 커스터마이징 할 수 있는지 살펴보았다. 그리고 이것을 비즈니스 코드를 더럽히지 않고 커스텀 GrantedAuthorities에 기반하여 선언적으로 보안을 적용하는지 살펴보았다.

샘플 코드는 여기서 다운로드 할 수 있다. spring-security-sample-grantedauthority
top

Write a comment.


드디어 Spring Security 2.0 Released!!



http://www.springframework.org/node/627

아 이 녀석의 POM 때문에 어제 고생한 걸 생각하면...OTL 이번 배포판에서는 스프링 2.5.0 이상의 버전을 사용하도록 명시했군요. 대체 왜 [2.0, 2.5]라고 한건지.. 그냥 2.0 이라고 하면 알아서 2.0 이상의 버전을 쓸텐데 말이죠. petclinic 예제도 봐야겠습니다.

2.0에 추가된 기능들 요약
- OpenID 지원
- NTLM
- JSR 250 애노테이션
- AspectJ 포인트컷 표현식
- 도메인 ACL 기능강화
- RESTful URI 권한
- 그룹
- 계층적인 권한
- user 관리 API
- 데이터베이스 기반 "remember me"
- portlet 인증(로그인)
- 언어 추가
- Web Flow 2.0 지원
- Spring IDE 시각화와 자동완성
- 스프링 웹 서비스 1.5를 사용하여 WSS 기능 지원 강황

우왕.. 몇 개 빼고 다 해보고 싶네요.

참조 할 것
http://www.jroller.com/habuma/entry/method_level_security_in_spring <-- 메소드 레벨 Security 모든 방법 소개. SIA 저자. 굳.
top

  1. Favicon of https://jjaeko.tistory.com BlogIcon 째코 2008.04.16 00:59 신고 PERM. MOD/DEL REPLY

    스프링 시큐리티는 또 언제 공부하나... 어휴

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.04.16 08:11 신고 PERM MOD/DEL

    걍 천천히~ 느긋하게.. 즐기시면 됩니다. 전 어서 하이버를 마무리해야 할텐데 말이죠.ㅋㅋ

Write a comment.


Spring Security 2.0 Milestone 1 드디어 나옴.



스프링 포럼에서 젤 먼저 알려주는 군요.

다운로드 받기.
변경사항 보기.


위 XML 파일을 보시면 Spring Secutiry 2.0 이전의 설정 방법은 전부 주석처리를 해두었기 때문에, 비교하면서 볼 수 있습니다.

근데 왜 필요한 네임스페이스는 등록도 안 해둔거지..-_-;; 어떡하라고.. 벤 알렉스!

레퍼런스도 별로 바뀐게 없는 듯 합니다.
top

  1. Favicon of http://riosung.tistory.com BlogIcon 리오 2008.01.04 14:12 PERM. MOD/DEL REPLY

    그러게요. 희한하네요~ ㅋㅋ 그래도 무지 반갑네요 ^^

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.01.04 14:34 신고 PERM MOD/DEL

    네. XML 코드 줄어든 걸 보면 정말 기분이 좋아져요.ㅋㅋ

Write a comment.


Spring Security 2 조만간 볼 수 있을 듯



참조 : http://blog.interface21.com/main/2007/12/06/whats-new-in-spring-security-2/

다음 주 쯤에 배포가 될 것 같습니다. 벌써부터 기다려지네요. Ben Alext가 올린 글을 보면, 설정이 상당히 간결해 진것 같은데, 너무 간결해져서 다시 공부해야 할 것 같습니다. 수 많은 필터들을 직관적인 엘리먼트와 속성이름을 사용해서 감춰주길 기대하고 있습니다.

대강 보니, 사용법은 일단 web.xml에 Filter To Chain Proxy를 등록하던 저번과 비슷한데, 대신 등록하는  클레스가 Filter To Chain Proxyr가 아니라 org.springframework.web.filter.DelegatingFilterProxy 로 바뀐 것 같습니다. 그리고 수 많은 필터를 빈으로 등록해야 했던 부분이 다음과 같은 한 덩어리로 뭉쳐진 것 같습니다.

    <http autoConfig="true">
        <intercept-url pattern="/**" access="IS_AUTHENTICATED_REMEMBER" />
    </http>

    <repository>
        <user-service hash="md5:hex">
            <user name="rod" password="a564de63c2d0da68cf47586ee05984d7" authorities="ROLE_SUPERVISOR,ROLE_USER" />
        </user-service>
    </repository>

TSE 2007에서 Spring Security와 관련된 세션이 세 개나 된다고 하는데, 내년에도 올해처럼 재밌는 발표들이 가득한 TSE가 되면 좋겠습니다.
top

  1. Favicon of http://toby.epril.com BlogIcon 토비 2007.12.08 06:24 PERM. MOD/DEL REPLY

    Ben Alex는 참 느리기도 하지. 호주 사람이라서 그런지... 코알라 벤이라고 불러줘야겠다. 2.0 소개한지 1년만에 M1나오네, 정식 릴리즈는 한 일년은 더 기다려야 할 듯

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2007.12.08 07:52 PERM MOD/DEL

    ㅋㅋㅋ그래도 좋은거 만들어 줬자나요.

Write a comment.


Acegi 사용시 사용자 정보 접근하기



Acegi를 사용하여 인증을 거치면, 사용자 아이디(principal)가 session에 ACEGI_SECURITY_LAST_USERNAME 라는 속성으로 저장됩니다.

따라서, 뷰에서는 EL을 사용하여 ${ACEGI_SECURITY_LAST_USERNAME} 이런식으로 접근할 수 있으며, 컨트롤러 계층에서는

String loginId = (String) request.getSession().getAttribute("ACEGI_SECURITY_LAST_USERNAME");
이런식으로 접근할 수 있습니다.

HttpServletRequest 변수에 직접 전근할 수 없는 계층에서도 현재 로그인 되어 있는 사용자 정보에 접근할 수 있습니다.

String username = SecurityContextHolder.getContext().getAuthentication().getName();
이런 식으로 SecurityContextHolder를 통해서 현재 로그인 되어 있는 사용자의 정보를 가져올 수 있습니다.


top

Write a comment.


Acegi Security in one hour



시기적절하게 좋은 글 하나가 올라왔네요.
Acegi Security in one hour

Spring 2, Acegi, Sitemesh를 사용한 예제를 코드 중심으로 설명한 아티클입니다. 자세하기 보진 않았지만, 빠르게 Acegi를 사용해 보고 싶으신 분들에게 매우 유용할 듯 싶습니다. 제목은 한 시간이지만, 영어권이 아니기 때문에 한 두 시간정도가 되지 않을까 싶네요.ㅎㅎ

top

Write a comment.


왜 이름이 Acegi 인가?



Acegi Security의 이름이 왜 Acegi인가에 대해 Acegi를 만든 Ben Alex가 2007년 1월에 작성했던 글이 있습니다.

정말 영어 알파벳 홀수 1, 3, 5, 7, 9를 따서 만든거라고 합니다. 다만 처음 부터 지금의 Acegi Sicurity용으로 만든 이름을 아니였고 다른 시스템을 일컷는 것 같은데 BBS라고 하는데 뭔지 모르겠군요.

Anyway, 2003년 11월에 만들어서 ZIP 파일로 들고가서 로드 존슨과 융겐 휄러에게 보여주며 Spring Security로 제안을 했지만... 둘 다 너무 바쁜 나머지 제대로 검토할 시간이 없어서 Spring Security라고 하지 못하고 XXX Security System for Spring으로 이름을 지어야 했는데.. 그 때 바로 위에서 사용했었던 Acegi를 사용한 것이라고 합니다.

지금은 당당히 Spring Security라는 새 이름을 가지게 되었고, 단순한 이름의 변경이외에도 다양한 의미가 내포된 것 같군요.

Acegi의 엄청난 설정 내용을 보면서 전부 새로운 태그를 만들어서 확 줄이고 싶다는 생각이 들었는데.. 아마도 만들고 있겠죠?? Spring 2.1에 추가된 <context:annotation-config/> 이런 태그 처럼 여러개의 bean을 등록해야 할 때 묶어서 한방에 등록해주고 자주 설정하는 부분은 속성으로 설정할 수 있도록 해주면 훨씬 간편해 질 거라는 생각만 해봤습니다. 태그 만드는 방법은 토비님의 예전 포스팅에도 있었고 KSUG 1회 때의 약간 어려웠던 발표도 있었으며, Ben Hale의 Creating a Spring 2.0 namespace? Use Spring's AbstractBeanDefintionParser hierarchy. 이런 글도 있지만.. 아직 해보진 못했습니다. 해봐야겠네요. 앗. 갑자기 삼천포;;


top

Write a comment.


Spring Acegi 예제 애플리케이션



어제 올렸던 Spring Acegi Tutorial 아티클에서 사용한 예제 애플리케이션입니다. Acegi의 핵심 기능인 인증과 권한을 테스트 해보기 위한 매우 간단한 예제 애플리케이션입니다.



Spring 1.2 rc1, Acegi 1.0.0 rc2 를 사용한 코드입니다.
JDK 5.0 이상, Tomcat 5.5 이상에서 동작합니다.

사용법은 간단합니다. 톰캣으로 돌리면 다음과 같은 화면을 볼 수 있습니다.
사용자 삽입 이미지
여기서 위쪽 링크는 일반 user만 들어갈 수 있고 아랫 쪽 링크는 admin만 들어갈 수 있습니다. dispatcher-servlet.xml의 userDetailsService 빈을 살펴 보시면 해당 메모리 DB로 id, 비번, role 을 설정 해 둔 것을 볼 수 있습니다.
사용자 삽입 이미지
위 쪽 링크를 클릭하시면 인증 화면이 뜹니다. 여기서 user, userpass 라고 입력하시면 일반 user로 로그인 할 수 있습니다.
사용자 삽입 이미지
로그인에 성공하면 다음과 같은 일반 폼 화면이 뜨고 여기서 아무 값이나 입력하면 결과를 확인할 수 있습니다. 그리고 로그아웃도 할 수 있죠. 만약 위의 로그인 화면에서 로그인이 실패하면 다음과 같은 페이지를 볼 수 있습니다.
사용자 삽입 이미지
이번에는 admin만 접근할 수 있는 첫 번쨰 화면의 두 번째 링크로 들어가겠습니다. admin의 id와 비번은 admin, adminpass입니다.
사용자 삽입 이미지
자 이제 거의 다 테스트를 해봤습니다. 한 가지만 해보면 끝입니다. admin 로그인 화면 또는 user 로그인 화면에서 해당 권한이 없는 id와 비번으로 로그인을 시도합니다. 즉 admin 로그인 창에서 user/userpass를 입력합니다. 그럼 다음과 같은 화면을 볼 수 있습니다.
사용자 삽입 이미지
누가 이런 일을 했을까요? ExceptionTranslationFilter 이겠죠? 물론 보여준건 브라우져지만, 브라우져에게 403 에러를 보낸 건 ExceptionTranslationFilter의 일 중 하나입니다.



top

Write a comment.


Spring Acegi Tutorial



참조 :  Spring Acegi Tutorial

Spring Security(Acegi Security)에 대한 맛보기용 아티클로 매우 적당한 것 같습니다. 먼저 Acegi에서 흔히 사용하는 용어에 대해 설명을 하고, 간단한 애플리케이션을 통해 실제 Acegi를 적용하여 구동하고 있는 녀석을 살펴본 뒤에, 해당 샘플에서 사용한 필터들과 각각의 필터들의 종속성을 살펴보고 있습니다. 개인적으로는 이러한 구성이 어렵고 생소한 프레임워크를 공부하는데 가장 좋은 것 같습니다.

Acegi에서 사용하는 용어
- Authentication(인증) : "너는 누구냐?"
    - principal(주체) : username
    - credentials(신용) : password
- Authorization(권한) : "뭐 할려고?"
    - object definitions : secured resources, 관계자외 출입 금지인 자원

샘플 애플리케이션  
사용자 삽입 이미지
- 두 링크 모두 로그인으로 인증을 하며, 이때 validation을 해서 에러페이지로 이동시킬 수 있습니다.
- 특정 url과 role을 맵핑한 정보를 사용하여 권한 체크를 합니다.

샘플에서 사용한 필터들과 그들의 종속성
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
예전에 토비님께서 작성하셨던 "나의 Spring Acegi Security Framework 학습기"에 보면 더 많은 필터들이 있지만 일단 여기서는 위의 예제에서 사용한 httpSessionContextIntegrationFilter, authenticationProcessingFilter, exceptionTranslationFilter, filterInvocationInterceptor 네 개만 살펴보겠습니다.

1. AuthenticationProcessingFilter(위 그림에서 formAuthenticationProcessingFilter)
Http Request가 지나가는 첫 번째 필터로 인증과 관련된 요청을 처리하는데 특화된 필터 입니다. 즉, 로그인과 관련된 요청에 특화 되었기 때문에 폼 서브밋 URL 값(filterProcessUrl 속성)이나 로그인 실패시 URL 값(authenticationFailureUrl 속성)들을 설정합니다.

2. HttpSessionContextIntegrationFilter
위에서 살펴보았던 AuthenticationProcessingFilter가 사용하고 있는 AuthenticationManager에 의해 만들어지고 관리되는 Authentication 객체를 Thread Local을 사용하여(servlet이 thread기반이라..) 감싸서(wrap) 해당 쓰레드 내의 여러 request에서 같은 Authentication 객체를 공유할 수 있도록 하는 역할을 합니다.

3. ExceptionTranslationFilter
security 시스템의 중추적인 역할을 하는 두 개의 필터 중에 하나이며(다른 하나는 FilterSecurityInterceptor), 인증과 권한에 관련되어 발생하는 예외(AcegiSecurityException)를 잡아서 다음의 두 가지 중 하나로 처리 합니다.
- Authentication 객체 부재로 인한 예외 일 경우 : AuthenticationEntryPoint 를 사용하여 사용자에게 로그인을 요구함.
- FilterSecurityInterceptor에 의해 던져진 권한이 없어서 발생한 예외 일 경우 : 브라우저에게 SC_FORBIDDEN (HTTP 403) 에러를 던집니다.

4. FilterSecurityInterceptor
secured resources에 대한 정의를 담고 있습니다. 이곳에서 실제 특정 URL과 role을 맵핑하는 정보인 objectDefinitionSource 속성을 설정하고 있습니다. 이 속성을 설정할 때는 두 개의 dialect를 지정해 줍니다. 이름만 봐도 대강 짐작이 가는 dialect기 때문에 설정 내용을 살펴보시면 됩니다.
사용자 삽입 이미지




top

Write a comment.