Omniの権限周りで挙動を確認したい点を検証してみた
さがらです。
Omniの権限周りは基本的に、Modelごとにグループやユーザーの粒度でAccess permissionを付与することで行う仕様となっております。詳細な権限の違いは以下の公式Docに記載があります。
一方で、この公式Docを見ただけでは動作が完全にイメージできない箇所がいくつかありました。そのため、権限周りで挙動が気になった箇所を実際に試してみたので、その内容を本記事でまとめてみます。
事前準備：検証に用いるグループとユーザーについて
下図のように、検証用のグループを作成して、Creator相樂というユーザーだけをこのグループに割り当てます。
このグループに対して各種権限を割り当てて、動作検証を行っていきます。
Creator相樂のユーザーで動作検証する際は、Impersonate user機能を使用します。下記はこの機能を検証した際のブログです。
Workbooks：Restricted querierは、Topic経由でしかクエリを発行できないのか？
公式Docを見ると、Restricted querierは、Topic経由でしかクエリを発行できないように見えます。
Topicを整備しているConnectionで下図のように権限を設定し、動作検証してみます。
動作検証
Restricted querierを付与したユーザーで対象のModelを用いたExploreを立ち上げると、Topicしか選択できませんでした。つまりRestricted querierは、Topic経由でしかクエリを発行できないということがわかりました。
ダッシュボード：Restricted querierはTopicを使用していないチャートを閲覧できるか？
公式Docを見ると、Restricted querierは、Topic経由のチャートしか閲覧できないように見えます。
Topicを整備しているConnectionで下図のようにRestricted querierの権限を設定します。
この上で下図のように、Viewを直接参照するチャートと、Topicを参照して作成したチャートの2つを用意して、動作検証します。
動作検証
Restricted querierを付与したユーザーで用意したダッシュボードを閲覧すると、View使用のチャートが閲覧できませんでした。つまりRestricted querierは、Topic経由で作られたチャートしか閲覧できないということがわかりました。
ちなみに、ダッシュボード作成時点でも、Viewを使用したチャートがあると下図のように警告が出ていました。ダッシュボード作成時は、基本的にTopicでチャートを作ることを必須にすることを強く推奨します。
ダッシュボード：No accessの権限でもダッシュボードが見れてしまうのか？
公式Docを見ると、No accessでもAccess dashboardsにチェックがついており、No accessでもダッシュボードが見えるように見えてしまいます。
ダッシュボードを作成しているConnectionで下図のようにNo accessの権限を設定して、動作検証してみます。
また、ダッシュボードを保存しているフォルダに対しては、Viewerの権限を付与しておきます。
動作検証
No accessの権限を設定してダッシュボードにアクセスしようとすると、No document accessと表示されました。
つまり、No accessの権限だとダッシュボードがフォルダにあることはわかっても、閲覧することは出来ないということがわかりました。
ConnectionのBase accessとグループ・ユーザーに対する権限設定はどちらが優先されるか？
こちらの公式Docを見ると、A connection’s base role will override a less permissive role set in the Model access section.とあります。つまり、Base accessより低い権限をグループ・ユーザーに対して設定しても、Base accessの方が優先されるということになります。
動作検証
こちらを動作検証するため、以下のように権限付与をしてみました。
- User Role：
Restricted querier - 所属するグループに対するRole：
Querier - ConnectionのBase Role(Base access)：
Viewer
この状態で対象のユーザーの詳細画面を開き、Model Access欄を確認してみます。
すると、Resolved Role欄が最も権限の強いQuerierになっていました。つまり、ConnectionのBase Role、所属するグループに対するRole、User Role、の中で付与されている最も強い権限がそのユーザーに適用されるということになります。
Content permissions：「Shared “root” is open」の有無でなにが変わるか
SettingsのContent permissionsで設定できるShared “root” is openですが、このパラメータの有効・無効に応じてどう画面が変わるかを確かめてみます。
動作検証
動作検証は、Organization RoleがMemberのユーザーで試してみます。
「Shared “root” is open」が有効化されている場合 ※デフォルト値
下図の通り、Hubのルート階層でフォルダを自由に作成できます。
作成したフォルダでは、作成したユーザーがOwner権限を持ちます。（Organization Adminを持つユーザーならば、権限編集や削除は自由に可能です。）
「Shared “root” is open」が無効化されている場合
下図の通り、Hubのルート階層ではフォルダを作成できません。
Hubのルート階層でフォルダを作成できるのはOrganization Adminを持つユーザーだけとなるため、権限管理を厳重に行いたい場合はShared “root” is openを無効化することを推奨します。
最後に
Omniの権限周りで挙動を確認したい点を検証して、内容をまとめてみました。
実際に検証してみないとわからないところも多くありました。どなたかの参考になると幸いです！
