Whiteship's Note


[Spring Security] http 네임스페이스 쓰려면 필터 이름은 항상 고정(?)

Spring Security/etc : 2010.06.29 17:02


http://static.springsource.org/spring-security/site/docs/3.0.x/reference/appendix-namespace.html#nsa-http-attributes

<filter>
<filter-name>securityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

   <filter-mapping>
       <filter-name>securityFilterChain</filter-name>
       <url-pattern>/*</url-pattern>
   </filter-mapping>
    

자 이렇게 필터를 설정하고 

<http>
        <intercept-url pattern="/base/color/mgt" access="ROLE_USER" />
        <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
<form-login login-page="/login" />
<logout logout-success-url="/index" />
<remember-me />
</http>

    <beans:bean id="smdisUserDetailsService" class="smdis.common.security.SmdisUserDetailsService"/>

<authentication-manager alias="authenticationManager">
<authentication-provider user-service-ref="smdisUserDetailsService"/>
</authentication-manager>

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

이렇게 시큐리티 설정을 했다.

잘 돌아갈까?? 안 돌아간다.. 시큐리티 네임스페이스를 사용해서 <http>를 등록하면 FileChainProxy 빈 이름은 항상 springSecurityFilterChain이 된다. 그래서 필터 이름을 springSecurityFilterChain으로 설정해줘야 한다.

뭐.. DelegatingFilterProxy 필터 자체에 targetBeanName 속성을 사용해서 연결할 빈 이름을 설정할 수도 있지만 기본적으로 이 이름은 필터 이름을 따르게 된다. 필터 이름을 바꾸고 targetBeanName을 또 설정해 주느니 그냥 필터 이름을 springSecurityFileterChain으로 하는게 좋겠다.

<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

    <filter-mapping>
        <filter-name>springSecurityFilterChain</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
top


[Spring Security] sec:authentication

Spring Security/etc : 2010.05.11 07:36


참조: http://static.springsource.org/spring-security/site/docs/3.0.x/reference/taglibs.html

스터디의 각 모임에는 댓글을 달 수 있습니다. 삭제 기능이 필요해져서 댓글 삭제 기능을 만들었는데 이것을 일반적인 User-Role 기반 Voter를 사용해서 권한 처리하는것이 그렇게 단순하지는 않습니다. 

관리자 권한이 있는 사람만 삭제할 수 있게 할까요? 아님 회원 권한을 가진 사람은 누구나 삭제하게 할까요? 비즈니스 룰이야 정하기 나름이지만 그렇게 무식하게 정하고 싶지는 않았습니다. 작성자만 자신이 작성한 댓글을 삭제하는 것이 가장 정당해 보입니다.

먼저 문제가 되는 부분은 뷰. 삭제 버튼을 감춰야 합니다.

<sec:authentication property="principal.username" var="currentUserName"/>
<c:if test="${currentUserName == comment.writer.email}">
//감출 버튼
</c:if>

이렇게 authenrication 태그를 사용해서 principal 객체와 그 속성값에 접근할 수 있습니다. 현재 로그인 되어있는 사용자의 username을 가져와서 현재 댓글 작성자의 email과 비교합니다. 봄싹에서는 email을 아이디로 사용하고 있기 때문에 이렇게 비교합니다. 그 둘이 일치하는 경우에만 버튼을 보여줍니다. 

참 쉽죠;

하지만... 버튼을 감춘다고 다가 아니죠. URL 보내면 보내집니다. 웹 보안으로는 위에서 언급했듯이 힘듭니다. 이럴 때는 서비스 쪽에서 객체 정보와 pricipal 정보를 기반으로 권한 처리를 해주면 되겠습니다. 그건 다음에.


top


[스프링 시큐리티 3.0] @PreAuthorize

Spring Security/etc : 2009.08.23 14:38


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

시큐리티 설정 파일에 위와 같이 설정하면 @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter를 사용할 수 있습니다.

이들 애노테이션에서는 스프링 EL을 사용해서 현재 사용자 정보에 접근하거나, (pre 인 경우)메서드의 인자값 또는 (post 인 경우)메서드의 반환값의 정보에 접근할 수 있습니다.

    @PreAuthorize("(#study.manager.email == principal.Username) or hasRole('ROLE_ADMIN')")
    public void updateStudy(Study study) {
        repository.update(study);
    }

위 예제는 다음 주에 오픈 할 봄싹 프로젝트에서 사용하고 있는 코드입니다. Study를 수정하려는 사람이 관리자이거나, 스터디를 만든 사람인지 확인한 뒤에 메서드를 실행합니다. 만약 해당 EL이 false로 판단되면 Access Dinied 에러를 던져줍니다.

애노테이션을 메서드에만 붙이지 않고 클래스에도 붙여서 클래스에 정의한 모든 메서드에 적용할 수도 있습니다. 이런식으로요.

@Service
@Transactional
@PreAuthorize("hasRole('ROLE_USER')")
public class StudyService {

...

}





top


Using Spring Security 2

Spring Security/etc : 2008.09.27 10:32


참조: http://www.parleys.com/display/PARLEYS/Home#slide=1;title=Using%20Spring%20Security%202;talk=19267601

귿. 발표자 말투도 느린편이고, 억양도 알아들을만 합니다. 어제 들은 아리드안 코일러의 AOP 발표에 비하면 훨씬 알아 듣기 쉬운것 같네요.

데모 코드는 스크린캐스팅에 잡히지 않아서 참조할 수 없었지만, 대충 말해주면서 코딩하기 때문에 어떻게 코딩하는지 눈치챌 수 있습니다. 물론 Spring Security 2에 새로 도입한 스키마들을 알고 계셔야게죠.

몇 가지 정리해둡니다.

1. URL 권한 확인으로는 충분하지 않다.
- 리소스랑 URL이랑 1:1로 맵핑되는게 아닌 경우.
/listCustomers.html 과 /print.view?page=listCustomers 이 두 개의 URL이 같은 리소스를 나타낼 경우 권한처리를 어떻게 할 것인가
- URL이 없을 수도 있다.
Web Application이 아닌 경우 권한 처리는?
- 여러 Ajax 요청을 처리하는 하나의 URL
헤더 정보만 조금씩 다른데, 그 정보에 따라 권한 처리해야 할테네 어떻게 할텐가?

=> Method Authonrization!!

2. 메소드 권한처리
- AspectJ 포인트컷 표현식 사용 가능
- @Secured 애노테이션 사용 가능
- JSR 250의 @RoleAllowed 사용 가능

3. 베스트 프랙티스
- URL 체크로 개괄적인(corse grained) 권한 처리를 한다.
- 메소드 체크로 세밀한(fine grained) 권한 처리를 한다.
- Role 사용하지 말고, Right를 사용하라. User <--> Role <--> Riht
@Secured("PERM_DELETE_USER)
public oid deleteUser(User user)

마지막 문구

Spring Security is more powerful than Acegi was
... and now it is also easy ;-)


top


Whiteship's Spring Security 총 정리

Spring Security/etc : 2008.05.07 18:16


기본 개념

1.1. What is Acegi Security? : Acegi 정의와 개요.
2.2 Shared Components : 주요 구성 요소
2.3 Authentication (2) : 인증 절차를 도식화 했습니다.
Spring Acegi Tutorial : 가장 중요한 필터들에 대한 설명과 해당 필터들이 물고 있는 빈들을 보여줍니다.
3.2 Filters : 전체 필터들 간단 요약
4. Channel Security : https 사용에 대한 개요
Access Decision Manager : 접근 권한 관리를 하는 핵심 컴포넌트

웃긴 이야기

왜 이름이 Acegi 인가? : AbCdEfGhI, 스프링 서브 프로젝트가 되기 위한 노력.
Acegi 필터 등록할 때 발생할 수 있는 몹쓸 버그 : 필터 체인 사용하던 시절에 발생하던 웃긴 버그
Spring Security 설정 분류 및 커스터마이징 (5) : Acegi 관련 XML이 커져서 어떻게 나눌지 고민했던 시절

Spring Security(Acegi) 2.0 이전

Acegi로 웹 애플리케이션 보안하기 1
Acegi로 웹 애플리케이션 보안하기 2
Acegi로 웹 애플리케이션 보안하기 3
Acegi로 웹 애플리케이션 보안하기 4
Acegi로 웹 애플리케이션 보안하기 5 (2)
Acegi로 웹 애플리케이션 보안하기 6
Acegi로 웹 애플리케이션 보안하기 7

Spring Security 2.0 네임스페이스

Security Namespace Configuration PART 1 (1)
Security Namespace Configuration PART 2

많이 미흡하지만 이 정도면 Spring Security 학습에 어느 정도 도움이 되실 거라고 생각합니다.
Live with Passion!!! Live with Spring!!
top


Spring Security 2.0.1 Released

Spring Security/etc : 2008.05.03 09:54


참조 : http://www.springframework.org/node/648

빠르네요 빨라. 이번에는 버그 수정과 몇 가지 개선사항들이 있었습니다.
- Remember me 버그 수정
- JPA 붙인거에 전역 메소드 시큐리티 필터 버그 수정
- ...
top