実践 権限管理の基本 (5) アクセスチーム

前回までの投稿でセキュリティロールやエンティティ単位をベースとした権限管理を説明した。

今回記載するアクセスチームはレコード単位での制御を行う機能である。レコード単位であるため、

「(例外的に)このレコードの情報だけは、通常アクセス権のないユーザーに権限を付与する」

というようなイメージで利用することが想定されていると思われる。

レコード単位で制御を行う機能としては、従来から「共有」という機能が存在している。

「共有」機能は共有の都度、誰に何の権限を付与するという下記のような設定を行う。

20141010_001

これはこれでいいのであるが、毎回この設定を行うのは面倒であったり、

誤った権限を付与してしまうというケースも考えられ、運用上容易に利用するにはハードルがあった。

これを補う形で2013 Fall ’13から登場したのがアクセスチームである。

というよりも、レコード単位の制御をするにはまず、アクセスチームを利用し、

これよりも複雑な制御を行いたい場合には「共有」を利用するというイメージの方が妥当と思われる。

従って、

機能:「共有」>「アクセスチーム」

ここのレコードでの制御操作のしやすさ:「アクセスチーム」>「共有」

まず先に利用検討する機能:「アクセスチーム」

というイメージで捉えてよいと思われる。

 

では、アクセスチームの設定方法に関して触れたいと思う。

