Shiroの文字列ワイルドカードベースの権限式

Apache ShiroのPermissionsを深く理解する
自分の理解:
まず、realmのdoGetAuthorizationInfo()を使用して、返されるSimpleAuthorizationInfoで2つのロールと権限を設定することを知っておく必要があります.

@Override
    protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
        String username = (String)principals.getPrimaryPrincipal();

        SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo();
        authorizationInfo.setRoles(userService.findRoles(username));
        authorizationInfo.setStringPermissions(userService.findPermissions(username));

        return authorizationInfo;
    }

一部はロールroleで、一部は権限permissionです.これにより、リソースを制御するときにロール制御を単独で使用したり、権限制御を単独で使用したり、ロール+権限制御を単独で使用したりできます.たとえば、個別権限制御:

@RequiresPermissions("user:create")
@RequestMapping(value = "/create", method = RequestMethod.POST)
public String create(User user, RedirectAttributes redirectAttributes) {
    userService.createUser(user);
    redirectAttributes.addFlashAttribute("msg", "     ");
    return "redirect:/user";
}

個別のロール管理:

    User Page

Shiroのデフォルトでは、WildcardPermissionというクラスを使用してパーミッションマッチングを行います.このクラスの権限に対する式に制限があるのは、本稿で紹介する*【Apache ShiroのPermissionsを深く理解する】*、つまりこのクラスの権限式に対する制限、あるいはこのクラスを使用するには、以下のルールに従って権限文字列を設定する必要があります.
自分のまとめ:
WildcardPermissionは、権限は3つの部分から構成され、各部分は3つの部分をコロンで分割することができることを規定している.1つ目はドメインであり、2つ目は動作であり、3つ目は実行されるインスタンス(識別)user:query:2である.3つの部分は、userがuserクラスまたはテーブルまたはuserに対応するメニューであり、queryがクエリー権限であり、idが2のuserであることを理解すべきである.実際の開発では、user:*のような前の2つの部分ですべての権限を表すか、queryのように単一の権限だけを表すことができます.user:createは、userテーブルに対するcreate権限と理解できます.では、注釈を使用して、この権限をuserControllerのaddメソッドに追加するか、jsp追加ボタンのラベルに追加するか、userの追加urlブロッキングにアクセスすることができます.では、このメソッドにアクセスするか、ボタンラベルの表示を追加するか、userのurlの追加が成功するかどうかは、ユーザーがこの権限を持っているかどうかにかかっています.

@RequiresPermissions("user:create")
@RequestMapping(value = "/create", method = RequestMethod.POST)
public String create(User user, RedirectAttributes redirectAttributes) {
    userService.createUser(user);
    redirectAttributes.addFlashAttribute("msg", "  ");
    return "redirect:/user";
}

もちろん、独自の権限マッチングクラスを定義して使用することもできます.別のブログを参照してください.https://blog.csdn.net/lw_power/article/details/52562749 https://blog.csdn.net/lw_power/article/details/52562754

ワイルドカードの権限
≪単一権限｜Single Privileges｜ldap≫:文字列名を直接付けます.
例:queryPrinter権限-クエリー権限subject.isPermitted("queryPrinter")

1

ほぼ同等:subject.isPermitted( new WildcardPermission("queryPrinter") )

1

2つ目の方法は基本的に使わず、1つ目の方法でいいです.
≪複数の権限｜Multiple Privileges｜ldap≫:ワイルドカード権限は、複数のレベルまたは一部の概念をサポートします.
以下では、「権限文字列の次の部分を区切る特殊文字」を使用します.printer:query printer:print printer:manage

1

2

3

複数の権限を設定できます
複数の値で構成することもできます.printer:print,query

1

クエリー権限の検証:subject.isPermitted("printer:query")

1

単一リソースのすべての権限
例えば、私たちはこれらの権限を持っています.printer:query,print,manage

1

次のようになります.printer:*

1

2つ目の方法では、後でアプリケーションに新しい操作を追加した場合、このセクションでワイルドカードを使用する権限を更新する必要がないため、ワイルドカードを使用するのは、アクションを明示的にリストするよりも便利です.
すべてのリソースの権限
ワイルドカードトークンは、ワイルドカード権限文字列の任意の部分で使用することもできます.*:view

1

すべてのリソースのview権限、すなわちfoo:view(または他の:view)に対する任意の権限チェックはtrueを返します.
インスタンス・レベルの権限制御
ワイルドカード権限のもう1つの一般的な使用方法は、インスタンス・レベルのアクセス制御リストを作成することです.この権限では、3つのセクションを使用します.1つ目はドメイン、2つ目はアクション、3つ目は実行されるインスタンス(ID)です.
単一インスタンスの単一権限printer:query:lp7200 printer:print:epsoncolor

1

2

