#はじめに
DocuSign は昨今話題となっている「脱ハンコ」を推し進める為に活用できる「電子署名」や「電子捺印」を備えた SaaS アプリケーションで、Microsoft の Office 365 製品とも連携可能なアプリケーションになります。
どのような感じで使うのかについては下記 DocuSign の URL に載ってる動画がイメージしやすいかもしれません。
-参考情報
DocuSign + マイクロソフト = 生産性向上
URL:https://www.docusign.jp/solutions/microsoft
Azure AD 上のユーザーと SAML 連携することで、マイ アプリ (myapplications.microsoft.com) から各ユーザーが DocuSign のアイコンをクリックするだけでシングル サインオンできます。
また、後述しますが、DocuSign は JIT (ジャスト イン タイム) プロビジョニングに対応しており、SAML 連携したユーザーが DocuSign にシングル サインオンすると、Azure AD 側が発行した SAML Response に含まれるユーザー属性を使って DocuSign 側にユーザーを自動的に作成してくれます。
これにより DocuSign 側で個別にユーザーを作成する必要もありません。
今回は評価版の Developer エディションを利用し、Azure AD 上と DocuSign 側でそれぞれ必要な一連の設定を画面ショット付きで紹介します。
#やってみる
手順の概要は下記の通りとなります。
- DocuSign の Developer エディションを入手する
- DocuSign 側で組織の作成とドメインの申請、設定を行う
- Azure AD 、DocuSign 双方でシングル サインオンに必要な設定を行う
- マイ アプリから割り当てたユーザーでシングル サインオンできるかテストする
- (おまけ) トラブルシュート
#####1.DocuSign の Developer エディションを入手する
DocuSign 評価版などのワードで検索すると最初にたどり着く URL が「https://go.docusign.jp/o/trial/」 なのですが、この評価版では SAML を利用することできません。この評価版で使えるのは下の一覧にある、「Business Pro (企業向け)」で Business エディションなので、使えそうに見えますし、実際私も最初はこれを試しましたが、後述する設定項目が存在しませんでした。
SAML および今回は触れませんがプロビジョニングをするために必要な評価ライセンスは「https://developers.docusign.com/」 からサインアップすることで入手可能です。
サインアップすることで Developer 向けの Sandbox 環境を 30 日間無料で評価できます。
https://developers.docusign.com/ にアクセスし、画面右上の「Developer Account」→「Create account」の順に選択します。
下記画面ショットのようにサインアップの画面が表示されますので必要な情報を入力していきます。
下記は入力イメージです。
「I agree」から始まる DocuSign からコンタクトを希望するかどうかというチェック ボックスにチェックを入れなくても環境は作れますので、任意で選択を行い、「GET STARTED」をクリックします。
クリック後に、サインアップ時に入力した Email アドレス宛に下記画面ショットのようにアクティベートしてくださいというメールが届きますので、「ACTIVATE」をクリックします。
下記アクティブ化の画面にリダイレクトされますので、パスワードと秘密の質問を設定し「アクティブ化」をクリックします。
アクティブ化をクリック後に、下記画面ショットのようにサインイン後の画面が表示されます。
※この手順は必須ではないですが、言語表示を日本語に変更する場合には、画面右上のアイコンをクイックし、「Manage Profile」をクリックします。
Language & Region タブをクリックし、Language の項目をクリックします。
言語を「日本語」に変更し「SAVE」をクリックします。
※Region も同様に「日本」に変更できます。
#####2. DocuSign 側で組織の作成とドメインの申請、設定を行う
DocuSign 単体で使う場合にはこの状態から利用可能となりますが、今回の目的は Azure AD 上に登録されているカスタム ドメイン (組織ドメイン) を持ったユーザーを DocuSign 側にシングル サインオンさせることなので、DocuSign 側でも Azure AD 側のカスタム ドメインと紐づけるために必要な「組織」の作成と「ドメイン」の申請を行っていきます。
アクティブ化直後の下記画面にて、画面上部の「設定 (Settings)」をクリックします。
評価版初回利用時は Azure AD の組織で利用しているカスタム ドメインが登録されていないので、画面上部に下記画面ショットのように「組織」が構成されていない場合は赤枠で囲った「GET STARTED」をクリックします。
設定画面で組織として利用する任意の組織名を入力し「次へ」をクリックします。
そのまま「CREATE」をクリックします。
組織を作成すると、DocuSign Admin 画面に遷移します。画面一覧の「Domains (ドメイン)」をクリックします。
初回利用時はドメインは未作成の状態なので「ドメインの申請 (CLAIM DOMAIN)」をクリックします。
ドメインの申請画面で Azure AD で利用している DocuSign にシングル サインオンさせたいカスタム ドメイン名を入力し「申請 (CLAIM)」をクリックします。
ドメインの申請画面で「閉じる (CLOSE)」をクリックします。
Domains の画面で「トークンを申請 (Get Validation Token)」のリンクをクリックします。
表示される TXT Token の右のアイコンをクリックし、TXT レコードをコピーします。
この TXT レコードが登録したドメイン名が DocuSign 上でも管理されていることを証明するために必要となります。
以下作業は各 DNS レジストラによって作業内容が異なりますので詳細な手順は割愛しますが、DNS レジストラ上に下記画面ショットのように (以下はお名前.com の場合) 利用している Azure AD のカスタム ドメインのゾーンファイルにコピーした TXT レコードを追加します。
DNS レコードが反映された後に、DocuSign Admin 上の Domains 画面にて「ACTIONS」→「Validate」をクリックします。
TXT レコードの確認が完了すると、Validate に成功し対象のドメインの Status が「Active」になります。
これで対象の DocuSign のサイトに Azure AD 上で登録されているカスタム ドメイン名を持った「組織アカウント」としてサインインできるようになりました。
#####3. Azure AD 、DocuSign 双方でシングル サインオンに必要な設定を行う
次に Azure AD 及び DocuSign 側それぞれでシングル サインオンに必要な設定を行います。
手順のベースとなるのは Microsoft の公開情報になります。
-参考情報
チュートリアル:Azure Active Directory シングル サインオン (SSO) と DocuSign の統合
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/docusign-tutorial
公開情報の内容は正しいですし、公開情報を見ていただければできると言えばできるのですが、実際に構築してみた感覚としては若干コツが必要なので、手戻りなく最短で構成できる方法を記載します。
「Azure ポータル」→「Azure Active Directory」→「エンタープライズ アプリケーション」の順にクリックし、すべてのアプリケーションの画面上ににある「＋新しいアプリケーション」をクリックします。
検索ボックス内で「DocuSign」と入力し表示されるアプリケーション一覧のうち、「DocuSign」のパネルをクリックします。
画面右に DocuSign の画面が表示されるので、「作成」をクリックします。
表示される DocuSign の概要画面にて左ペインにある「シングル サインオン」をクリックします。
シングル サインオン方式の選択画面で「SAML」をクリックします。
下記画面の右側にある基本的な SAML 構成の項目を見ていただくと分かるのですが、サインオン URL に必要な ORGANIZATIONID や IDPID にどんな値を入れればいいのかが分かりません。
これは公開情報を読み解くと分かるのですが、DocuSign 側の 「SAML 2.0 エンドポイントを表示」をクリックしないと値が判明しません。
よって必須項目は一旦飛ばして画面下にある、「Or, ステップ バイ ステップの手順を表示」のリンクをクリックします。
画面右に「サインオンの構成」として「1.」から「12.」までの手順が全て表示されます。
この手順を見ながら設定していくことで SAML の設定を完了させることができます。
ブラウザーのタブで Azure ポータルと DocuSign Admin を表示させながら作業をすると効率的だと思います。
既に「サインオンの構成」内の手順の 4. までは実施済みですので手順 5. から進めます。
管理画面ホーム上の一覧にある「IDプロバイダー」のアイコンをクリックします。
IDプロバイダーの画面内にある「IDプロバイダーの追加」をクリックします。
IDプロバイダーの設定の項目で以下必須項目を順番に入力、選択していきます。
| 設定項目 | 値 (例) | 備考 |
|---|---|---|
| 名前 | 任意の値で可 | 必須項目 |
| IDプロバイダーの発行者 | https://sts.windows.net/tenantid/ | 必須項目 /サインオンの構成 7. の b. に書かれている値をそのままコピペする |
| IDプロバイダーのログインURL | https://login.microsoftonline.com/tenantid/saml2 | 必須項目 / サインオンの構成 7. の c. に書かれている値をそのままコピペする |
| IDプロバイダーのログアウトURL | https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 | 必須ではない / サインオンの構成 7. の d. に書かれている値をそのままコピペする |
| 認証要求に署名する | チェックを入れる | 必須設定 |
| 認証要求の送信 | POST | 必須設定 |
| ログアウトの送信 | GET | 必須設定 |
| カスタム属性マッピング | Azure AD 上のユーザー属性とクレームの値を DocuSign 側に渡す際にカスタマイズしたい場合は設定する。カスタマイズしなくても SSO は可 | 任意設定 |
以下のような感じで設定を行い、画面上部もしくは画面下部にある「保存」をクリックします。
以下のように IDプロバイダーが追加されます。
次に、新しい証明書の追加の前に、Azure ポータル側で設定をしますが、そのために「アクション」→「エンドポイント」の順にクリックします。
ここで表示される下記赤枠で囲った URL がそれぞれ Azure ポータル上で設定に必要な値になってきます。
一覧にすると下記のような感じです。
| DocuSign設定値 | 値 (例) | Azure AD 設定値 |
|---|---|---|
| サービスプロバイダーの発行元URL | https://account-d.docusign.com/organizations/ORGANIZATIONID/saml2 | 識別子 (エンティティID) |
| サービスプロバイダーのアサーションコンシューマーサービスのURL | https://account-d.docusign.com/organizations/ORGANIZATIONID/saml2/login/IDPID | 応答 URL |
| サービスプロバイダーのログインURL | https://account-d.docusign.com/organizations/ORGANIZATIONID/saml2/login/sp/IDPID | サインオン URL |
以下のような感じでそれぞれ設定を行い画面上部の「保存」をクリックします。
基本的な SAML 構成が完了したことで、Azure AD が捺印をする SAML 署名証明書が作成されますので、赤枠で囲った「Base64」の証明書をダウンロードし、ローカルの任意のフォルダに保存します。
次に DocuSign Admin 側の画面に戻って、「新しい証明書の追加」のリンクをクリックします。
下記画面の「証明書の追加」のボタンをクリックし、Azure ポータルからダウンロードした証明書をアップロードします。
アップロード証明書はこちらです。
アップロードが正常に完了するとメッセージと共に、ID プロバイダー証明書に証明書が追加されますので、「保存」をクリックします。
保存が成功すると下記画面ショットのように証明書のステータスが「有効」になります。
これで一通り、Azure AD 側と DocuSign 側の設定が完了しましたので、ユーザーを割り当ててシングル サインオンできるかテストしてみます。
#####4. マイ アプリから割り当てたユーザーでシングル サインオンできるかテストする
マイ アプリからシングル サインオンのテストをするためには、テストするユーザーをエンタープライズ アプリケーションに割り当てる必要があります。
Azure AD 上の DocuSign の「ユーザーとグループ」から「＋ユーザーの追加」をクリックします。
テストを行いたいユーザーを選択後、画面下の「選択」をクリックします。
1 ユーザー選択されていることを確認し、「割り当て」をクリックします。
ユーザーが割り当てられましたので、マイ アプリ (myapplications.microsoft.com) に割り当てたユーザーでサインインします。
DocuSign に割り当てたユーザーの場合は、下記画面ショットのようにマイ アプリ上にシングル サインオンが可能なアプリケーションの一覧がアイコンとして表示されますので、「DocuSign」のアイコンをクリックし、シングル サインオンできるかテストしてみます。
めでたく割り当てたユーザーで DocuSign 側にシングル サインオンできました。
DocuSign へは UPN 「test002_change@カスタムドメイン名」 ではなく、「test002@カスタムドメイン名」でサインインしていることが分かります。
具体的に DocuSign Admin のユーザー画面を見てみると、下記画面ショットのように「メール アドレス」が DocuSign にサインインするために必要な属性になっていることが分かると思います。
逆に言うと、メール アドレスを持っていない Azure AD ユーザーでシングル サインオンしようとするとシングル サインオンに失敗します。
これは、JIT (ジャスト イン タイム) プロビジョニングを行う際に SAML Response として Azure AD が発行したトークンに含まれるメール属性値を基に DocuSign 側のユーザーを作成しているためとなります。
以上で DocuSign へのシングル サインオンが完了しましたが最後におまけとして動作検証時にハマってしまったトラブルシュート ネタを載せます。
5.(おまけ) トラブルシュート
4.の手順まで行ってマイ アプリからいざシングル サインオンが動作するか試すときに、以下のように「応答アサーションに必須の属性が欠落しています」と表示された場合の対処方法を記載します。
※結論から言ってしまうと、Azure AD 側で定義されている「ユーザー属性とクレーム」上で設定している属性が対象の Azure AD ユーザーにおいて不足しているために出るエラーです。
※私の場合は Surname (姓) が不足してエラーが出ていました。
Azure AD の下記画面ショットにある「ユーザー属性とクレーム」は DocuSign 側に SAML Response としてブラウザー経由で渡すために必ず必要な属性になります。例えば赤枠で囲った「surname (姓名の姓)」が不足していた場合に上記エラーが出力されました。
対象のユーザーを見てみると、確かに「姓」の値が NULL になっていました。
下記画面のようにオンプレミス AD から「姓」の値を追加、Azure AD に同期後に再度シングル サインオンをテストしたら問題なく動作しました。
実際の本番環境ではユーザーの 姓 (surname) 名 (givenname) が欠落しているようなことはあまりないとは思いますが、テスト環境で簡易的にユーザーを作った場合には、姓名のどちらかがない、という可能性はなくはないと思うので、このエラーが出た時の参考になれば幸いです。
#おわりに
今回は電子捺印や電子署名を推し進めるために活用できる DocuSign という SaaS アプリと Azure AD を SAML 連携するために必要な手順を紹介しました。
Developer 版の SandBox 環境も 30 日間無料で評価できるので、Azure AD と連携させて使ってみたい、という方は是非試して頂ければと思います。
今回の記事が少しでも参考になれば幸いです。