これに関しては、中村さんのブログ(http://blogs.msdn.com/b/crmjapan/archive/2013/10/16/dynamics-crm-2013-fall-13-access-team.aspx)や自習書(http://technet.microsoft.com/ja-jp/cloud/crm_learning.aspx)が充実しているので割愛する。

改めて一通り、動作検証をしてみて気づいた点を記載しておく。

・そもそも全く読み込み権限のないエンティティを共有/アクセスチームしても読み込み権限は付与されない。

最低でもユーザーレベルの読み込み権限を対象エンティティに対して保有していないと

共有/アクセスチームを設定しても権限は付与されない。

※エラーや警告が表示されないので、気づかない可能性が高い。

・セキュリティロールで共有権限を保有しないとアクセスチームを利用できない。

利用できないとはアクセスチームのサブグリッドにユーザーが追加できない。

[+]のアイコンが表示されない。

20141010_002

このような権限を保有してアクセスチームサブグリッドにユーザーを追加しようとすると

以下のように[+]が表示されない。

20141010_003

以上。

これを以って、権限管理は終了とする。

Dynamics CRM 2015ではヒエラルキーという機能が追加され、また新たな制御が可能となる。

公開できるタイミングで早々に記載したいと思う。

広告

実践 権限管理の基本 (4) フィールドセキュリティ

前回までの投稿でセキュリティロールをベースとした権限管理を説明した。

権限設計を行う上では、セキュリティロールによる制御を第一に検討すべきであるということも記載した。

この上で、更なる制御を行う場合はその他標準機能を検討するべきであるとも記載した。

今回は、更なる制御の1つとしての標準機能である、フィールドセキュリティに関して記載する。

フィールドセキュリティとは、フィールドに対する制御を行う機能である。

セキュリティーロールがエンティティ単位での制御であるのに対して、

フィールドセキュリティはフィールド単位での制御を行うことができる。

フィールドセキュリティの有効有無はフィールドセキュリティプロファイルを用い、

ユーザーもしくはチーム単位で制御を行う。

また、大きな制限であるが、システムフィールド(デフォルトで存在するフィールド)には

適用できず、カスタムフィールドのみに適用ができる。

 

以下の要件を例にとり、設定を行ってみる。

「取引先企業の重要取引先フラグフィールドは営業担当者が更新せず、営業アシスタントが更新するものとする。

経理部派遣社員には閲覧制限を設けるものとする。」

設定の流れは以下のとおりである。

①フィールドでフィールドセキュリティを有効化する

②フィールドセキュリティプロファイルで権限を設定し、ユーザーまたはチームを追加する

③動作確認

 

①フィールドでフィールドセキュリティを有効化する

(フィールドを作成し、)以下のようにフィールドセキュリティのチェックをオンにする。

20141007_011

保存して公開する。

②フィールドセキュリティプロファイルで権限を設定し、ユーザーまたはチームを追加する

フィールドセキュリティは2つ作成する。

・値の閲覧はできるが作成/修正できないプロファイル

・値の閲覧及び作成/修正ができるプロファイル

[設定]>[フィールドセキュリティプロファイル]をクリック

20141007_002

[新規]をクリック

20141007_003

・値の閲覧はできるが作成/修正できないプロファイルの作成

[名前]を入力し、一度保存保存する。

20141007_012

[フィールドのアクセス許可]をクリック

フィールドセキュリティがオンになっているフィールドが一覧表示される。

20141007_013

[読み込み]:可、[更新]:不可、[作成]:不可とする。

レコードをダブルクリックし、上記に変更し保存。

20141007_006

ユーザーもしくはチームを追加する。

登場人物は以下のようにしている。

営業:crmuser1、営業1課部署(同チーム)

営業アシスタント:crmuser2、営業アシスタント部署(同チーム)

営業派遣社員:crmuser3、経理部部署(同チーム)

※セキュリティロールに関しては取引先企業に対してフル権限を付与。

20141007_015

※チームに関する画面は割愛

[チーム]から[営業1課]を追加する。

20141007_008

・値の閲覧及び作成/修正ができるプロファイル

同様にプロファイルを作成する。

20141007_016

営業アシスタントはフィールドに対してフル権限

20141007_017

[営業アシスタント]チームを追加

20141007_018

③動作確認

crmuser1でログインする。

取引先企業の新規フォーム。フィールドセキュリティ項目にはフィールドの先頭に鍵マークが表示される。

入力フィールド前に錠マークが表示されて入力できないが、値は確認できる。

20141007_019

既存データ。同じく錠マークが表示され、修正はできないが値は確認できる。

20141007_029

crmuser2でログインする。

取引先企業の新規フォーム。入力可能。

20141007_021

既存データ。閲覧、修正可能。

20141007_022

crmuser3でログインする。

取引先企業の新規フォーム。[*******]でマスクされ、閲覧/入力不可。

20141007_023

既存データ。同じく[*******]でマスクされ、閲覧/入力不可。

20141007_024

以上のような実装で要件を満たすことができる。

[*******]マスクはビューやExcelダウンロードでも行われる。

また、crmuser3は特殊な派遣社員であってある取引先企業のこの値を閲覧させるたい要望が発生した場合、

一般ユーザーにて権限付与を行うことができる。

既存レコードの[・・・]から[セキュリティで保護されたフィールドの共有]をクリック

20141007_025

「crmuser3」を追加し、[読み込み][更新]共に「あり」に変更する。

20141007_026

crmuser3でログイン。該当レコードを表示すると、制御が解除されていることが分かる。

20141007_027

別の既存レコードは従来同様、制御が機能している。

20141007_028

当然、この操作はcrmuser3自身が行うことはできない。

crmuser2など該当権限に対して「あり」という権限を保有しているユーザーのみが実施可能である。

セキュリティーロールで制御しているわけではないという点に注意が必要である。

以上。

本来はもう少し注意点や別の実装方法を記載しようと思ったが、

長くなってしまったので以下程度の軽い形にしておく。雑な記載のため理解困難かもしれない。

・システム管理者ロールを保有するユーザーには制限を加えられない。

自動的に[システム管理者]というプロファイルに追加されてしまうため。

・チームをプロファイルに追加するような設計に注意。

ユーザーの部署で設定した部署名と同名のチームから外れることはできないというのがチームの仕様である。

今回、crmuser3は経理部という別の部署としたが、当初のストーリーでは

営業1課部署に所属する派遣社員としたかった。しかしながら、

このようにすると必ず、営業1課チームに所属することとなってしまい、

crmuser1と同様になってしまうためストーリーを変更した(のだが。。事項に続く)

・複数チームに所属され複数のプロファイルを適用すると制御は加算され弱いほうが適用される

ストーリーを変更したのだが、よく考えたところ、以下のように実装できることが分かった。

1.「派遣」チームを作成し、crmuser3を所属

2.「派遣用」フィールドセキュリティを作成し、「派遣」チームを追加

3.フィールドに対する制御は営業と同様

crmuser3は[営業1課]と[派遣]チーム所属し、それぞれのプロファイルが適用される。

読み込み等制御はそれぞれの弱いほうが適用されるため、

営業と同様の権限制御が可能。

・安易に使いすぎるないほうがいい

複雑なクエリが実行されるであろうというのは容易に想像がつく。

また、そもそも要件自体が細かくなり勝ちであるため、テストが複雑化する。

どこかのタイミングで説明をしようと思うが、要件次第では複数フォームの利用を検討すべきである。

実践 権限管理の基本 (3) 権限レベルと部署/ユーザー

前回に引き続き、セキュリティロールである。

今回は権限レベルに関して記載する。

エンティティに対する権限レベルとしては以下の5つが存在する。

①[選択なし] 権限なし

②[ユーザー] 自分にだけ権限あり

③[部署] 同じ部署の範囲で権限あり

④[部署配下] 同じ部署及び配下の部署の範囲で権限あり

⑤[組織全体] すべてのデータに対して権限あり

横には簡易な説明を記載した。

これはあくまで簡易であり、ポイントは主語である。

主語は「レコードの所有者が」である。所有者が何であるかがポイントである。

※例えば、これを意識しないと[作成]の[ユーザー]権限の意味合いが捉え難いと思われる。

これはレコード初回保存時は自分が所有者であるレコードしか作成できないという意味である。

また、部署は「部署エンティティ」と「ユーザーエンティティ」の関係を意味している。

以下、実際の画面で説明する。なお、①と⑤は省略する。また確認は[読み込み]だけを行う。

まず、検証するためのデータ構造を説明する。

部署構造は以下のとおりである。

ルート部署の配下に[営業本部]-「営業1部]-[営業1課]と[営業2]が同列である構造を作成した。

