はじめに
認証認可って大切ですよね
弊社には多数の社内システムが存在しており、その認証認可方式は様々です。
ADFSとSAML連携、独自実装、LDAP参照…等々
- 折角EntraIDに全ての社員情報が統合されているのに活用しないのは勿体ない
- システムが個々に認証機能を考えて実装するのは手間がかかる
- システム毎にユーザの追加削除運用がバラバラで面倒くさい
という事で内製開発の推進や、社内システムのクラウドマイグレーションに合わせて「共通機能」の１つとして共通認証基盤を実装しています。
弊社における共通機能の位置づけ
共通機能或いは共通基盤というキーワードでシステムインフラや非機能部分を統合する事で無駄を省き、運用を効率化するというアプローチは多くの会社で実施されているのではないでしょうか。
しかし、実際の利用頻度は高く無く、結果として運用保守コストが増えてしまっただけ…というリスクが存在すると思います。
そこで、今回社内で作成する共通機能はCCoEが別途作成するクラウドガイドラインへの準拠を助ける為のツールと位置づけ、共通機能を活用する事で、結果的にガイドラインに準拠出来ている状態を目指すものとしました。
そうする事でシステム関係者がガイドラインを守る為に何かをしなければならないという負のイメージではなく、便利な共通機能が出来た、コレを使った方が楽になるね。という正のイメージから共通機能を使って頂き、その結果としてガイドラインに準拠出来る環境を作った方がスムーズなのではないか。
という考え方（仮説）に基づいて共通機能を実装しています。
仕組み
概要図
AWS Cognito と EntraID を連携させることで実現しています。
実装においては コチラ のサイトなどを参考にさせて頂きました。
共通機能としては認証部分のみを実装し、認可はアプリケーション側で実装する事を想定した構成にしています。
何をもって認可するかのコントロールについてはアプリケーション側の要件に柔軟に対応できるよう、Entraprise App 側のクレーム設定で吸収する形を想定しています。
下記の図は Enterprise App 側のクレーム設定で SecurityGroup の Object ID を連携するように設定し、アプリケーション側がレスポンスで返却された Object ID を元に権限を制御する構成をイメージした図です。
躓いた点
実装において注意すべき制約が存在します。
Enterprise App の仕様として紐づけた SecurityGroup がネストされていると、ネストした 2層目以降のSecurityGroup 直下の Object は Cognito からの認証要求に答えられません。
これは Enterprise App 側の仕様・制約である為連携先が AWS Identity and Access Management であっても変わりません。
この制約の為、EntraID側に既存の SecurityGroup をネストする形では権限付与に利用できず、権限を付与するには対象者を簡単にリストアップ出来る仕組みに加えて、権限付与を楽に出来る手順や仕組みが求められることになります。
今後の改善点
EntraIDには動的グループという設定が存在する為これを Enterprise App に紐づけることが出来ないかの調査検証は引き続き実施が必要かなと感じています。
これが出来ると権限管理が楽に出来るようになるのではと考えています。
また、今後のクレーム設定として SecurityGroup の情報ではなく、ユーザのカスタム属性値を返す事で制御をさせるようにしたいと考えています。これはアプリケーション側からの要求に対する柔軟性を高めたい意図があります。
今後も弊社CCoEとしては同様の位置づけの共通機能の実装を複数計画・検討しており、システム開発担当者や運用担当者が楽を出来る、そして結果としてガイドラインにも準拠しているという仕組みの拡充を図って行きます。
弊社では一緒に働く仲間を募集中です
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！
募集内容等詳細は、是非採用サイトをご確認ください。
https://engineer.po-holdings.co.jp/