サポート > リポジトリ > 認証・認可 > 権限管理の概要

Wagbyの権限管理は「パーミッション」と「プリンシパル」という概念を用います。

ロールベースの権限管理では「利用者」と「データ」を直接、結びつけません。その間に「権限」という概念を導入します。

Wagbyはロールベースの権限管理機能を提供します。

図1 ロールを用いない場合
図2 ロールを用いる場合 (Wagby)

権限の基本単位を「パーミッション」と呼びます。
たとえば「顧客モデルの表示パーミッション」や「社員モデルの更新パーミッション」などがあります。

各画面には「自分を処理するためには、このモデルについてのXXX権限が必要である」というチェック機能が備わっています。 「XXX」の部分はそれぞれ、「登録」「更新」「削除」「表示」「検索」といった基本的な権限が入ります。

複数のパーミッションをグループ化したものを「プリンシパル」と呼びます。たとえば、「登録」「更新」パーミッションをグループ化して「更新系プリンシパル」を用意することもできます。Wagbyの標準は「複数パーミッション = 1プリンシパル」となっています。

図3 パーミッションとプリンシパルの関係
管理者は、利用者(アカウント)に対して「プリンシパル」を割り当てることができます。 この操作は運用中に行えるため、ある利用者に対して一時的に操作権限を付与したり、削除したりといった柔軟な対応を実現できます。

Wagbyは標準で次のプリンシパルを用意しています。

種類 内容
共通処理 プレファレンス(配色や、各パーツの表示制御)を指定することができます。
パスワード変更 パスワードの変更を行うことができます。
システム管理者 すべての権限をもちます。標準で用意されているアカウント "admin" に割り当てられています。
一般ユーザ 閲覧・検索・更新・登録・削除・ダウンロード・アップロード・メニュー・一覧更新・帳票出力
「メニュー」とは、メニューに表示される権限という意味です。
グループ管理者 各グループには、グループ内のデータに対して特別な権限を持つ「グループ管理者」を用意することができます。
グループ管理者(代理登録不可) グループ管理者の権限でデータを操作できますが、代理登録を行うことはできません。
休日設定更新者 システムが管理する「休日」を追加することができます。
アカウント閲覧者 自分以外のアカウント情報を閲覧することができます。グループ権限設定での代理登録機能や、ワークフローの代理承認で用います。
フロー状態閲覧 ワークフローで、承認すべきワークフローを確認することや、申請したワークフローの状態を確認するための権限です。
ワークフロー代理者設定 ワークフローの代理承認で用います。
メールテンプレート管理者 メールテンプレート」の登録、更新操作を行うことができます。
帳票定義管理者 帳票テンプレート」の登録、更新操作を行うことができます。
お知らせ管理者 「お知らせ」の登録、更新操作を行うことができます。
ジョブ管理者 Wagbyが提供する「ジョブマスタ」の登録、更新操作を行うことができます。
ジョブスケジュール管理者 Wagbyが提供する「ジョブ」の実行ルールを定義できます。指定した時間にジョブが起動します。
バッチジョブ管理 Spring Batch を用いたバッチ処理で、各バッチジョブの状態を操作するための権限です。初期設定では、更新機能を無効としているため、本権限を設定しても利用できません。(バッチジョブは原則として閲覧のみが許可されるようになっています。)
バッチジョブ閲覧 Spring Batch を用いたバッチ処理で、各バッチジョブの状態(インスタンス、実行結果、ステップ)を閲覧できます。
ワークフロー管理者 フローパターンフロー参加者設定ワークフロー設定を行うための権限です。
マスタ更新者 選択肢モデル」の操作を行う権限です。
ジョブ専用アカウント ジョブを実行することができる特別な権限です。
接続解除 ログオン済みの利用者を強制的に解除することだけが行える権限です。この権限を有したアカウントは、接続解除以外の操作は一切、制限されます。

Wagbyのログオンアカウントは juser モデルとして定義されています。 ログオンアカウントの設定時に、どのプリンシパルを割り当てるかを指定することができます。

