обычаем Shiro царства - кто делает фактическую аутентификацию

Question

когда юг причислять Сиро AuthorizingRealm (или только AuthenticationRealm) путем переопределения

protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { 
} 

это моя работа, чтобы проверить, что учетные данные, представленные в AuthenticationToken фактически совпадают?

Или я должен вернуть AuthenticationInfo с principals разрешенного от AuthenticationToken и правильного пароля для данных учетных данных и Shiro будет сравнить их самостоятельно где-то в потоке Subject.login (AuthenticationToken) называют?

Answer 1

Внутри doGetAuthenticationInfo (...) вам нужно убедиться, что пользователь предоставил вам подтверждение подлинности.

Вот псевдо-кодированный пример того, что вы могли бы сделать:

protected AuthenticationInfo doGetAutheticationInfo(AuthenticationToken token) { 
    if(token instanceof UsernamePasswordToken) { 
    String username = token.getUsername(); 
    // Look up the user by the provide username 
    UserRecord userRecord = lookupUserRecord(username); 
    // No record found - don't know who this is 
    if (userRecord == null) { 
     throw new UnknownAccountException(); 
    } 
    // Check for other things, like a locked account, expired password, etc. 

    // Verify the user 
    SimpleAuthenticationInfo sai = new SimpleAuthenticationInfo(userRecord.getPrincipal(), userRecord.getHashedCredentials(), userRecord.getCredentialsSalt(), getName()); 
    boolean successfulAuthentication = getCredentialsMatcher().doCredentialsMatch(token, sai); 

    if(successfulAuthentication) { 
     // Check for anything else that might prevent login (expired password, locked account, etc 
     if (other problems) { 
      throw new CredentialsException(); // Or something more specific 
     } 
     // Success! 
     return sai; 
    } else { 
     // Bad password 
     throw new IncorrectCredentialsException(); 
    } 
    } 
    // Don't know what to do with this token 
    throw new CredentialsException(); 
} 

Вы должны написать lookupUserRecord (имя пользователя) или что-то подобное, чтобы перейти поиск информации о пользователе, включая его хешированное и соленые полномочия.

Answer 2

Javadocs для AuthenticatingRealm.doGetAuthenticationInfo() состояния (курсив мой):

извлекает данные аутентификации из источника данных конкретной реализации (RDBMS, LDAP, и т.д.) для данного маркера аутентификации.

Для большинства источников данных это означает просто «вытягивание» данных аутентификации для связанного субъекта/пользователя и ничего более, и позволить Сиро сделать все остальное. Но в некоторых системах этот метод может фактически выполнять специфическую логику входа EIS в дополнение к простому извлечению данных - это зависит от реализации Realm.

Метод AuthenticatingRealm.getAuthenticationInfo() первые вызовы doGetAuthenticationInfo() затем последовательно называет assertCredentialsMatch() с помощью сконфигурированной credentialsMatcher:

Так в зависимости от того, насколько типична ваша реализация Realm, вы можете захотеть, чтобы избежать проверки учетных данных AuthenticationToken «с в doGetAuthenticationInfo(), потому что метод шаблона getAuthenticationInfo() уже содержит шаг для обеспечения соответствия представленных учетных данных.

конкретно на Ваш вопрос, если это ваша ответственность «чтобы проверить, что учетные данные, представленные в AuthenticationToken фактически совпадают», ответ да, но не в doGetAuthenticationInfo() методы. Обычно вы выполняете сравнение учетных данных в рамках реализации интерфейса CredentialsMatcher, как описано here.

Answer 3

doGetAuthenticationInfo - это основной метод, в котором выполняется аутентификация. SO, если вы переопределяете его, как правило, вы являетесь основным процессом аутентификации. Если вы хотите использовать процесс, который был определен для этого reealm и сделать некоторые дополнительные вещи, лучше сначала вызовите метод супер класса, затем получите его информацию, а затем используйте его, чтобы вам не пришлось ничего менять. Также в случае jdbcrealm sqls в shiro.ini автоматически отображаются.и они не будут изменены до тех пор, пока вы не переопределите setAuthenticationQuery, setUserRolesQuery и т. д.

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

AuthenticationInfo info = super.doGetAuthenticationInfo(token); 

Обратите внимание, что супер является ссылкой на родителя, но super() является его конструктором.

как:

public class CustomJdbcRealm extends JdbcRealm 
{ 
    @Override 
    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException 
    { 

     AuthenticationInfo info = super.doGetAuthenticationInfo(token); 
     // Your own code here 
    } 
}