OutSystemsのようなローコード開発プラットフォームを導入する際は、開発手法やプラットフォームのアーキテクチャなど、製品の様々な仕様を理解しなければなりません。その中でもとりわけ重要なのが、最終的なアプリケーション利用者となるエンドユーザーの権限管理の仕組み＝ロール（Role）の構造を理解することです。
OutSystemsでは、アクセス制御をどのように定義でき、どのような階層構造になっているのか？会社の組織情報や既存の権限管理システムで持っている情報を反映することはできるか？これらは製品の導入可否を判断する際のポイントにもなるため、システム管理者は必ず知っておくべき内容です。

そこで本ブログ記事では、OutSystemsの権限管理の仕組み＝ロール構造について、プラットフォーム全体を管理する視点から図解、適切なアクセス制御を実現する方法をわかりやすく解説します。

OutSystemsの権限管理の仕組み（ロール構造）とは？

まず最初に覚えておくべき基本的な考え方として、OutSystemsのロール（Role）は、「システムロール」と「カスタムロール」の2つに大別されるという点が挙げられます。

1. システムロール
   システムロールは、OutSystemsが標準で提供している作成済みのロールです。
   システムロールには、「Anonymous」と「Registered」の2つのロールしか存在しません。
   ・Anonymous：ログインしていないユーザーを含むすべてのエンドユーザーに付与されるロール
   ・Registered：ログイン済みのエンドユーザーに付与されるロール

   

   これはつまり、システムロールでは、エンドユーザーとしてログインしているかどうかのみを判別できるということを意味します。
   そのため、開発者はほとんどの場合、追加のカスタムロールを作成し、ログイン済みのエンドユーザーに対してアプリケーションの各種操作を制御することになります。
   ＊未ログインのユーザーにカスタムロールは付与できません。

2. カスタムロール
   カスタムロールは、開発者が必要に応じて作成できるロールです。
   カスタムロールは、開発ツールを使用することでモジュールの中に作成できます。
   モジュールは各々の役割によって分割されており、複数のモジュールが組み合わさることでアプリケーションとしてエンドユーザーに最終的な機能を提供します。
   つまり、OutSystemsにおいては、アプリケーションで実現したい機能が出発点であり、その機能の利用可否を決定する役割としてカスタムロールが内包されているのです。

   

   また、カスタムロールは開発環境上でのみ定義できます。本番環境上では定義した内容を変更することはできないため、アプリケーション開発時に適切な設計を検討した上でカスタムロールを定義する必要があります。

   カスタムロールの付与／剥奪は、標準で提供されているUsersアプリケーションを使用することで簡単に管理することができます。

   カスタムロールは2種類の方法でエンドユーザーに適用されます。個別のユーザーに直接付与／剥奪する方法と、複数ユーザーと複数ロールをGroupにまとめて一括で付与／剥奪する方法です。直接付与とGroupでの付与の2つの方法に優先順位はなく、いずれかの方法で付与されていれば、カスタムロールは有効となります。

   

   また、ユースケースは限られますが、開発したアプリケーションのロジック内で付与／剥奪することもできます。これは実際の動作はエンドユーザーへの直接付与と変わりません。

ここまで、ロールの基本的な考え方について解説して参りました。
改めて本章の内容を整理すると、下図のようになります。

自動付与されるシステムロールは問題にはならないかと思いますが、自由に作成できるカスタムロールは設計者によるバラつきが生じやすい部分です。
そこで次章は、ロールを適切に設計するためのポイントを解説します。

OutSystemsで拡張性を考慮した権限（ロール）を設計するポイントとは？

OutSystemsの利用期間が長くなると、プラットフォーム上に存在するアプリケーションの数も増えていきます。アプリケーション内で定義してきたカスタムロールも整合性が取れなくなり、場合によっては再設計の必要性が出てきてしまいます。そのような事態を出来る限り避けるためには、OutSystems利用の初期段階から拡張性を考慮してカスタムロールを設計できなければなりません。
OutSystemsで様々な開発を担ってきた弊社が考える“カスタムロール設計のポイント”は次の通りです。

Groupで付与することを前提に検討する

前章では、カスタムロールに2つの管理方法があることを解説しました。個別で管理する方法と、Groupで一括管理する方法です。
今後の拡張性を考慮するのであれば、Group一括管理のみを活用することを推奨します。それは今後、ユーザー数が増えることで、「大人数に一括でカスタムロールを付与したい」という場面が必ず生まれるからです。その際、個別管理の運用もしていると、両者の整合性を取るのが難しくなります。「Groupのカスタムロールは剥奪したのに、個別でカスタムロールが付与されており、権限が有効のままだった」という状況も発生し得ます。初めからカスタムロールはGroupのみで付与する方針にしておけば、そのような運用面の混乱を未然に防ぐことができます。

