Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

グループ会社横断でシングルサインオンをできるようにしてみた

こんにちは。

コーポレートエンジニアリンググループの 下村 です。 コーポレートエンジニアリングって？という方は こちら をご参照下さい。 誤解を恐れず言えば、社内ITをハックする人 といった職種です。

本日はマネーフォワード本社のSaaSに対して、グループ会社のIDでシングルサインオンをできるようにしてみた話です。

Azure Active DirectoryのAzure B2Bという仕組みを利用しているので、情報としての新しさは無いかもしれません。 ただ、企業で導入・運用してみたという記事が意外と世間に無いことがわかったので、記事を書いてみました。

どういうことか。ざっくり1行で要約。

各グループ会社で利用中の "Google WorkspaceのIDとパスワードを利用したまま" でマネーフォワード本社のSaaSにシングルサインオンできるようになります。

図で示すと下記のような形です。

発生していた課題

マネーフォワードでは毎年、数多くのグループ会社が設立/グループジョインしています。 グループ会社職員が増えたり出向関係が増えたりとしていくなかで、マネーフォワード本社と共同プロジェクトが自然と増えていきました。

そうなると、マネーフォワード本社で利用しているSaaS(Salesforceなど)にアクセスしたいという要望が出てくるようになりました。 ただ、グループ会社とは当然のことながら ID基盤が異なる ので、本社側SaaSにログインすることが困難でした。 (迂回策はあるが煩雑になったり、セキュリティレベルが下がるので積極的には運用できていなかった)

今後もグループ会社が増えていくことは明らかなので、 グループ会社のID/Passwordでマネーフォワード本社のSaaSへログインできるようにする ことが必要になりました。

本記事の構成でできるようになること

  1. 各グループ会社職員が今まで使っていたGoogle IDでマネーフォワード本社のSaaSにログインできるようになる
    • グループ会社職員のGoogle WorkspaceのIDで本社のAWSやSalesforceなどにアクセスできるようになる。
  2. グループ会社からのログインであっても、本社側が定めるセキュリティ基準に準拠できる。
    • 本社側のAzure Active Directoryを通過するため。
  3. (この構成の副産物ですが)各グループ会社情シスのOffice365関連のユーザー棚卸しが不要になる。

実際にどうやったのか

  1. 各グループ会社でAzure Active Directoryを開設(プランはFreeでOK)

  2. Google WorkspaceをIdPとしてAzure Active DirectoryとSSO、ユーザープロビジョニング連携

    • 参考にさせていただいた手順はこちら。
    • この連携によりグループ会社側ではAzure Active Directoryのユーザーメンテは不要になります(ここ重要)
      • グループ会社側でOffice365の割り当てをする場合はプロビジョニング後のIDに対して割り当てすれば、GoogleのID/PasswordでOffice365の認証、ユーザー改廃もGoogle Workspace側で作業するだけでOKになります。
        • Google WorkspaceからAzure Active Directoryにユーザープロビジョニングする際は2バイト文字が使えないので、Google WorkspaceのDisplay Nameなどに2バイト文字を設定している場合は下記設定にしておくのがおすすめです。
      • Google Directoryの属性 アプリの属性
        「Additional Details」
        └「Username」         		displayName
        「Additional Details」
        └「Alias name」         		mailNickname
        「Basic Information」
        └「Username」         		userPrincipalName
        「Basic Information」
        └「Username」         		onPremisesImmutableId
        「フィールドを選択」(＝未選択状態)を選択。 上記以外

  3. グループ会社側のAzure Active Directoryのユーザーを本社マネーフォワードのAzure Active Directoryにゲスト招待。

  4. ゲスト招待したユーザーに対して、シングルサインオンを許可。

図で表すと下記のような形です。

この構成によりおきた良い影響

1. ユーザー管理が簡略化

今回の構成にするまではグループ会社の職員を招待するには下記のようなステップが必要でした。 アカウント発行の負荷もそうですが、パスワード忘れの対応など運用負荷もなかなか高い状況でした...。 もちろん、グループ会社職員も自社と本社のIDとパスワードを管理しなければならなく、これもまた負荷でした。

1. グループ会社職員から該当SaaSに対してアクセス申請。
2. アカウント管理表などにグループ会社職員用の本社側Azure Active DirectoryのIDを発行する旨を記載。
3. アカウント管理表に基づき、ID発行担当者が本社側Azure Active DirectoryのIDを発行＆SSO割り当て。
4. グループ会社職員に対して発行したIDの初期パスワードを連絡。

これが今回の構成にすることにより、本社側Azure Active Directoryにグループ会社のIDをゲスト招待&SSO割り当てをすれば良くなり非常に簡略化＆グループ会社職員も余計なID/Passwordを管理せず、双方Win−Winの状態を構築できました。 (パスワード発行作業がなくなったことで、自動化することもできるようになったので最終的にはユーザー管理作業自体の時間がゼロになる想定です。)

2. 本社側SaaSへのアクセス障壁が下がった

前述の「ユーザー管理が簡略化」したことにより気軽にグループ会社職員をゲスト招待できるようになったので、これまで運用負荷の理由でお断りしていた依頼も受けれるようになりました。 これによりマネーフォワードグループ全体で情報共有が活発になり、企業力の強化にもつながると考えています。