20140926_001

次にユーザーであるが、[crmuser1]と[crmuser2]が同じ[営業1課]に所属するよう設定を行った。

20140926_002

検証するデータ前回作成したカスタムエンティティを利用する。

データは以下で作成している。3つのユーザーがそれぞれ1つずつ所有者となっている。

20140926_003

この状態で、crmuser1に以下のようにユーザー権限を付与する。

20140926_007

実際のレコードは以下のように表示される。

20140926_008

説明のとおり、自分が所有者であるレコードのみが表示される。

この状態からセキュリティロールを以下のように部署に変更する。

20140926_009

実際のレコードは以下のように表示される。

20140926_010

 

crmuser1とcrmuser2は同じ営業1課の部署に所属している。

権限を部署にすることによって同一部署のユーザーが所有者となっているレコードが表示された。

次はさらにこの状態から、crmuser1が上位の部署である、営業1部に変更となった場合を確認してみる。

※部署変更後はセキュリティーロールが外れるため、再度適用することに注意する必要がある

20140926_011

実際のレコードは以下のように表示される。

20140926_012

移動したことにより、同一部署のユーザーはcrmuser1のみになったためである。

次はさらにこの状態から、セキュリティロールを以下のように部署配下に変更する。

20140926_013

実際のレコードは以下のように表示される。

20140926_014

crmuser1が所属している営業1部の配下には営業1課が存在し、

営業1課のユーザーとしてcrmuser2が存在し、レコードを所有している。

配下のレコードが表示された。

次はさらにこの状態から、crmuser1がさらに上位の部署である、営業本部に変更となった場合を確認してみる。

20140926_015

実際のレコードは以下のように表示される。

20140926_016

部署の階層において配下であれば、直下でなくても権限は及ぶということが分かる。

以上。セキュリティロールに関して説明をした。

まずはこの仕様がベースである。

実際の案件では、この仕様でどこまで実現できて、どこが実現できないかを明確にしつつ、

その他の標準機能やPlugin開発にて制御を行うべきだと私は考える。

※余談ではあるが、本テストを行っている際に製品不具合とも考えられる現象を確認した。

原因が分かり次第、Tipsとして投稿を行う予定である。

実践 権限管理の基本 (2) アクションの制御

前回に引き続き、セキュリティロールである。

今回は言葉だけでなく実際の制御に関して記載する。

なお、今回は権限レベル(ユーザーや部署など)には触れず、

アクション(作成、読み込み)に関してのみ記載する。

また、権限を確認するために下記のカスタムエンティティを作成している。

・Lookupをもつエンティティ

・関連ビューを持つエンティティ

 

まず、すべての権限がない場合である。

これは想像のとおり、表示がされない。

20140923_001

画面ショットはないが、当然高度な検索の選択エンティティなどにも表示はされない。

次であるが、まずベースとなるのが[読み込み]である。

エンティティが表示されなければ(読み込まれなければ)、その他のアクションは成り立たない。

[読み込み]権限を付与すると下記のようにエンティティが表示される。

20140923_002

実際にエンティティをクリックすると下記のようになる。

20140923_003

[読み込み]権限を付与することでエンティティを表示することができた。