例えばprinterのquery権限、プリンタのidはlp 7200、つまりこのようなprinterのquery権限を持っています.
これらの権限をユーザーに付与すると、特定のインスタンスで特定の動作を実行できます.コードでチェックすることができます.if ( SecurityUtils.getSubject().isPermitted("printer:query:lp7200") { // Return the current jobs on printer lp7200 } }

1

2

3

すべてのインスタンスの単一の権限printer:print:*

1

すなわち、すべてのprinterのprint権限を有し、前の単一リソースの複数の権限に相当する
すべてのインスタンスのすべての権限printer:*:*

1

単一インスタンスのすべての権限printer:*:lp7200

1

単一インスタンスの複数の権限printer:query,print:lp7200

1

queryとprintの間には実際の開発でカンマで区切られており、インスタンスレベルの権限制御は基本的に使用されません.
権限割り当てに関する最後のことは、最後に失われた部分は、ユーザーがその部分に対応するすべての値にアクセスできることを意味します.言い換えれば、printer:print : printer:print:*

1

2

3

printer printer:*:*

1

2

3

でも注意!printer:lp7200 printer:*:lp7200 ！！！

1

2

3

4

これは末尾の*ではないので
アクセス権の確認
パーミッション割り当てはワイルドカードを使用してかなり構築されていますが(「printer:*」=任意のprinterに印刷されます)、実行時のパーミッションチェックは常に可能な最も特定のパーミッション文字列に基づいている必要があります.たとえば、ユーザーがlp 7200プリンタにドキュメントを印刷したいユーザーインタフェースがある場合は、ユーザーがこのコードを実行できるかどうかを確認する必要があります.if ( SecurityUtils.getSubject().isPermitted("printer:print:lp7200") ) { //print the document to the lp7200 printer } }

1

2

3

このチェックは非常に具体的であり,ユーザがその時点で何を試みているかを明確に反映している.ただし、次のコードは正しくありません.if ( SecurityUtils.getSubject().isPermitted("printer:print") ) { //print the document } }

1

2

3

2つ目の例では、「次のコードブロックを実行するために、任意のプリンタに印刷できる必要があります」と説明しています.ただし、「printer:print」は「printer:print:*」に等しいことを覚えておいてください.
そのため、これは不正確な検査です.現在のユーザーがプリンタに印刷する能力がない場合、lp 7200やepsoncolorプリンタなどの印刷能力があります.しかし、上記の2番目の例では、lp 7200プリンタに印刷することはできません.たとえ彼らがこのような能力を得たとしても.
したがって,経験則は,権限チェックを実行する際に最も特殊な権限文字列を用いる.もちろん、本当にコードブロックだけを実行したい場合、ユーザーがプリンタに印刷することを許可されている場合(可能)、2番目の方法はアプリケーションのもう1つの有効なチェックである可能性があります.アプリケーションは、どのチェックが意味があるかを決定しますが、一般的には、具体的であればあるほど良いです.
なぜランタイム権限チェックはできるだけ具体的にすべきですが、権限割り当てはもっと一般的にできますか?これは,権限チェックが平等チェックではなく暗黙論理によって計算されるためである.
すなわち、ユーザが「user:」に割り当てられた場合、これは、ユーザが「user:view」操作を実行できることを意味する.文字列"user:“明らかに”user:view”ではありませんが、前者は後者を暗示します.user:*は、「user:view」によって定義される機能のスーパーセットを記述する.
暗黙規則をサポートするために、すべての権限が実装orgに翻訳される.apache.shiro.authzのオブジェクトインスタンスの権限インタフェース.すなわち、暗黙論理は実行時に実行でき、暗黙論理は通常、単純な文字列等式検査よりも複雑である.このドキュメントで説明するワイルドカードの動作は、実際にはorg.apache.shiro.authz.permission.WildcardPermissionクラス実装
アクセスの意味を示すワイルドカード文字列を次に示します.user:*

1

ユーザーを削除できる機能を指します.user:delete

1

ただし:user:*:12345

1

すなわち、インスタンス12345を使用してユーザアカウントを更新することもできる.user:update:12345

1

printer ， : printer:print

1

2

3

承認プロセス
権限とは、権限があるかどうかを確認し、権限を与えることです.
認証手順:Step 1: Application or framework code invokes any of the Subject hasRole*, checkRole*, isPermitted*, or checkPermission* method variants, passing in whatever permission or role representation is required. Step 2: The Subject instance, typically a DelegatingSubject (or a subclass) delegates to the application’s SecurityManager by calling the securityManager’s nearly identical respective hasRole*, checkRole*, isPermitted*, or checkPermission* method variants (the securityManager implements the org.apache.shiro.authz.Authorizer interface, which defines all Subject-specific authorization methods). Step 3: The SecurityManager, being a basic ‘umbrella’ component, relays/delegates to its internal org.apache.shiro.authz.Authorizer instance by calling the authorizer’s respective hasRole*, checkRole*, isPermitted*, or checkPermission* method. The authorizer instance is by default a ModularRealmAuthorizer instance, which supports coordinating one or more Realm instances during any authorization operation. Step 4: Each configured Realm is checked to see if it implements the same Authorizer interface. If so, the Realm’s own respective hasRole*, checkRole*, isPermitted*, or checkPermission* method is called.

1

2

3

4

5

6

7

興味のある人は公式サイトに行ってみてください.http://shiro.apache.org/authorization.html