시로 대 스프링 시큐리티 [닫기]

현재 Java 기반 보안 프레임 워크를 평가하고 있으며 Spring 3.0 사용자이므로 SpringSecurity가 올바른 선택 인 것처럼 보였지만 Spring 보안은 과도한 복잡성을 겪고있는 것으로 보입니다. 확실히 보안을 구현하는 것처럼 보이지는 않습니다. 시로는 훨씬 일관성 있고 이해하기 쉬운 것 같습니다. 이 두 프레임 워크 사이의 장단점 목록을 찾고 있습니다.

나도 스프링 시큐리티가 너무 복잡하다고 생각한다. 물론, 그들은 XML 구성의 양을 줄이기 위해 사용자 정의 XML 네임 스페이스를 만드는 것처럼, 복잡성을 줄일 수있는 일들을,하지만 나를 위해, 이러한 해결하지 않는 나의 봄 보안과 개인 근본적인 문제 : 그 이름과 개념은 종종 일반에 혼동 나를. 그냥 '얻기'가 어렵습니다.

두 번째로 시로를 사용하기 시작하면 '얻을'것입니다. 보안 세계에서 이해하기 어려운 것은 이해하기가 훨씬 쉽습니다. JDK에서 사용하기 어려운 것들 (예 : 암호)은 견딜 수있는 수준이 아니라 종종 사용하기 쉬운 수준으로 단순화되었습니다.

예를 들어, 비밀번호를 해시 + 소금하고 Java 또는 Spring Security에서 base64로 인코딩하는 방법은 무엇입니까? 시로의 솔루션만큼 간단하고 직관적 인 것도 아닙니다.

ByteSource salt = new SecureRandomNumberGenerator().nextBytes();
new Sha512Hash(password, salt).toBase64();

공통 코덱이나 그 밖의 다른 필요가 없습니다. 단지 시로 항아리.

이제 스프링 환경과 관련하여 대부분의 시로 개발자는 스프링을 기본 애플리케이션 환경으로 사용합니다. 그것은 시로의 스프링 통합이 훌륭하다는 것을 의미하며 모두 훌륭하게 작동합니다. Spring 앱을 작성하는 경우 보안 경험이 풍부하다는 것을 확신 할 수 있습니다.

예를 들어,이 스레드의 다른 게시물에있는 Spring XML 구성 예제를 고려하십시오. Shiro에서 (본질적으로) 같은 일을하는 방법은 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd>

