Shiro vs. SpringSecurity [fechado]

Atualmente, estou avaliando estruturas de segurança baseadas em Java, sou um usuário do Spring 3.0 e, portanto, parecia que o SpringSecurity seria a escolha certa, mas a segurança do Spring parece sofrer de complexidade excessiva, certamente não parece estar facilitando a implementação, Shiro parece ser muito mais coerente e fácil de entender. Estou procurando listas de prós e contras entre esses dois frameworks.

Também concordo que o Spring Security parece muito complicado (para mim). Certamente, eles fizeram coisas para reduzir a complexidade, como criar namespaces XML personalizados para reduzir a quantidade de configuração XML, mas, para mim, eles não abordam meu problema fundamental pessoal com o Spring Security: seus nomes e conceitos geralmente são confusos para mim. É difícil apenas 'entender'.

No momento em que você começa a usar o Shiro, você apenas 'entende'. O que era difícil de entender no mundo da segurança é muito mais fácil de entender. Coisas que são insuportavelmente difíceis de usar no JDK (por exemplo, Cifras) são simplificadas para um nível que não é apenas suportável, mas geralmente uma alegria de usar.

Por exemplo, como você hash + salt uma senha e a base64 a codifica em Java ou Spring Security? Nem são tão simples e intuitivos quanto a solução de Shiro:

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

Não há necessidade de codec comum ou qualquer outra coisa. Apenas a jarra de Shiro.

Agora, com relação aos ambientes Spring, a maioria dos desenvolvedores do Shiro usa o Spring como seu ambiente principal de aplicativos. Isso significa que a integração do Shiro ao Spring é excelente e tudo funciona excepcionalmente bem. Você pode ter certeza de que, se estiver escrevendo um aplicativo Spring, terá uma experiência de segurança completa.

Por exemplo, considere o exemplo de configuração do Spring XML em outra postagem neste segmento. Aqui está como você faria (essencialmente) a mesma coisa no 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>

Embora um pouco mais detalhado que o outro exemplo do Spring, é mais fácil ler o IMO.

Você também descobrirá que usar as definições de cadeia de filtros do Shiro é provavelmente a maneira mais fácil de definir cadeias de filtros gerais e regras de segurança baseadas na Web de todos os tempos! Muito melhor do que defini-los no web.xml.

Finalmente, Shiro oferece extrema 'conectabilidade' também. Você verá que é possível configurar e / ou substituir praticamente qualquer coisa devido à arquitetura compatível com injeção de POJO / Shiro da Shiro. O Shiro padroniza quase tudo para padrões normais e você pode substituir ou configurar apenas o necessário.

No fim das contas, acho que escolher um desses dois é mais sobre o seu modelo mental - qual dos dois faz mais sentido e é mais intuitivo para você? Para alguns, será Shiro, para outros, será Spring Security. Shiro funciona muito bem em ambientes Spring, então eu diria que escolha com base em qual dos dois você gosta mais e faz mais sentido para você.

Para saber mais sobre a integração do Shiro no Spring: http://shiro.apache.org/spring.html

Não tenho experiência com o Shiro e concordo "parcialmente" com o que você disse sobre o Spring Security. Antes do Spring Security 3.x, o Spring Security (ou Acegi) era muito doloroso de configurar. Uma configuração simples baseada em função terá pelo menos 140 linhas de configuração XML enigmática ... Eu sei disso porque na verdade eu contei as linhas. Era algo em que você configurava uma vez e reza para que funcione para sempre sem você tocar na configuração novamente, porque você pode garantir que esqueceu o que significa toda a configuração. :)

Com o Spring Security 3.x, ele melhorou tremendamente. Ele introduz um securityespaço para nome que reduz drasticamente a configuração de 140 linhas para ~ 30 linhas. Aqui está um exemplo do Spring Security 3.x de um dos meus projetos: -

<?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>

A beleza do Spring Security 3.x é que ele é extremamente configurável, o que contribui para um dos principais contras: muito complicado de entender. A documentação também não é fácil de ler, porque estou apenas parcialmente familiarizada com alguns dos termos usados ​​pelo Spring Security. No entanto, as opções existem se você precisar criar sua configuração personalizada ou controlar o quão granular você deseja que sua segurança seja. Ou então, você pode seguir as <30 linhas acima para executar uma verificação de segurança baseada em função.

O que eu realmente gosto na Spring Security é que, uma vez configurada, a segurança é integrada ao projeto sem problemas. É como se o código do projeto real não soubesse a existência da segurança ... e isso é bom, porque me permite desanexar ou atualizar facilmente o componente de segurança no futuro (por exemplo: alterar a autenticação do banco de dados para LDAP / CAS auth).

Eu estava usando o Spring Security (versão 3.1) há alguns meses e estava bastante feliz com isso. É realmente poderoso e possui um recurso muito bom, especialmente depois de implementar tudo manualmente, como eu fiz antes! Porém, como eu li em algum lugar, algo que você configurou uma vez perto do início do desenvolvimento do aplicativo e depois orou para que ele continuasse trabalhando até o fim, porque se você precisar corrigi-lo, provavelmente esqueceu a maioria das coisas que você tinha que parametrizar.

Mas então surgiu um novo projeto, com requisitos de segurança mais complexos. Em resumo, tivemos que implementar algum tipo de SSO personalizado entre alguns aplicativos da web relacionados.

Eu sabia exatamente o que queria alcançar em termos de lógica HTTP, cookies, IDs de sessão e outras coisas, e o que deveria acontecer em que ordem, mas passei a maior parte de um dia lutando com as APIs do Spring Security e ainda não consegui entender. descobrir exatamente qual classe ou interface devo implementar ou substituir e como conectá-las ao contexto. Toda a API parecia realmente complexa e um pouco esotérica às vezes. E embora o documento seja bastante bom para os casos de uso geral e até mesmo para algumas customizações, ele não foi profundo o suficiente para atender às minhas necessidades.

Depois de ler as respostas aqui e em outros lugares da Web, tive a impressão de que Shiro seria mais fácil de entender e personalizar de acordo com minhas necessidades. Então, eu tentei.

E estou feliz por ter conseguido, porque depois de um dia trabalhando nisso, consegui aprender o suficiente sobre as APIs não apenas para configurar um sistema básico de autenticação e autorização no meu aplicativo da Web Spring sem problemas, mas também para implementar o comportamento SSO personalizado que eu estava procurando por. Eu só tinha que estender 2 ou 3 classes e a coisa toda levou apenas cerca de 25 linhas de configuração XML no meu contexto de primavera.

Portanto, como conclusão, sobre a facilidade de uso e os aspectos da curva de aprendizado, o Shiro é realmente bastante agradável, e acho que provavelmente o acompanharei no futuro, a menos que encontre alguns recursos ausentes ou algum outro problema (o que eu não tenho) tão longe).

TL; DR: Ambos são poderosos, mas Shiro é muito mais fácil de aprender.