ゼロからの Aras Innovator 第4回 〜 アクセス権制御:業務システムの必須要素 〜

Arasフレームワークの主な構成要素をご紹介しているシリーズの3回目です。 前回・前々回は、その中でも根幹中の根幹となる「アイテムタイプ」と「リレーションシップ」についてご紹介しました。 3回目となる今回は、部門横断の業務システムで特にきちんとした対応を求められる「アクセス権制御」について、Aras Innovatorでの管理方式をご紹介したいと思います。


「ログインアカウント」と「役割」

他の多くのシステムと同様、Aras Innovator も「ログインアカウント」と「役割」を概念的に分けて設定していきます。前者を 「User(ユーザ)」 、後者を 「Identity(アイデンティティ)」 と呼びます。

概念 Aras での呼称 責務
ログインアカウント User (ユーザ) ログイン認証を制御。システムの門番
役割 Identity (アイデンティティ) 各機能やアイテムに対する利用可否を制御。機能/アイテムの門番

「User」 にはパスワードが設定され、ログイン時にパスワードを入力することにより、「ログインしようとしている人=想定される利用者」という認証が為されます。 (脚注*1)

ログインに成功した利用者には、システム上の役割として 「Identity」 が割り当てられます。Identity は階層構造を持つことができ、上位 Identity から下位 Identity へ権限が継承されます。Identity の階層構造は、会社内の組織階層を下地に組み上げていくのが一般的です。

 

また、Identity には、特定の部署を表すような固有名詞的な Identity に加えて、アクセスしようとしているアイテムの属性に応じて対象者が変わる代名詞的な Identity も存在します。

 

例えば、「文書」アイテムタイプに対して、代名詞的 Identity の「Creator」を指定して参照権限を与えた場合、

  • 文書A(作成者 田中さん) ・・・ 田中さんのみ参照可能、鈴木さんは参照不可
  • 文書B(作成者 鈴木さん) ・・・ 鈴木さんのみ参照可能、田中さんは参照不可

といったアクセス制御が行われます。


「権限」

では、Identity に対して どのような「権限」を付与することができるのでしょうか? Aras 上で Identity に付与される「権限」は、大きく3つに分類可能です。 (脚注*2)

  • (1) メニュー表示権限(TOCアクセス)
  • (2) 新規登録権限
  • (3) 登録されたアイテムの参照・操作権限

 

この中で (3) のみ、既に登録されたアイテムに対して参照したり編集したりする権限である点にご注意ください。また、既に登録されたアイテムは何らかの状態=ライフサイクルステート(準備中、レビュー中、リリース済み、など)を持っていますので、(3) はそのステートに応じて設定を切り替えることも可能です。

この (3) の設定を、Aras Innovator では 「Permission(パーミッション)」 と呼んでいます。


「Permission(パーミッション)」

「Permission」 として設定可能な項目には、

  • (a) ディスカバ―権限: 対象アイテムを検索結果一覧へ表示できるか否か
  • (b) 参照権限: 対象アイテムを個別フォーム(画面)で表示できるか否か
  • (c) 編集権限: 対象アイテムの編集可否
  • (d) 削除権限: 対象アイテムの削除可否
  • (e) アクセス権の変更権限: 対象アイテムの Permission の切り替え可否

などがあります。

参照権限をプロパティ単位で設定することはできませんが、表示プロパティの範囲を (a) と (b) の2段階で設定できますし、(b) で開くフォーム(画面)を Identity に応じて切り替えることが可能ですので、フォームを個別に用意することで、このプロパティを誰に見せて誰に見せないといった制御が可能です。

Permission は、アイテムタイプ単位でのデフォルト設定のほか、ライフサイクルステートに応じた設定も行えます。

また、「文書X は厳秘扱いで、人事部長と私にしか参照できないようにしよう」というような、個々のアイテム単位の Permission も存在します。これを「プライベートパーミッション」と呼んでおり、プライベートパーミッションの作成を許すかどうかを アイテムタイプに対して設定することができます。 (なお、プライベートパーミッションを設定できるのは、(e) の権限が付与された人だけです)

「Identity の階層構造」や「代名詞的な Identity」をうまく利用して Permission 設定することで、

  • 文書種別が「労務関連」の文書アイテムは、人事部門と対象部署の所属長のみ参照可能
  • 準備中のパーツは設計部門のみ参照可能。他部門からはリリース済みパーツしか参照できない
  • 製品開発情報は、各製品の開発担当チームメンバーのみ参照可能。その内、見積情報に関しては チーム見積担当のみ編集可能
  • 田中さんは 営業と技術の兼務なので、両方の情報にアクセスできる

などのアクセス制御が実現可能です。 工夫次第で大抵の要件を充足させることができますので、色々工夫してみてください。

※ 次回は、今回もチラッと出てきたライフサイクルやワークフローについてご紹介したいと思います。 それでは、また次回。


(脚注*1) 認証オプション: パスワードの長さや再利用可否などのパスワードポリシー、パスワード間違いによるロックアウト方針などを認証時のオプションとして設定可能です。また、ActiveDirectoryと連携したシングルサインオンも実現可能です(こちらはサブスクライバ限定機能)。

(脚注*2) その他の権限: (1)~(3)の権限設定のほかに、

  • アイテムのライフサイクルステートの変更権限
  • ワークフローのVote権限(承認、否認など)

などもありますが、追々ご紹介できるかと思いますので、ここでは説明を割愛します。


(アラスジャパン 宮内一也)