組織構造でカスタムロールを定義しない

エンドユーザーの権限は多くの場合、その人自身の所属部署や職位に基づくことかと思います。そのため、開発者はカスタムロールを設計する時、「利用部署の数だけカスタムロールを作成しよう」とか、「職位が異なるのでカスタムロールを分けよう」などと考えてしまいがちです。
考え方としては決して誤りではありませんが、そのように設計したカスタムロールは組織変更によって部署が分割された時や、想定と異なる特殊なエンドユーザーが登場してきた時などに再設計の必要性に迫られてしまいます。そのため、「○○部ロール」や「マネージャーロール」のような定義の仕方は避けるべきでしょう。

アプリケーションの操作内容でカスタムロールを定義する

最も重要なポイントはこちらです。アプリケーションの操作内容というのは、例えばマスタ管理のアプリケーションであれば「参照」ロールと「更新」ロールのような構成、ワークフローのアプリケーションであれば「申請」ロールと「承認」ロールのような構成のことを指します。一つのアプリケーション内でも操作の種類の数だけロールが必要になってしまいますが、前2項のポイントを踏まえれば、Groupで複数のロールをまとめることが出来ますし、Groupが組織構造を反映するように整備すれば、組織変更によるプログラムへの影響を極小化することができます。

カスタムロールは不用意に共有しない

アプリケーションの数が増えると、似たようなアプリケーションも現れます。OutSystemsでは、定義したカスタムロールを公開（Public）することで、環境内の別の機能でもそのカスタムロールを利用できるようになります。エンドユーザーの視点からすると、一つのカスタムロールで異なるアプリケーションの操作権限を得られるので便利なように感じられますが、これをわざわざ共有する必要はないでしょう。同じGroupにカスタムロールを入れてしまえば、目的は達成されるはずです。この方がアプリケーションの機能スコープが変動した場合でも、カスタムロールへの影響を最小限に抑えられます。

これら4つのポイントはあくまで弊社のこれまでの開発経験を基にした、拡張性を考慮した設計をするための推奨事項であり、必ずしも全てのケースに当てはまるわけではありません。連携先システムのロールを模倣するケースや、セキュリティ上の理由で既存の権限管理システムと辻褄を合わせる必要があるケースなど、様々な状況があります。したがって、最終的には導入環境の状況を踏まえて方針を決定する必要はありますが、これらのポイントを理解しておくだけでも、効率的な運用を実現するための一助となるはずです。

OutSystemsの権限（ロール）管理を効率化できるツール・機能とは？

最後に、権限（ロール）管理をさらに効率化できるツールや機能をご紹介します。

• Groupのエンドユーザー一括登録ツール
  標準で提供されているUsersアプリケーションでは、Groupに所属させるために一人ずつエンドユーザーを選択しなければなりません。大量の利用者を初期登録する場合、Excelから一括登録できる処理を開発すると効率化が図れます。
• 権限管理システムとの連携機能
  導入環境によっては、社内標準の権限管理システムと同期する必要があるかもしれません。一定期間ごとにシステムからエンドユーザーの権限付与状況を読み出し、Groupに所属させるTimer機能があると便利です。

※これらのツール・機能の詳細は、今後、別のブログ記事で解説する予定です。

まとめ

さてここまで、OutSystemsにおける権限管理の仕組み＝ロール構造と、拡張性に長けた設計をするためのポイントを解説してまいりました。
様々なビジネスニーズに対応したアプリケーションを開発できるOutSystemsだからこそ、環境内の統制を図ることは非常に重要です。今回解説した権限（ロール）はOutSystems導入初期にはイメージしにくい部分かと思いますので、本ブログ記事がOutSystems導入の懸念を払拭するための一助となれば幸いです。

弊社電通総研は、ローコード開発プラットフォーム：OutSystemsの導入/活用を支援する様々なサービスメニューをご用意しております。
ローコード開発のはじめの一歩を、電通総研と一緒に踏み出してみませんか？

電通総研のOutSystems関連サービスページ：https://itsol.dentsusoken.com/outsystems/service/

本ブログは、2023年5月1日時点の情報をもとに作成しています。
OutSystemsに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。
https://itsol.dentsusoken.com/outsystems/inquiry/