Как использовать отдельные области для аутентификации и авторизации с помощью Shiro и CAS?

Проблема, с которой вы столкнулись, связана с тем, что и CasRealm, и JdbcRealm расширяют как AuthorizingRealm (Authorizer), так и AuthenticatingRealm. Первый шаг, который я бы сделал, это JdbcRealm. Реализация JdbcRealm наследует AuthenticatingRealm#supports(AuthenticationToken token) реализация метода. Если вы расширите JdbcRealm и переопределите метод «supports», чтобы он возвращал «false» для всех типов токенов, JdbcRealm больше не будет использоваться для аутентификации.

@Override
public boolean supports (AuthenticationToken token) {
    return false;
}

CasRealm — это отдельная история, нет способа (насколько я знаю) легко сказать Широ не использовать область, которая реализует Авторизатор при проверке разрешений. Меня лично разочаровывает то, что реализация по умолчанию для большинства протоколов предполагает необходимость как авторизации, так и аутентификации. Я бы предпочел, чтобы каждая из них была разделена на две реализации (например, AuthenticationCasRealm, AuthorizingCasRealm).

Логика проверки разрешений при использовании нескольких областей задокументирована здесь. . Конкретный текст, который ссылается на это поведение:

1. Создайте новый класс AuthenticationCasRealm, который расширяет org.apache.shiro.realm.AuthenticatingRealm и реализует org.apache.shiro.util.Initializable.

2. Скопируйте и вставьте содержимое существующего исходный код CasRealm в ваш новый класс "AuthenticatingCasRealm". (Я знаю, что путь копирования и вставки существующего кода часто не одобряется, однако в описанных обстоятельствах я не знаю другого способа решения проблемы.)

3. Удалите все методы, которые были реализованы для org.apache.shiro.realm.AuthorizingRealm.

4. Обновите конфигурацию Shrio, чтобы она ссылалась на вашу новую реализацию AuthenticationCasRealm.

Основываясь на этих изменениях, теперь у вас должно быть две настраиваемые реализации в вашей конфигурации Shrio; один из JdbcRealm переопределяет метод «поддерживает» и один из CasRealm удаляет методы API авторизации.

Существует один дополнительный метод, основанный на явном объявлении Авторизатор через конфигурацию Широ, которая может лучше подходить для вашей ситуации.

Вот явное объявление Authorizer и Authenticator через пользовательское расширение ShiroFilter. Оба были реализованы и зарегистрированы для предоставленных имен JNDI при запуске.

public class CustomShiroFilter extends ShiroFilter {

    @Override
    public void init () throws Exception {
        super.init();
        DefaultWebSecurityManager dwsm = (DefaultWebSecurityManager) getSecurityManager();
        dwsm.setAuthorizer((Authorizer)JndiUtil.get("realms/authorizerRealm"));
        dwsm.setAuthenticator((Authenticator)JndiUtil.get("realms/authenticatorRealm"));
    }
}

Вам нужна только одна область, которая расширяет область AuthorizingRealm. Это обеспечит

• authc: метод doGetAuthenticationInfo (сервер CAS)
• авторизация: метод doGetAuthorizationInfo (JDBC)

Надеюсь это поможет

У нас был аналогичный случай, когда мы использовали область LDAP для аутентификации и использовали стандартный файл shiro.ini для авторизации для простого варианта использования.

Чтобы дополнить ответ «justin.hughey», я даю конфигурацию плана (также может быть spring), чтобы ваш вариант использования работал:

<!-- Bean for Authentication --> 
<bean id="rccadRealm" class="org.mydomain.myproject.security.shiro.ldap.realm.LdapRealm"
        init-method="init">
    <property name="searchBase" value="${realm.searchBase}" />
    <property name="singleUserFilter" value="${realm.singleUserFilter}" />
    <property name="timeout" value="30000" />
    <property name="url" value="${contextFactory.url}" />
    <property name="systemUsername" value="${contextFactory.systemUsername}" />
    <property name="systemPassword" value="${contextFactory.systemPassword}" />
</bean>

<!-- Bean for Authorization --> 
<bean id="iniRealm" class="org.mydomain.myproject.security.realm.AuthzOnlyIniRealm">
    <argument value="file:$[config.base]/etc/shiro.ini"/>
    <property name="authorizationCachingEnabled" value="true" />
</bean>

<bean id="myModularAuthenticator"
    class="org.mydomain.myproject.security.service.MyModularRealmAuthenticator">
    <property name="realms">
        <list>
            <ref component-id="ldapRealm" />
        </list>
    </property>
</bean>

<bean id="mySecurityManager" class="org.apache.shiro.mgt.DefaultSecurityManager">
    <property name="authenticator" ref="myModularAuthenticator" />
    <property name="authorizer" ref="iniRealm" />
    <property name="cacheManager" ref="cacheManager" />
</bean>

Главное, что нам понадобилось:

• a modularRealmAuthenticator и пусть стратегия по умолчанию (поскольку существует только одна область) для «аутентификатора»
• специальный AuthzOnlyIniRealm, который переопределяет метод supports, возвращающий false, чтобы предотвратить его использование для аутентификации.

Наша реализация LdapRealm — это просто расширение Shiro ActiveDirectoryRealm.