Apache Kiri ユーザーマニュアル (3) Shir 認可

認可はアクセス制御であり、ユーザーがアプリケーション内のリソースへの対応するアクセス権を持っているかどうかを決定します。

たとえば、ユーザーがページを表示する権限、データを編集する権限、特定のボタンを持つ権限、印刷する権限などを持っているかどうかを判断します。

1. 認可の 3 つの要素

認可には、権限、ロール、ユーザーという 3 つの主要な要素があります。

アクセス許可

アクセス許可は、Apache Tora セキュリティ メカニズムの中核要素です。アプリケーションで許可される動作とパフォーマンスを明確に示します。適切にフォーマットされた権限ステートメントは、ユーザーがリソースに対して持つ権限を明確に伝えます。

ほとんどのリソースは一般的な CRUD 操作 (作成、読み取り、更新、削除) をサポートしますが、どの操作も特定のリソースに基づくことが理にかなっています。したがって、許可宣言の基本的な考え方はリソースと操作に基づいています。

そして、許可の宣言を通じて、この許可がアプリケーションで何ができるかを理解することしかできませんが、誰がこの許可を持っているかを判断することはできません。

そのため、アプリケーションでユーザーと権限を関連付ける必要があります。

通常のアプローチは、ロールに権限を割り当て、このロールを 1 人以上のユーザーに関連付けることです。

パーミッション宣言と粒度

Shiroパーミッション宣言は通常、コロンで区切られた式を使用します。前述したように、アクセス許可式では、リソース タイプ、許可される操作、およびアクセス可能なデータを明確に指定できます。同時に、Shiro 権限表現は単純なワイルドカードをサポートしており、より柔軟な権限設定が可能です。

以下では、例を使用して許可の式を説明します。

ユーザーデータのクエリが可能

User:view

ユーザーデータのクエリまたは編集が可能

User:view,edit

ユーザーデータに対するすべての操作の実行が可能

User:* またはユーザー

は 123 の ID を編集可能ユーザーデータ

User:edit:123

ロール

Shiro は 2 つのロール モードをサポートしています:

1. 従来のロール: ロールは、操作の承認検証が必要な場合に、それが承認されているかどうかを判断するだけです。役割。この種のロール権限は比較的単純かつ曖昧であるため、拡張にはつながりません。

2. 権限ロール: ロールには一連の権限があります。権限の検証中に、現在のロールに権限があるかどうかを判断する必要があります。この種類のロール権限は、ロールの詳細な権限の説明を提供することができ、より複雑な権限の設計に適しています。

2 つの役割モードの認可の実装については、以下で詳しく説明します。

2. 認可実装

Shiro は認可プロセスを実装する 3 つの方法をサポートしています:

コーディング実装
アノテーション実装
JSP Taglig 実装

1. コーディングに基づく認可実装

1.1 従来のロールに基づく認可実装

検証が必要です ユーザーが特定のロールを持っている場合、Subject インスタンスの hasRole* メソッドを呼び出して検証できます。

Subject currentUser = SecurityUtils.getSubject(); 

if (currentUser.hasRole("administrator")) { 

//show the admin button 

} else { 

//don't show the button? Grey it out? 

}

関連する検証方法は以下のとおりです:

対象方法gt; リスト配列の順序で対応するブール値を返します

;

hasAllRoles(Collection roleNames) ユーザーが指定されたすべてのロールを持っている場合は true を返します

アサーションのサポート

Shiro はアサーションの形式での承認検証もサポートしています。アサーションが成功した場合、値は返されず、プログラムは実行を続行します。アサーションが失敗した場合、例外メッセージがスローされます。アサーションを使用すると、コードをより簡潔にすることができます。

Subject currentUser = SecurityUtils.getSubject(); 

//guarantee that the current user is a bank teller and 

//therefore allowed to open the account: 

currentUser.checkRole("bankTeller"); 

openBankAccount();

の 関連メソッド:

Subject メソッド 説明

Checkrole (String Roleneame) ユーザーが指定した文字を持っているかどうかをアサートします

Checkroles (Collection & LT; ROLENAMES) kroles (string .. . roleNames) 前のメソッドのメソッドのオーバーロード

1.2 権限ベースのロール認可の実装

従来のロールモデルと比較して、権限ベースのロールモデルは結合度が低く、ロールの変更によってソースコードが変更されることはありません。アクセスを制御するためのより良い方法。

そのコード実装には次の実装メソッドがあります:

1. 権限オブジェクトに基づく実装

org.apache.hiro.authz.Permission のインスタンスを作成し、そのインスタンス オブジェクトを認証用のパラメータとして Subject.isPermitted() に渡します。 。

Permission printPermission = new PrinterPermission("laserjet4400n", "print"); 

Subject currentUser = SecurityUtils.getSubject(); 

if (currentUser.isPermitted(printPermission)) { 

//show the Print button 

} else { 

//don't show the button? Grey it out? 

} 

Permission printPermission = new PrinterPermission("laserjet4400n", "print"); 

Subject currentUser = SecurityUtils.getSubject(); 

if (currentUser.isPermitted(printPermission)) { 

//show the Print button 

} else { 

//don't show the button? Grey it out? 

}

該当するメソッドは以下の通りです:



Subjectメソッド 説明

isPermitted(Permission p) Subjectが指定された権限を持っている場合、treuを返します

isPermitted(List perms)    返回对应权限的boolean数组    

isPermittedAll(Collection perms)    Subject拥有所有制定权限时，返回true    

2、 基于字符串的实现 

相比笨重的基于对象的实现方式，基于字符串的实现便显得更加简洁。 

Subject currentUser = SecurityUtils.getSubject(); 