<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login.jsp"/>
    <property name="successUrl" value="/home.jsp"/>
    <property name="unauthorizedUrl" value="/unauthorized.jsp"/>
    <property name="filterChainDefinitions">
        <value>
        /secure/** = authc
        /** = anon
        </value>
    </property>
</bean>

<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
    <property name="realm" ref="myRealm"/>
</bean>

<bean id="myRealm" class="...">
    ...
</bean>

다른 Spring 예제보다 약간 더 장황하지만 IMO를 읽는 것이 더 쉽습니다.

또한 Shiro의 필터 체인 정의를 사용하는 것이 일반 필터 체인과 웹 기반 보안 규칙을 정의하는 가장 쉬운 방법 일 것입니다! web.xml에서 정의하는 것보다 훨씬 좋습니다.

마지막으로 시로는 극단적 인 '플러그 기능'도 제공합니다. Shiro의 POJO / 주입 친화적 인 아키텍처 덕분에 무엇이든 구성 및 / 또는 교체 할 수 있음을 알 수 있습니다. Shiro는 거의 모든 것을 기본값으로 설정하고 필요한 것만 무시하거나 구성 할 수 있습니다.

하루가 끝나면이 두 가지 중 하나를 선택하는 것이 당신의 정신 모델에 관한 것이라 생각합니다. 두 가지 중 어느 것이 더 합리적이고 직관적입니까? 어떤 사람들에게는 시로 (Shiro), 다른 사람들에게는 봄 보안 (Spring Security)이 될 것입니다. Shiro는 봄 환경에서 훌륭하게 작동하므로 둘 중 어느 것을 더 좋아하고 가장 적합한 지에 따라 선택한다고 말하고 싶습니다.

시로의 스프링 통합에 대한 자세한 내용은 다음을 참조하십시오 : http://shiro.apache.org/spring.html

시로를 사용한 경험이 없으며 Spring Security에 대해 말한 것에 부분적으로 동의합니다. Spring Security 3.x 이전에는 Spring Security (또는 Acegi)를 설치하기가 매우 어려웠습니다. 간단한 역할 기반 구성에는 최소한 140 줄의 암호화 XML 구성이 필요합니다. 실제로 실제로 줄을 세었기 때문에 이것을 알고 있습니다. 한 번만 설정하면 구성을 다시 만지지 않아도 영원히 작동하도록기도합니다. 모든 구성의 의미를 잊었 음을 확신 할 수 있기 때문입니다. :)

Spring Security 3.x에서는 크게 개선되었습니다. security140 줄에서 ~ 30 줄로 구성을 크게 단축시키는 네임 스페이스를 소개 합니다. 내 프로젝트 중 하나의 Spring Security 3.x의 예는 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd">

    <security:http auto-config="true">
        <security:form-login login-page="/index.do" authentication-failure-url="/index.do?login_error=1" default-target-url="/index.do"
            always-use-default-target="true" />
        <security:logout logout-success-url="/index.do" />
        <security:intercept-url pattern="/secure/**" access="ROLE_ADMIN,ROLE_USER" />
        <security:intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    </security:http>

    <bean id="customAuthenticationProvider" class="my.project.CustomAuthenticationProviderImpl">
        ...
    </bean>

    <security:authentication-manager>
        <security:authentication-provider ref="customAuthenticationProvider" />
    </security:authentication-manager>

</beans>

Spring Security 3.x의 장점은 매우 구성하기 쉽다는 점입니다. 이해하기에는 너무 복잡합니다. Spring Security가 사용하는 용어 중 일부에만 익숙하기 때문에 문서를 읽기가 쉽지 않습니다. 그러나 사용자 지정 구성을 만들거나 보안 수준을 세분화해야하는 경우 옵션이 있습니다. 또는 위의 <30 줄을 사용하여 역할 기반 보안 검사를 수행 할 수 있습니다.

Spring Security에 대해 내가 정말로 좋아하는 것은 일단 설정되면 보안이 프로젝트에 완벽하게 통합됩니다. 실제 프로젝트 코드가 보안의 존재를 알지 못하는 것과 같습니다 ... 그리고 나중에 보안 구성 요소를 쉽게 분리하거나 업그레이드 할 수 있기 때문에 좋습니다 (예 : 데이터베이스 인증을 LDAP / CAS로 변경하십시오) 인증).

나는 몇 달 동안 스프링 보안 (버전 3.1)을 사용하고 있었고 매우 기뻤습니다. 그것은 정말 강력하고 아주 좋은 기능을 가지고 있습니다. 특히 이전처럼 손으로 모든 것을 구현 한 후에! 그러나 어딘가에서 읽은 것처럼 앱 개발 시작 부분 근처에서 한 번 설정 한 다음 끝까지 계속 작동하도록기도하십시오. 아마도 당신이 매개 변수로 삼아야 할 것들 대부분을 잊었을 것입니다.

그러나 더 복잡한 보안 요구 사항을 갖춘 새로운 프로젝트가 등장했습니다. 요컨대, 우리는 두 개의 관련 웹앱 사이에 일종의 커스텀 SSO를 구현해야했습니다.

HTTP 로직, 쿠키, 세션 ID 및 항목과 관련하여 달성하고자하는 것과 정확히 어떤 순서로 발생 해야하는지 정확히 알고 있었지만 Spring Security API로 어려움을 겪고있는 하루 중 더 나은 시간을 보냈지 만 여전히 파악할 수 없었습니다. 내가 구현하거나 재정의 한 클래스 또는 인터페이스와 컨텍스트에 연결하는 방법을 정확하게 파악하십시오. 전체 API는 때때로 복잡하고 약간 난해하다고 느꼈습니다. 이 문서는 일반적인 사용 사례 및 일부 사용자 정의에 매우 적합하지만 내 요구를 충족시키기에 충분하지 않습니다.

여기 및 웹의 다른 곳에서 답변을 읽은 후 Shiro가 이해하기 쉽고 내 요구에 맞게 사용자 정의 할 수 있다는 인상을 받았습니다. 그래서 나는 그것을 시도했다.

그리고 하루를 보낸 후에 API에 대해 충분히 배우고 문제없이 Spring webapp에서 기본 인증 및 권한 부여 시스템을 설정할뿐만 아니라 사용자 정의 SSO 동작을 구현할 수 있었기 때문에 기뻤습니다. 찾고있는. 나는 2 ~ 3 개의 클래스 만 확장해야했고 스프링 컨텍스트에서 XML 구성의 약 25 줄 만 걸렸습니다.

결론적으로, 사용 편의성 및 학습 곡선 측면에서 시로는 실제로 매우 적합하며 일부 기능이 부족하거나 다른 문제가 발생하지 않는 한 향후에도 계속 사용할 것이라고 생각합니다. 지금까지).

TL; DR : 둘 다 강력하지만 시로는 배우기가 훨씬 쉽습니다.