はじめに

Outsystemsのアプリケーションで使用するユーザー(エンドユーザー)は提供された環境で共通管理され、同じ環境内であれば異なるアプリケーションのユーザーであっても同一のデータベース(モジュール)で管理される。
※開発者アカウントもユーザーと呼ばれるがエンドユーザーとは別物

管理方法については専用の管理プラットフォームが提供され、追加や削除、パスワード編集など認証に関する操作や権限の作成、付与など認可に関する操作もデータベースを意識する事なくGUIで行う事ができる。

またアプリ内での認証や権限操作に関するメソッドもOutsystemsが提供するSystemモジュールから使用でき、Session認証やトークン認証に該当する複雑な機能も簡単に実装できる
※デフォルトのInternal認証(後述)

多機能な反面ユーザー数は利用料金に直接影響するため理解が必要になる

内容に誤りがあったらご指摘を…

エンドユーザーの分類

※参考：エンドユーザー
エンドユーザーはInternalとExternalに分類されるが、上記のドキュメントを見る限り特別な権限の違いは見当たらない。

プラットフォームからユーザーを管理

参考：ロールベースのセキュリティ

MyPlatform > Users
環境内のアプリのエンドユーザーが一覧で表示される

※図は最初から用意されているサンプルユーザー

ここからユーザーを選択すれば指定したユーザーの名前、パスワード変更、権限付与などの操作が可能
※権限の作成はService Studioのモジュール開発から行う

Emailアドレスが指定されたドメインを含む場合Internalユーザーに分類される

Service Studioでの開発におけるUserエンティティ

User情報のEntityは(System)モジュールが持っており、開発中どのモジュールからでも共有される。

SystemモジュールのUserエンティティ

Outsystemsがデフォルトで提供するユーザーが特殊なのは、同じ開発環境で使用するどのアプリケーションであっても、Userエンティティが共有される点

例えば、Users管理コンソールで作成したユーザーは権限がデフォルトのままであれば、Outsystesmから提供された環境の中の全てのアプリケーションにログイン可能で、エンティティから情報を参照する事も可能となる。

そのため、Outsystemsが提供するエンドユーザー機能を使用して認証、認可を実装する場合、アプリケーションの利用ユーザーにOutsystemsのUserエンティティを紐づける必要がある

例えばDoctor(医師)とPatient(患者)をUserに紐づけてエンドユーザー機能を使用する

上記の場合、医師と患者の情報を切り分けてUserに紐づける事ができる

また、医師、患者がそれぞれアクセスできる画面や情報も制限する必要があるが、これは後述するRole(権限)機能を使用する

Role(権限)の操作

権限の操作を行う方法はService Studio、管理コンソールの２種類がある

Service Studioにおける権限操作

Service StudioではLogic > Rolesから権限の作成ができる

その際、Check(権限の有無の検証)、Grant(権限の付与)、Revoke(権限の解除)を行うメソッドも同時に作成される

通常のアプリケーションで認可機能を実装する際は、権限のテーブルを作成しユーザーに紐づける事でユーザーがどんな権限を有するかの検証、権限の操作などの機能を実装していくが、
OutsystemsではUserテーブルや権限についてのテーブルを作成する必要はなく、自動生成されるこれらのメソッドを使用して簡単に認可の機能を作成できる

Interfaceから画面にアクセスできるRoleを指定可能

デフォルトの権限、Anonymous(認証不要)、Registere(ユーザー登録者のみ)に加え、先ほど作成したMyRoleが追加されている

管理コンソールにおける権限操作

Service Studioで追加したRoleはUsers管理コンソールから操作可能

すべてのユーザーのRoleにモジュールで作成したMyRoleが選択可能となっている

またGroupを作成して権限をまとめて付与できる
参考：[OutSystems]プログラムからUsersアプリケーションのGroupを操作する

認証機能

エンドユーザーの認証方法は上記のUser管理プラットフォームから変更可能
参考：エンドユーザー認証

ここではデフォルトのInternal認証について記述する

Internal認証

Internal
デフォルトの認証方式です。エンドユーザーの情報は、OutSystemsのデータベースに保存されます。資格情報は保存されませんが、資格情報を基にした暗号のハッシュ関数を計算し、その結果のみが保存されます。エンドユーザーがログインを試行すると、ハッシュ関数を再計算し、その結果をデータベースの値と比較します。

Internal認証ではユーザー情報をデータベースに保持し認証に検証する

Systemモジュールの認証機能

依存性の管理からSystemモジュールを検索すると、既に様々なロジックが使用されている

共通のUserエンティティ、Login、Logoutロジックなど
これらをServer Action内で使用し認証時の処理などを拡張する事ができる

疑問とまとめ

Outsystemsの提供するユーザーには認証や認可などの様々な機能を開発、管理するための基盤が備わっている。

しかし、ユーザー数を増やしたりユーザー情報を同じ環境内で共通管理したくないといった理由で、Outsystemsのユーザーを使いたくない場合など、別途でUser用のモジュールを自作し認証や認可に関わる機能を実装する事で同様の機能は実現可能なのではと感じた。

まだ認識しきれていない機能がありそうなので実際にアプリを作りながら調べていきたい。