ホームページ >バックエンド開発 >PHPチュートリアル >Apache Kiri ユーザーマニュアル (2) Shir 認定資格
Apache シロ ユーザーマニュアル (2) シロ認証
認証とは、ユーザーの身元を確認するプロセスです。認証プロセス中、ユーザーはエンティティ情報 (プリンシパル) と資格情報 (資格情報) を送信して、ユーザーが正当であるかどうかを確認する必要があります。最も一般的な「エンティティ/資格情報」の組み合わせは、「ユーザー名/パスワード」の組み合わせです。
1.Shiro 認証プロセス
1. エンティティ/資格情報を収集します
//Example using most common scenario of username/password pair: UsernamePasswordToken token = new UsernamePasswordToken(username, password); //”Remember Me” built-in: token.setRememberMe(true);
UsernamePasswordToken は、最も一般的なユーザー名/パスワード認証メカニズムをサポートします。同時に、RememberMeAuthenticationToken インターフェイスを実装しているため、トークンを介して「remember me」機能を設定できます。
ただし、「記憶されている」と「認証されている」には違いがあります:
記憶されているユーザーは非匿名ユーザーのみであり、subject.getPrincipals() を通じてユーザー情報を取得できます。ただし、完全に認証されたユーザーではないため、認証されたユーザーが必要な機能にアクセスする場合は、認証情報を再送信する必要があります。
この違いについては、Amazon の Web サイトを参照してください。Web サイトに再度アクセスすると、機密性の低いページ機能の場合、記憶されているユーザー情報がページに表示されます。 Web サイトのアカウント情報にアクセスする必要があるため、再度ログイン認証を行う必要があります。
2. エンティティ/資格情報を送信する
Subject currentUser = SecurityUtils.getSubject(); currentUser.login(token);
エンティティ/資格情報を収集した後、SecurityUtils ツール クラスを通じて現在のユーザーを取得し、login メソッドを呼び出して認証を送信できます。
3. 認証処理
try { currentUser.login(token); } catch ( UnknownAccountException uae ) { ... } catch ( IncorrectCredentialsException ice ) { ... } catch ( LockedAccountException lae ) { ... } catch ( ExcessiveAttemptsException eae ) { ... } ... catch your own ... } catch ( AuthenticationException ae ) { //unexpected error? }
例外情報をスローせずにログインメソッドが完了した場合、ユーザー認証は成功したとみなされます。その後、アプリケーション内の任意の場所で SecurityUtils.getSubject() を呼び出すと、現在認証されているユーザー インスタンスを取得できます。subject.isAuthenticated() を使用してユーザーが認証されているかどうかを判断すると、ログイン メソッドが例外をスローした場合、true が返されます。その場合、認証は失敗したものとみなされます。 Shiro には、コード例など、認証失敗の理由を説明するための個別の例外クラスが豊富に用意されています。
2. ログアウト操作
ログアウト操作では、以下のように subject.logout() を呼び出すことでログイン情報を削除できます。
currentUser.logout(); //removes all identifying information and invalidates their session too.ログアウト操作が完了すると、セッション情報はクリアされ、サブジェクトは匿名とみなされます。ユーザー。
3. 認証の内部処理機構
以上がアプリケーションにおけるShiro認証の処理過程です。以下、Shiro認証の内部処理機構について詳しく説明します。
1. アプリケーションは、エンドユーザー認証情報の AuthenticationToken インスタンスを構築した後、 Subject.login メソッド。
2. Sbuject のインスタンスは通常、DelegatingSubject クラス (またはサブクラス) のインスタンス オブジェクトであり、認証が開始されると、アプリケーションによって設定された securityManager インスタンスが securityManager.login(token) メソッドを呼び出すように委任されます。
3. トークン (トークン) 情報を受信した後、SecurityManager は組み込みの Authenticator のインスタンス (通常は ModularRealmAuthenticator クラスのインスタンス) を呼び出して、認証中に ModularRealmAuthenticator を 1 つ以上設定します。 Realm インスタンスが適応され、Shiro にプラグイン可能な認証メカニズムが実際に提供されます。
4. アプリケーションで複数のレルムが構成されている場合、ModularRealmAuthenticator は、構成された AuthenticationStrategy (認証戦略) に従ってマルチレルム認証プロセスを実行します。 Realm が呼び出された後、AuthenticationStrategy は各 Realm の結果に応答します。
注: アプリケーションで Realm が 1 つだけ構成されている場合、Realm は認証ポリシーを構成せずに直接呼び出されます。
5. 各レルムが送信されたトークンをサポートしているかどうかを確認します。サポートしている場合、レルムは getAuthenticationInfo(token) を呼び出します。これは、レルムの doGetAuthenticationInfo メソッドをオーバーライドすることによってカスタム認証処理を作成します。
4. 複数のレルムを使用する処理メカニズム:
1. Authenticator
デフォルトの実装は、単一のレルムと複数のレルムの両方をサポートします。レルムが 1 つだけ構成されている場合、ModularRealmAuthenticator はレルムを直接呼び出して認証情報を処理します。複数のレルムが構成されている場合は、認証ポリシーに従ってレルムを調整し、認証情報を実行する適切なレルムを見つけます。
認証システムの構成をカスタマイズする:
[main] ... authenticator = com.foo.bar.CustomAuthenticator securityManager.authenticator = $authenticator
2、AuthenticationStrategy(认证策略)
当应用程序配置了多个Realm时,ModularRealmAuthenticator将根据认证策略来判断认证成功或是失败。
例如,如果只有一个Realm验证成功,而其他Realm验证失败,那么这次认证是否成功呢?如果大多数的Realm验证成功了,认证是否就认为成功呢?或者,一个Realm验证成功后,是否还需要判断其他Realm的结果?认证策略就是根据应用程序的需要对这些问题作出决断。
认证策略是一个无状态的组件,在认证过程中会经过4次的调用:
在所有Realm被调用之前
在调用Realm的getAuthenticationInfo 方法之前
在调用Realm的getAuthenticationInfo 方法之后
在所有Realm被调用之后
认证策略的另外一项工作就是聚合所有Realm的结果信息封装至一个AuthenticationInfo实例中,并将此信息返回,以此作为Subject的身份信息。
Shiro有3中认证策略的具体实现:
AtLeastOneSuccessfulStrategy 只要有一个(或更多)的Realm验证成功,那么认证将被视为成功
FirstSuccessfulStrategy 第一个Realm验证成功,整体认证将被视为成功,且后续Realm将被忽略
AllSuccessfulStrategy 所有Realm成功,认证才视为成功
ModularRealmAuthenticator 内置的认证策略默认实现是AtLeastOneSuccessfulStrategy 方式,因为这种方式也是被广泛使用的一种认证策略。当然,你也可以通过配置文件定义你需要的策略,如:
[main] ... authcStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy securityManager.authenticator.authenticationStrategy = $authcStrategy ...
3、Realm的顺序
由刚才提到的认证策略,可以看到Realm在ModularRealmAuthenticator 里面的顺序对认证是有影响的。
ModularRealmAuthenticator 会读取配置在SecurityManager里的Realm。当执行认证是,它会遍历Realm集合,对所有支持提交的token的Realm调用getAuthenticationInfo 。
因此,如果Realm的顺序对你使用的认证策略结果有影响,那么你应该在配置文件中明确定义Realm的顺序,如:
blahRealm = com.company.blah.Realm ... fooRealm = com.company.foo.Realm ... barRealm = com.company.another.Realm securityManager.realms = $fooRealm, $barRealm, $blahRealm
以上就是Apache Shiro 使用手册(二)Shiro 认证的内容,更多相关内容请关注PHP中文网(www.php.cn)!