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

я работаю над веб-приложением, в котором несколько приложений проходят проверку подлинности через сервер единого входа CAS. Однако каждое приложение должно поддерживать свои соответствующие роли, и эти роли хранятся в базе данных, специфичной для приложения. Итак, мне нужно иметь 2 сферы, одну для CAS (для authc) и другую для БД (для authz).

Это мой текущий конфиг сиро. Я'm перенаправление на CAS работает нормально, но вошедший в систему пользователь (Subject) не 'Кажется, что в него загружены роли / разрешения (например, SecurityUtil.isPermitted () не работает должным образом)


        
        
        
        
        

        
        
        
    

    
    
        
        
        
        
        
    
    


    
        
            
                
                
            
        
        
        
    


        
    


    
        
        
        
        
        
            
                     
            
        
        
             
                
                /shiro-cas = casFilter
                /login = anon
                /logout = logout
                /error = anon
                /static/** = anon
                /** = authc
            
        
    

Способ регистрации областей в securityManager должен быть правильным. Я могу'Т действительно найти хороший пример установки.

У меня есть 2 вопроса здесь:

Что такое правильная настройка / конфигурация для достижения вышеупомянутого сценария?Как лучше всего управлять пользователями и ролями в разных / отдельных приложениях?
 Volker Seibt11 дек. 2013 г., 16:56
В casRealm мы опускаемdefaultRoles имущество.
 Volker Seibt11 дек. 2013 г., 16:50
Вы проверяли роли? Мы используем очень похожую конфигурацию с casRealm для аутентификации и textRealm и / или activeDirectoryRealm для авторизации. Для разрешений мы используем пользовательскую реализацию RolePermissionResolver.

Ответы на вопрос(3)

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

authc: методdoGetAuthenticationInfo (Сервер CAS)authz: методdoGetAuthorizationInfo (JDBC)

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

 Volker Seibt11 дек. 2013 г., 16:47
Если вы используете вышеупомянутый подход, вам нужно только настроить существующие области и не требовать никакой пользовательской реализации.

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

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

 

    
    
    
    
    
    


 

    
    



    
        
            
        
    



    
    
    

Главное, что нам нужно:

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

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

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

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

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

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

Шаг 4: Проверяется каждое настроенное Царство, чтобы увидеть, реализует ли оно тот же интерфейс Авторизатора. Если так, то ЦарствоВызывается собственный соответствующий метод hasRole *, checkRole *, isPermitted * или checkPermission *.

Исходя из этого, вы теоретически можете переопределить каждый из названных методов и все их перегруженные реализации, чтобы всегда возвращать "ложный".

Мое решение этой проблемы основано на моем предыдущем комментарии о разделении каждой области на два компонента, один для аутентификации и один для авторизации. Таким образом, в итоге вы получите более повторяющийся код, но он явно указывает на то, какое поведение вы ожидаете от своей реализации.

Вот'Как это сделать:

Создать новый класс "AuthenticatingCasRealm» это расширяет org.apache.shiro.realm.AuthenticatingRealm и реализует org.apache.shiro.util.Initializable.

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

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

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

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

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

Вот явное объявление Авторизатора и Аутентификатора через пользовательское расширение 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"));
    }
}

Ваш ответ на вопрос