図4 ログオンアカウント登録画面におけるプリンシパル設定欄

画面単位ではなく、モデル項目単位に「パーミッション」を設定することができます。
これにより、次のような複雑な設定も行うことができます。

参照権限 - 権限を有していないユーザに対して、項目を隠す
「営業日報」モデルに「上司のコメント」項目を用意した。この項目は管理者が閲覧・更新することができるが、営業スタッフはこの項目は見えない。すなわち、この項目が存在することさえも知らない。
更新権限 - 権限を有していないユーザに対して、項目を読み込み専用にする
「販売」モデルに「注文数量」項目を用意した。この項目は「注文数量更新権限」をもっている利用者は閲覧・更新することができるが、同権限をもっていない場合、閲覧はできるが更新を行うことができない。

機能

権限設定は「画面」「帳票」「CSV・Excelダウンロード/アップロード更新」に適用されます。

アカウント

一般利用者が対象範囲となります。システム管理者 (admin) は、すべての権限が有効になります。

権限管理の動作テストでは、システム管理者を用いないようにしてください。

「システム管理者」プリンシパルは、次のように動作します。

1. これは、あるユーザーが表示できる画面をシステム管理者が表示できないという動作は許可しない、ことを意味します。一方で、システム管理者を含む、どのようなプリンシパルも与えられていない権限定義は可能です。この場合は誰も操作できない機能、となります。

このあとのマニュアルで、プリンシパルを追加する方法が説明されます。追加されたプリンシパルは、データベースに用意された "jprincipal" というテーブルに格納されます。このモデルは通常、外部から操作することはできませんが、テーブル情報としては存在しています。アカウント情報 (juser) のインポート・エクスポート時には、jprincipal も操作されます。

jprincipalの主キー(プリンシパルID)はビルドのタイミングで自動採番されます。("プリンシパル名(英語)" のソート順になります。)

外部データベース利用時は、ビルド後に import_db.bat を実行することで、追加したプリンシパルがアプリケーションに反映されます。この詳細は「サポート > データベース活用ガイド(R7) > テーブルの作成」の「二回目以降」の手順をお読みください。

内蔵データベース(HSQLDB)利用時は、この手順は自動的に行われます。

詳細な仕組み

ログオンアカウントにプリンシパルを割り当てる」にあるように、アカウントには複数のプリンシパルを紐づけることができます。内部ではjuserは、複数のプリンシパルIDを保持します。

図5 juser と jprincipal の関係

このように juser は jprincipal の ID 値を参照する仕組みですが、新たに jprincipal が追加された場合、juser がもっている ID 値に変更がないにもかかわらず、jprincipal の ID 値が降り直されるため、「ずれ」が生じます。

プリンシパルの追加・削除に伴いプリンシパルIDが変わった場合でも、通常のアプリケーション入れ替えルール(エクスポートとインポート処理)を行うことで、整合性が維持されるようになっています。

  1. ビルドのアプリケーションで、データをエクスポートしておきます。
  2. ビルドのアプリケーションで、データをインポートします。インポート時に、インポート対象データのプリンシパル情報と、(ビルド後の)アプリケーションのプリンシパル情報を比較して、インポート対象データのアカウント(juser)のプリンシパルIDを自動的に変換します。

最小限の操作

この仕組みから、プリンシパルの追加・削除時は、アカウントモデル(juser)のインポートを行うことで反映されます。具体的には次の操作になります。

  1. ビルド前のアプリケーションでアカウントモデル(juser)をエクスポートしておく。
  2. ビルド及びアプリケーションの入れ替えを行う。
  3. 新しいアプリケーションで 1. のアカウントモデル(juser)をインポートする。

3. のタイミングで、追加されたプリンシパルが自動的に反映されます。

R7.8.2よりも前のバージョンでは、3. のあと、Wagbyアプリケーションを再起動してください。(R7.8.2 以降のバージョンでは、再起動は不要です。