たとえば...

  1. 本社側のAWS環境にグループ会社職員を招待したい。
  2. グループ会社側役員をHRMOSに招待したい。
  3. 入社と同時にグループ会社職員が全員利用するSaaS(ドキュメント共有ツール等)にアクセス可能にしてほしい。

下記のように、ライトかつシームレスにグループ会社職員の招待を依頼頂くようになったり...

グループ会社情シスの方からは「Office365用ユーザー作成、削除が不要になり快適です！」といったフィードバックを頂いたりしました。

応用編

Azure Active Directoryには SAML要求のカスタマイズという機能があります。 「▲▲の条件に合致した場合は、SaaS側に○○の値を返す」ということができるのですが、これを利用することにより...

1. 出向先のGoogle Workspaceでログインがあった場合、
2. 本社側のAzure Active DirectoryでSAML要求属性を書き換え、本社側のIDとして認証を通し、
3. 対象SaaSへ本社側IDでログイン

といったことができるようになります。 (出向してみるとわかるのですが、本社のIDにアクセスするためにChromeのプロファイルを切り替える必要があるなど、なかなか億劫なのです。そのため出向メンバーには便利に使ってもらえると考えています。)

試しに、出向しているメンバーにも利用頂き感想を聞いたところとても好評でした！(嬉しい)

※注意：こちらの構成は悪用すれば情シス側で任意のIDにログインできてしまう危険性も秘めているので、利用には十分注意が必要です。情シスメンバーの性善説に則るか運用フロー変更などで担保が必要になります。 (マネーフォワードでは今後、Azureの構成管理をTerraformやTerraformで足りない箇所は自前でコード管理することで情シスメンバーであってもAzureのログイン自体を制限していく想定ではいるので、それで担保する予定です)

補足 及び 注意点(ゲスト側環境編)

上記までの構成についての注意点や補足を下記に記載します。

  1. 現状、たまたま各グループ会社がGoogle Workspaceを利用していたのでGoogle WorkspaceをIdPとして構成していますが、Azure Active Directoryを利用中でも当然この構成は可能です。

    • Oktaなど別のIdPを利用中でも、OktaをIdPとしてAzure Active Directoryにシングルサインオンさせることが可能(まだ未検証ですが)なので、今後別のグループ会社がグループジョインしたとしても対応できる想定です。
    • 参考： OktaをIdPとしてAzure ADとのフェデレーションを構成する

  2. Google WorkspaceをIdPとした場合、ゲスト側のAzure Active Directoryの下記設定は邪魔になる(MFAが2重で求められたりする)ので下記設定を無効化することをおすすめします。

  3. Google WorkspaceをIdPとしてAzure Active Directoryへのシングルサインオンを構成した場合、Azure Active Directory側では手動でユーザー作成ができずプロビジョニングによる作成のみしかできません。手動作成したい場合は今回設定したIdP連携解除後(Fedderation解除後)にAzure Active Directory側で手動ユーザー作成後、再度IdP連携設定をする必要があります。

補足 及び 注意点(ホスト側環境編)

  1. シングルサインオン先のSaaSは当然ながら、本社側Azure Active Directoryでシングルサインオン構成済であることが前提です。

  2. マネーフォワードではマネーフォワード側Azure Active DirectoryでのMFAを有効にしています。これをすることにより、グループ会社側のGoogle WorkspaceでMFA設定漏れがあっても抑止できますがSMS/電話認証を使う場合コストが1認証あたり3.36円かかります。

  3. ゲストアカウントの月間アクティブ人数が50,000人を超えると課金されます。

  4. SaaS側でSAML認証時にSAML Requestにパスワード認証を求めるオプションであるRequestedAuthnContextが設定されている場合、これを無効化してもらうようSaaS側に設定変更を求める必要があります。

    • 経験則からあまりこれが設定されているケースはありません。(が、たまにあります)
    • あったとしてもこれが有効になっていると今回の件に限らず、パスワードレス認証ができないといった障壁があるので、SaaS事業者側にはお願いしやすい変更だと思います。

終わりに

グループ会社のID/Passwordで、本社側SaaSのログインができるようになったことでマネーフォワードグループ全体のコラボレーションが促進されるきっかけになるのではないかなと、期待しています。

なお、マネーフォワードでは、「すべての人のお金の悩みや課題を解決したい」という想いをともにするエンジニアを募集しています。

私が所属するCIO室でも募集をしているのでぜひご応募ください！

コーポレートエンジニアの募集 　←私の現在の所属はこちら コーポレートインフラの募集 ITサポートの募集

マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。

【サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly ■京都開発拠点

【プロダクトのご紹介】 ■お金の見える化サービス　『マネーフォワード ME』　iPhone,iPad　Android

■ビジネス向けバックオフィス向け業務効率化ソリューション　『マネーフォワード クラウド』

■おつり貯金アプリ　『しらたま』

■お金の悩みを無料で相談　『マネーフォワード お金の相談』

■だれでも貯まって増える お金の体質改善サービス　『マネーフォワード おかねせんせい』

■金融商品の比較・申し込みサイト　『Money Forward Mall』

■くらしの経済メディア　『MONEY PLUS』