OutSystms Developer Cloud ( ODC ) のIdP認証機能とは? ~特長と設定方法を実際の画面で解説~(Vol.24)
- 公開日:
- 最終更新日:
2023年4月より、OutSystemsの新製品である「OutSystems Developer Cloud(以降、ODCという)」の日本での提供が開始されました。
「ODC」では、従来の製品である「OutSystems 11(以降、OS11という)」同様、Identity Provider(以降、IdP)の設定を行うことができますが、OS11と比べて設定方法や連携可能なプロトコルに変更が加わっています。
本ブログ記事では、ODCにおけるIdPの概要とその設定方法について、実際の操作も交えながらわかりやすく解説します。
目次
OutSystems Developer Cloud (ODC)のIdP認証機能とは?
【IdP認証機能の概要】
IdPとは、Identity Providerの略称で、デジタルID情報を保存/識別し、アクセスしてきたユーザーが本人であるかどうかを確認する認証機能のことです。
ODCでは、管理ポータルのODC Portal上でIdPの設定を行うことができます。
対応しているのは、次の5種類です。
- OpenID Connect
- Apple
上記の通り、2024年1月時点のODCは、SAML認証に対応していません。要件上ODCでSAML認証を利用する必要がある場合、OpenID Connectを使用したIdPを設定した後、連携先でAWS Cognitoなどのサービスを利用してSAML認証を構築する必要があります。
IdPの設定手順そのものは非常に分かりやすいものになっています。ODC Portal上で連携に必要な情報を入力し設定を保存した後、それを適用先に対して有効化することで使えるようになります。開発したアプリケーションで認証を行うにはアプリケーション側での実装も多少必要です。手順の詳細は次章で解説いたします。
【Group mapping機能】
ODCからは新たにIdPを介した「Group mapping」機能が追加されました。「Group mapping」機能はIdP連携先でユーザーが所属しているグループの情報を、ODCのエンドユーザーグループにマッピングできる機能です。
OS11では、エンドユーザーの認可をまとめて管理できる「グループ」機能が提供されていましたが、「グループ」へのユーザーの紐づけ/解除は手動で行うのが基本でした。自動化が必要な場合はアプリケーションを開発する必要があったため、認証はIdP機能で手軽にできる一方、認可の面にはやや不便な点があったのが実情でした。
ODCでの「Group mapping」機能の登場によって、ユーザーを認証時に自動的に「グループ」に紐づける設定が可能になり、運用負荷の低減が期待できます。ただし、ODC Portal上で「グループ」を作成する作業や、アプリケーションで定義したロールを「グループ」に紐づける作業は引き続き必要です。
OutSystems Developer Cloud (ODC)でのIdPの設定方法とは?
それでは実際に、ODCでIdPを設定してみましょう。
今回はMicrosoft Entra ID(旧:Azure AD)と連携し、開発したアプリケーションでログインできるようにします。
- IdPを追加する
まずはODC Portalのサイドメニューの「USERS & ACCESS」ツリーにある「Identity providers」を選択し、IdPの管理画面を開きます。この画面ではデフォルトの認証である「Built-in provider」が既に存在しています。
「Add provider」から「OpenID Connect」を選択し、IdPを新規作成していきます。新規作成画面では、以下の入力が必要です。
・Provider name・Basic configuration
・Discovery endpoint
・Client ID
・Client secret (secret value)
・PKCE
Provider nameは、ODC上でIdPを識別するための任意の名称をつけます。
その他の項目を設定するには、Microsoft Entra管理センターでの作業が必要になります。Microsoft Entra管理センターで、ODCへのアクセスを認証するアプリケーションを登録します。
アプリのディスカバリーエンドポイントは「概要」画面の「エンドポイント」で開かれるサイドバーの「OpenID Connect メタデータ ドキュメント」で確認できます。同じ「概要」画面からクライアントIDも確認可能です。
続けて「証明書とシークレット」画面でクライアントシークレットを作成し、その値も取得しておきましょう。
それらの取得した値を、ODC PortalのBasic configurationに入力します。PKCEはデフォルトで選択されている「SHA-256」のまま、その他の値もデフォルト値にします。入力したら、Discovery endpointの横にある「Get Details」ボタンからその他の情報を自動取得しましょう。
「Save」ボタンを押し、設定を保存します。 - IdPを有効化する
IdPは作成するだけではなく、Assignすることではじめて有効化されます。まずはIdPの詳細画面にある「Redirect URLs」のタブにて、Assign先の「Login URL」、「Logout URL」を確認します。
値はMicrosoft Entra管理ポータルで登録したアプリの「認証」ページにて、WebのリダイレクトURIとして追加しておきましょう。次に、ODC PortalでIdPの「Assign」ボタンを押下し、有効化する先を選択します。
- Organization:開発者アカウントのログイン時にIdPを選択できるようになります(Built-in providerとの併用が可能です)
- All apps in all stages:すべてのステージのアプリケーションでIdPによるログインを可能にします。
- Development (/QA) /Production:各ステージのアプリケーションでIdPによるログインを可能にします。
現在ログイン中のユーザーがすべて自動的にログアウトされる警告メッセージが表示されます。内容を確認し「Confirm changes」を押下します。
これでIdPが有効化されました。「Organization」へのAssignの場合は、ここまでの手順でセットアップは完了です。今後ODC Portalへのログイン時にはBuilt-in providerまたはAssignしたIdPのいずれかを選択することができるようになります。
いずれかのステージにAssignした場合、各アプリケーションでの実装が必要になります。次の章では、作成したIdPのみで認証させるようにロジックフローを変更していきます。なお、実装次第でBuilt-in providerと併用することも可能です。
OutSystems Developer Cloud (ODC)で開発したアプリへのIdP認証機能の実装方法とは?
【ログインフローの変更】
まず、ODC Studioで認証処理を変更したいAppを開きます。Interfaceタブにて「Common」フローのログイン画面やUserInfo Blockなど通常の認証処理に関連する部分は、削除するか、未認証のユーザーがアクセスできないように変更します。次に、同じく「Common」フロー内にある「OnException」ハンドラを開き、「SecurityException」ハンドラのフローを以下の通りにカスタマイズします。
「GetExternalLoginURL」は通常は参照に含まれていないため、プラグのアイコンの「Add public elements」から該当のClient Actionを参照に追加します。「IdentityProvider」プロパティは、有効化したIdP名を設定します。「RedirectToURL」には、「GetExternalLoginURL」のOutput Parameterである「ExternalLoginURL」を設定しましょう。
通常の認証処理に関連する部分を削除していた場合は、エラーが発生している箇所で上記と同等の変更を行います。
【ログアウトフローの変更】
続けて、ログアウトフローを編集します。「Common」フロー内「UserInfo」BlockのClient Logoutアクションは、フロー上に配置されている「Logout」Client Actionを削除し、代わりに「GetExternalLogoutURL」を実行して、そのOutput Parameterを「RedirectToURL」のURLプロパティに設定するようにします。
これで認証に必要なセットアップは完了です。アプリをPublishし、動作確認を行いましょう。
Microsoft Entra IDを介してユーザーを認証できたことが、右上のユーザー情報欄で確認できます。なお、画像のように初めてログインしたユーザーにはロールが割り当たっていないため、通常はInvalid Permissions画面に遷移します。アプリを利用するためにはODC Portalでロールの割り当てを行ってください。
まとめ
さてここまで、ODCでのIdPの設定方法について解説して参りました。
IdPはセキュリティを担保しつつ開発者やユーザーの負担を減らすことが可能となりますので、積極的に取り入れていくことをおすすめします。
また、ODCにおけるLibraryの概要と「リリース」機能の特長について「OutSystems Developer Cloud ( ODC ) のLibraryとは?~リリース機能について、実際の画面で解説~(vol.23)」のブログで解説しておりますので、是非ご覧ください。
OutSystemsでは利用の拡大に伴い、多くの開発者が数多くのアプリを同時に開発するようになっていきます。OutSystemsを導入する上で、今回解説した「認証ロジックの変更手順を開発者に周知する」、あるいは「開発者が意識しないでも済むようにアプリテンプレートを作成する」といった、プラットフォームの機能を熟知したメンバーによる横断的な対応が欠かせません。
弊社はODCの導入実績があるほか、積極的にODCの調査・検証を行っております。
また、OS11も含むOutSystemsの様々な導入・開発の知見をもとに、お客様の社内でOutSystemsの活用を推進するCenter of Excellence(CoE)チームを組成し、スムーズな導入と環境全体の統制、そして利用範囲の拡大をご支援するサービスをご提供しております。
ODCの導入やCoEチームの有用性/組成方法についてご興味のある方は、是非、弊社までお問い合わせください。
https://itsol.dentsusoken.com/outsystems/inquiry/
電通総研では、ローコード開発プラットフォーム:OutSystemsの導入/活用を支援する様々なサービスメニューをご用意しております。
ローコード開発のはじめの一歩を、電通総研と一緒に踏み出してみませんか?
電通総研のOutSystems関連サービスページ:
https://itsol.dentsusoken.com/outsystems/service/
本ブログは、2024年2月1日時点の情報をもとに作成しています。
OutSystemsに関する詳しいお問い合わせは、弊社Webサイトからお問い合わせください。