※画像の状態ではレコードが存在していなかった。存在していればレコードも表示される。

次にレコードを[作成]してみたいと思う。[新規]ボタンが表示されていないので、

権限が足りていないことが推測できる。

[作成]権限を付与してみる。付与後の画面は以下のとおりである。

20140923_004

[新規]ボタンが表示され、レコードの新規作成画面が起動する。

以下の画面は、レコードの新規作成画面が表示後、必須項目を入力し、保存した画面である。

20140923_005

保存するとすべてのフィールドに鍵マーク及び右下に[読み取り専用]と表示される。

これはエンティティに対する[書き込み]権限が付与されていないからである。

では次に[書き込み]権限を付与してみる。画面は以下のとおりである。

20140923_010

[名前]のテキストフィールドが変更可能となった。ただ、[Lookup]や[所有者]に関しては鍵マークのままである。

これは、後述する[追加][追加先]や[割り当て]の権限が付与されていないからである。

上記を解説する前に[削除]に関して触れておく。

ビュー上の[削除]ボタンに関しては[読み込み]権限を与えた時点で表示がなされている。

※権限がなければ表示されないのが基本なので、不具合とも言えるかもしれない。

削除権限を付与する前に[削除]をクリックしてみる。

20140923_006

20140923_007

20140923_008

[権限がありません]というダイアログが表示され、削除ができないことが分かる。

若干テーマからそれるが、上記のようなダイアログが発生し、原因調査をしたい場合は

[ログファイルのダウンロード]をクリックするとヒントが表示される。

内容は下記のようなテキストであるが、”privilege”が”missing”とあるんおで権限が不足というなことがなんとなく分かる。

20140923_009

話しを戻す。

次に分かりやすい、[割り当て][共有]を先に説明するである。

これは下記のようにボタンが表示されるものであると思えばよい。

20140923_013

最後に[追加][追加先]である。

結論から言うと、Lookupを持つエンティティで[追加]、関連ビューを持つエンティティで[追加先]

を選択していないと、Lookupフィールドの鍵マークが表示され、値の選択ができない。

単純に[書き込み]の権限だけを付与すると以下のとおり、[Lookup]フィールドは読み取り専用である。

20140923_010

以下のように権限を付与してみる。

20140923_011

すると、[Lookup]フィールドの鍵マークが表示されなくなり、選択が可能となる。

20140923_014

以上。

実践 権限管理の基本 (1) セキュリティーロール

新しいテーマである。

ここからは権限に関して記載する。

まずは、セキュリティロールである。

Dynamics CRMを利用するにはかならず、1つ以上のセキュリティロールが必要である。

権限管理を行う上でベースとなるものがセキュリティロールでの設定であり、

これでできないことを他の機能で補完していくのが基本的な考え方である。

セキュリティロールは下記のような画面で設定する。エンティティ単位の制御及び特権の管理を行う。

設定可能なすべての項目に対してチェックを行う方法で権限を付与する。

20140919_001

セキュリティロールは複数作成でき、ユーザー(及びチーム)に対して複数適用することができる。

複数適用した場合は範囲の広いほうが適用される([選択なし]と[ユーザー]では[ユーザー]が適用される)。

権限レベルの意味合いは下記である。

選択なし:権限なし

ユーザー:所有者が自分の場合可

部署:所有者が自分と同じ部署のユーザーの場合可

部署配下:所有者が自分の部署と同じかその配下の部署に所属している場合可

組織全体:すべて可

対象アクションに関しては下記である。

作成:レコードを作成する

読み取り:レコードを表示する

書き込み:変更が加わったレコード保存する

削除:レコードを削除する

追加:追加先とセットでLookupの制御をする。Lookupが表示されるエンティティに権限付与

追加先:追加とセットでLookupの制御をする。Lookupが表示されないエンティティに権限付与

割り当て:所有者を変更する

共有:レコードを共有する

追加、追加先以外はそれほど理解に苦しむものではないと思われる。

追加、追加先に関しては平易な表現にした。次回詳しく動作を確認する。

また、各タブの下部には[その他の特権]というものがある。

これは、単純に機能が使えるかというものの制御である。

例えば、[コアレコード]タブにある[一括削除]は、エンティティに関わらず、

一括表示のボタンを表示するかいなか(実行できるか否か)を制御している。

二択であるため、[選択なし]か[組織全体]のどちらかしか選択できない。

以上。次回は権限の選択と実際の制御を詳細に確認する。