if (currentUser.isPermitted("printer:print:laserjet4400n")) { 

//show the Print button 

} else { 

//don't show the button? Grey it out? 

}

使用冒号分隔的权限表达式是org.apache.shiro.authz.permission.WildcardPermission 默认支持的实现方式。 

这里分别代表了 资源类型：操作：资源ID 

类似基于对象的实现相关方法，基于字符串的实现相关方法： 

isPermitted(String perm)、isPermitted(String... perms)、isPermittedAll(String... perms) 

基于权限对象的断言实现 

Subject currentUser = SecurityUtils.getSubject(); 

//guarantee that the current user is permitted 

//to open a bank account: 

Permission p = new AccountPermission("open"); 

currentUser.checkPermission(p); 

openBankAccount();

基于字符串的断言实现 

Subject currentUser = SecurityUtils.getSubject(); 

//guarantee that the current user is permitted 

//to open a bank account: 

currentUser.checkPermission("account:open"); 

openBankAccount();

断言实现的相关方法 

Subject方法    说明    

checkPermission(Permission p)    断言用户是否拥有制定权限    

checkPermission(String perm)    断言用户是否拥有制定权限    

checkPermissions(Collection perms)    断言用户是否拥有所有指定权限    

checkPermissions(String... perms)    断言用户是否拥有所有指定权限

   

2、基于注解的授权实现 

Shiro注解支持AspectJ、Spring、Google-Guice等，可根据应用进行不同的配置。 

相关的注解： 

@ RequiresAuthentication 

可以用户类/属性/方法，用于表明当前用户需是经过认证的用户。 

@RequiresAuthentication 

public void updateAccount(Account userAccount) { 

//this method will only be invoked by a 

//Subject that is guaranteed authenticated 

... 

} 

@ RequiresGuest

表明该用户需为”guest”用户 

@ RequiresPermissions 

当前用户需拥有制定权限 

@RequiresPermissions("account:create") 

public void createAccount(Account account) { 

//this method will only be invoked by a Subject 

//that is permitted to create an account 

... 

} 

@RequiresRoles

当前用户需拥有制定角色 

@ RequiresUser 

当前用户需为已认证用户或已记住用户 

3、基于JSP TAG的授权实现 

Shiro提供了一套JSP标签库来实现页面级的授权控制。 

在使用Shiro标签库前，首先需要在JSP引入shiro标签： 

<%@ taglib prefix="shiro" uri="http://shiro.apache.org/tags" %>

下面一一介绍Shiro的标签： 

guest标签 

验证当前用户是否为“访客”，即未认证（包含未记住）的用户 

<shiro:guest> 

Hi there! Please <a href="login.jsp">Login</a> or <a href="signup.jsp">Signup</a> today! 

</shiro:guest>

user标签 

认证通过或已记住的用户 

<shiro:user> 

Welcome back John! Not John? Click <a href="login.jsp">here<a> to login. 

</shiro:user>

authenticated标签 

已认证通过的用户。不包含已记住的用户，这是与user标签的区别所在。 

<shiro:authenticated> 

<a href="updateAccount.jsp">Update your contact information</a>. 

</shiro:authenticated> 

notAuthenticated标签

未认证通过用户，与authenticated标签相对应。与guest标签的区别是，该标签包含已记住用户。 

<shiro:notAuthenticated> 

Please <a href="login.jsp">login</a> in order to update your credit card information. 

</shiro:notAuthenticated>

principal 标签 

输出当前用户信息，通常为登录帐号信息 

Hello, <shiro:principal/>, how are you today?

验证当前用户是否属于该角色 

<shiro:hasRole name="administrator"> 

<a href="admin.jsp">Administer the system</a> 

</shiro:hasRole>

lacksRole标签 

与hasRole标签逻辑相反，当用户不属于该角色时验证通过 

<shiro:lacksRole name="administrator"> 

Sorry, you are not allowed to administer the system. 

</shiro:lacksRole>

hasAnyRole标签 

验证当前用户是否属于以下任意一个角色。 

<shiro:hasAnyRoles name="developer, project manager, administrator"> 

You are either a developer, project manager, or administrator. 

</shiro:lacksRole>

hasPermission标签 

验证当前用户是否拥有制定权限 

<shiro:hasPermission name="user:create"> 

<a href="createUser.jsp">Create a new User</a> 

</shiro:hasPermission>

lacksPermission标签 

与hasPermission标签逻辑相反，当前用户没有制定权限时，验证通过 

<shiro:hasPermission name="user:create"> 

<a href="createUser.jsp">Create a new User</a> 

</shiro:hasPermission>

三、Shiro授权的内部处理机制 

1、在应用程序中调用授权验证方法(Subject的isPermitted*或hasRole*等) 

2、Sbuject的实例通常是DelegatingSubject类（或子类）的实例对象，在认证开始时，会委托应用程序设置的securityManager实例调用相应的isPermitted*或hasRole*方法。 

3、接下来SecurityManager会委托内置的Authorizer的实例（默认是ModularRealmAuthorizer 类的实例，类似认证实例，它同样支持一个或多个Realm实例认证）调用相应的授权方法。 

4、每一个Realm将检查是否实现了相同的 Authorizer 接口。然后，将调用Reaml自己的相应的授权验证方法。 

当使用多个Realm时，不同于认证策略处理方式，授权处理过程中： 

1、当调用Realm出现异常时，将立即抛出异常，结束授权验证。 

2、只要有一个Realm验证成功，那么将认为授权成功，立即返回，结束认证。

以上就是Apache Shiro 使用手册（三）Shiro 授权的内容，更多相关内容请关注PHP中文网（www.php.cn）！