シングルサインオン

シングルサインオン（SSO）は、認証と権限付与のソリューションです。ユーザーは同じ認証情報で一度ログインするだけで、関連する複数のシステムへアクセスできるようになり、便利で効率的な体験を実現します。 YiDA専用版のSSO機能は、他システムや他製品へ統合できます。ユーザーはそれらのシステムや製品に一度ログインするだけで、再度ログインすることなくYiDAの機能を直接利用でき、業務効率が向上します。 SSOの主なメリットは以下のとおりです。

便利なユーザー体験：ユーザーは一度認証するだけで複数のシステムへアクセスでき、ユーザー名とパスワードを繰り返し入力する必要がなくなります。これにより体験と生産性の双方が向上します。
セキュリティの向上：SSOは集中認証サービスを通じてユーザーの身元を検証するため、各システムにパスワードを保存するセキュリティリスクを回避し、パスワード漏洩のリスクを低減できます。
管理の簡素化：ユーザーは1組の認証情報のみを管理すればよいため、ユーザー管理の負担が削減され、システム管理者の運用コストも軽減されます。

対応プロトコル

YiDA専用版は現在、OAuth 2.0、OIDC、CASに基づくSSOに対応しています。以下では、OAuth 2.0を例に、IDaaS SSOとの統合方法をご紹介します。 OAuth 2.0の概要 OAuth 2.0は権限付与のためのオープン標準です。ユーザーが認証情報を共有することなく、サードパーティアプリに別のアプリ内のリソースへのアクセス権を付与できます。ユーザーのプライバシーとデータの安全を保護しつつ、安全で柔軟かつ標準化された権限付与を実現します。OAuth 2.0は、ソーシャルメディアのログイン、APIアクセス制御、SSOなど幅広いシナリオで利用され、ユーザーと開発者によりスムーズで一貫した体験を提供します。主なプロトコルフロー：

YiDA専用版がSSOを提供し、サービスプロバイダー（SP）として動作します。
組織管理者がSSOを有効化します。未認証の社員がYiDAへアクセスしようとすると、システムは管理者が設定したアイデンティティプロバイダー（IdP）のアドレスへページリクエストをリダイレクトします。
ユーザーがすでにIdPにログイン済みの場合、IdPはセッションからユーザー情報を読み取り、管理者が設定した方法でYiDAに返します。
ユーザーがまだIdPにログインしていない場合は、必要な情報を入力してログインする必要があります。ログイン完了後、ユーザー情報がYiDAに返されます。
YiDAはユーザー情報を受け取ると、DingTalkの連絡先APIを呼び出してユーザーの身元を検証し、サービスを提供します。

IdPはIdentity Providerの略で、ユーザー情報を保持し、認証プロセス中にユーザーとのセッションを維持する認証センターです。
SPはService Providerの略です。ユーザーがSPの提供するサービスにアクセスした際、SPがユーザーを識別できない場合、IdPに対してそのユーザーの認証を依頼します。

例：IdP - IDaaS、SP - YiDA専用版。

設定

前提条件：インターネット経由でアクセス可能な公開エンドポイントを提供する必要があります。また、ユーザー情報エンドポイントはDingTalkのuidまたはuserId（DingTalkアカウント体系に基づく）を返す必要があります。以下では、Alibaba Cloud IDaaSとOAuth 2.0プロトコルを例に、DingTalk認証システムを設定したIDaaS認証サービスを通じてYiDAへログインする方法を示します。

IDaaS側の設定

Alibaba Cloudコンソールにアクセスし、インスタンスを作成します。

OAuth 2.0プロトコルアプリを作成します（OIDCおよびCASプロトコルも同様の手順です）。

アプリ情報を設定します。

アプリ認可を設定します：IDaaS側では、さまざまな次元でアプリを認可できます。認可された範囲内のユーザーのみが、そのアプリを通じて認証されます。

アプリ情報を確認します。

YiDA側の設定

IDaaSでアプリを作成・認可した後、管理者はYiDAへ移動してSSOを有効化し、関連設定を完了します。

SSOのスイッチをオンにします。
SSO情報を設定します（ログインプロトコルを1つ選択します。以下のスクリーンショットではOAuth 2.0を例としています）。
設定を保存した後、いったんログアウトして再度ログインし、SSOサービスへリダイレクトされてログインすることを確認します。この設定は組織全体に適用されます。

YiDA SSOプロトコルのフォーマット例

返却されるアイデンティティコールバックデータは、以下のフォーマットに従う必要があります。

OAuth2

{
  "success": true,
  "code": 200, // ステータスコード
  "data": {
    "sub": "DingTalk uid or DingTalk userId"
  }
}

OIDC

設定した公開鍵に基づいて、返却されたユーザー情報をパースします。パース後のフォーマットは以下のとおりです。YiDAはsubフィールドを読み取ります。

{
    "sub": "DingTalk uid or DingTalk userId",
    "iss": "http://xxxxxx/public/api/application/plugin_oidc/oidc",
    "aud": "xxxxxxx6CPpztCvzN6tjB",
    "uuid": "xxxxxxx2baed8e7a77zqtOGeqBXbm",
    "username": "admin",
    "email": "xxxxxx@qq.com"
}

CAS

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:attributes>
            <cas:externalId>DingTalk uid or DingTalk userId</cas:externalId>
        </cas:attributes>
    </cas:authenticationSuccess>
</cas:serviceResponse>

主要な概念

概念	説明
アイデンティティプロバイダー（IdP）	外部のアイデンティティプロバイダーのメタデータを含むRAMエンティティです。アイデンティティプロバイダーはアイデンティティ管理サービスを提供します。 • オンプレミス企業IdP：Microsoft Active Directory Federation Service（AD FS）、Shibbolethなど。 • クラウドIdP：Alibaba Cloud IDaaS、Azure AD、Google Workspace、Okta、OneLoginなど。
サービスプロバイダー（SP）	IdPのアイデンティティ管理を利用し、ユーザーに特定のサービスを提供するアプリです。SPはIdPから提供されるユーザー情報を利用します。SAML以外のアイデンティティシステム（例：OpenID Connect）では、サービスプロバイダーはIdPのリライングパーティとも呼ばれます。
Security Assertion Markup Language（SAML 2.0）	企業向けユーザー認証の標準プロトコルであり、SPとIdP間の通信を実現する技術の1つです。SAML 2.0は、企業SSOの事実上の標準となっています。
SAMLアサーション	SAMLプロトコルにおける中核要素で、認証リクエストとレスポンスを記述するために使用されます。たとえば、特定のユーザー属性は認証レスポンス内のアサーションに含まれて伝送されます。
信頼関係	SPとIdP間で確立される相互信頼のメカニズムで、通常は公開鍵と秘密鍵によって実現されます。SPは信頼できるチャンネルを通じてIdPのSAMLメタデータを取得します。このメタデータには、IdPが発行したSAMLアサーションの署名を検証するための公開鍵が含まれており、SPはこの公開鍵を使用してアサーションの完全性を検証します。
OIDC	OIDC（OpenID Connect）は、OAuth 2.0の上に構築された認証プロトコルです。OAuthは権限付与プロトコルであり、OIDCはOAuthの上にアイデンティティ層を追加したものです。OAuthが提供する権限付与機能に加えて、OIDCではクライアントがエンドユーザーの身元を検証し、OIDCプロトコルAPI（HTTP RESTful形式）を通じて基本的なユーザー情報を取得できます。
OIDCトークン	OIDCは、ログイン済みのユーザーを表すIDトークン（OIDCトークン）をアプリに発行できます。OIDCトークンはログイン済みユーザーの基本情報の取得に使用されます。
Client ID	外部IdPにアプリを登録するとClient IDが生成されます。外部IdPからOIDCトークンをリクエストする際は、このClient IDを使用する必要があります。発行されるOIDCトークンにも、audフィールドにこのClient IDが含まれます。OIDCアイデンティティプロバイダーを作成する際は、このClient IDを設定します。OIDCトークンをSTSトークンに交換する際、Alibaba CloudはOIDCトークンのaudフィールドに含まれるClient IDが、OIDCアイデンティティプロバイダーに設定されたClient IDと一致するかを検証します。両者が一致する場合のみ、ロールの引き受けが許可されます。
検証フィンガープリント	発行者URLが悪意を持ってハイジャックされたり改ざんされたりするのを防ぐため、外部IdPのHTTPS CA証明書から生成された検証フィンガープリントを設定する必要があります。Alibaba Cloudが自動的にこのフィンガープリントを計算しますが、ローカルで（例：OpenSSLを使って）計算し、Alibaba Cloudが計算したフィンガープリントと比較することをおすすめします。両者が異なる場合、発行者URLが攻撃を受けている可能性があります。フィンガープリントを再確認し、正しいものを提供してください。
発行者URL	発行者URLは外部IdPから提供され、OIDCトークンのissフィールドの値に対応します。発行者URLはhttpsで始まり、標準URLフォーマットに準拠する必要がありますが、クエリパラメータ（`?`で示される）、フラグメント（`#`で示される）、ログイン情報（`@`で示される）を含めることはできません。
一時アイデンティティ認証情報	STS（Security Token Service）は、Alibaba Cloudが提供する一時的なアクセス管理サービスです。STSを使用すると、有効期間とアクセス権限をカスタマイズできる一時アイデンティティ認証情報（STSトークン）を取得できます。

FAQ

Q：YiDA SSOで他の製品をYiDAに統合できますか？

A：YiDA SSOは、YiDAを他システムや他製品に統合し、それらのシステムや製品からYiDAへのサイレントログインを可能にします。YiDAから他製品へのサイレントログインは本技術ソリューションの範囲外であり、独自にシステムを設計する必要があります。

Q：自社構築の認証システム（IDaaSではない）をYiDA SSOと統合できますか？

A：はい、可能です。YiDAでは、より軽量で設定ベースのSSO統合を実現するためにIDaaSの利用をおすすめしています。OAuth 2.0、OIDC、CASに対応する他のIdPをお持ちの場合も、YiDA SSO設定ページで正しく設定を行い、YiDAが要求するフォーマットでアイデンティティコールバックデータを返すことで統合できます。ただし、統合には一定のコストが発生する場合があります。

Q：SSO統合が正常に機能しているかを確認するには？

A：**www.your-organization-domain.aliwork.com/xxx**にアクセスして確認できます。各組織のドメインは固有であるため、YiDAはアクセス先URLに含まれる**組織ドメイン**を用いて、その組織がSSOを有効化しているかどうかを判定します。SSOが有効化されている場合、その組織のログインは標準の統一ログインではなくSSOを使用します。

Q：組織ドメインの有効化はSSO利用の前提条件ですか？組織ドメインはどこで確認できますか？

A：はい、前提条件です。組織がSSOを有効化しているかは固有の組織ドメインのマッピングを通じて判定されるため、共有のwww.yidaapps.comにアクセスしても特定の組織にマッピングできず、SSOを利用できません。YiDAプラットフォーム管理者は、組織プラットフォーム管理 > 基本情報 > 組織ドメインで確認できます。

Q：カスタマーの連絡先とDingTalk連絡先をどのようにマッピングしますか？

A：IDaaS統合の場合、このサービスはIDaaS製品によって提供されます。詳細はIDaaS製品のテクニカルサポートまでお問い合わせください。自社構築による統合の場合は、マッピングを自ら実装する必要があります。DingTalkオープンプラットフォームOpenAPIを呼び出して統合することをおすすめします。

Q：プラットフォーム管理コンソールに組織ドメインを変更するエントリが表示されないのはなぜですか？

DingTalk組織のスーパー管理者のみが、組織ドメインをカスタマイズする権限を持ちます。
組織ドメインはYiDAの比較的新しい機能です（「リリースノート」を参照）。変更にはコストとリスクが伴います。一部の古いYiDA組織では、すでに多くの業務がYiDA上で稼働しているため、2021年より前の一部の既存カスタマーには変更ボタンが表示されないことがあります。サポートまでお問い合わせのうえ有効化してください。

Q：DingTalk内でYiDAを開く場合も、SSOを経由する必要がありますか？

A：はい、必要です。

Q：モバイル（DingTalk外）でSSO経由でアクセスすると、一部のYiDA機能が利用できないのはなぜですか？

A：YiDAは現在、PC上のブラウザおよびDingTalkに対応しています。モバイルの技術ソリューションは異なるため、多くの機能（メンバーコンポーネント、一行テキストのQRコードスキャン、作業フローの引き継ぎなど）はモバイル版DingTalkに基づいて実装されており、モバイル版DingTalk以外では一部の機能がまだ対応していません。 DingTalk外でモバイルからYiDAを利用する場合の非対応機能一覧

Q：設定ミスによりYiDAへログインできなくなった場合はどうすればよいですか？

A：www.yidaapps.comドメインまたはDingTalk内からYiDAにアクセスし、SSOをオフにするか設定を修正してください。

Q：SSOは上流・下流の相互運用に対応していますか？

現在対応していません。

はじめに

クイックスタート

フォーム管理

ワークフロー設計

レポート設計

集計テーブル設計

ポータル設計

カスタムページ

統合と自動化

クールアプリ

アプリ管理

プラットフォーム管理

国際化

YiDA専用版

開発者機能

対応プロトコル

設定

IDaaS側の設定

YiDA側の設定

YiDA SSOプロトコルのフォーマット例

OAuth2

OIDC

CAS

主要な概念

FAQ

Q：YiDA SSOで他の製品をYiDAに統合できますか？

Q：自社構築の認証システム（IDaaSではない）をYiDA SSOと統合できますか？

Q：SSO統合が正常に機能しているかを確認するには？

Q：組織ドメインの有効化はSSO利用の前提条件ですか？組織ドメインはどこで確認できますか？

Q：カスタマーの連絡先とDingTalk連絡先をどのようにマッピングしますか？

Q：プラットフォーム管理コンソールに組織ドメインを変更するエントリが表示されないのはなぜですか？

Q：DingTalk内でYiDAを開く場合も、SSOを経由する必要がありますか？

Q：モバイル（DingTalk外）でSSO経由でアクセスすると、一部のYiDA機能が利用できないのはなぜですか？

Q：設定ミスによりYiDAへログインできなくなった場合はどうすればよいですか？

Q：SSOは上流・下流の相互運用に対応していますか？

​対応プロトコル

​設定

​IDaaS側の設定

​YiDA側の設定

​YiDA SSOプロトコルのフォーマット例

OAuth2

OIDC

CAS

​主要な概念

​FAQ

​Q：YiDA SSOで他の製品をYiDAに統合できますか？

​Q：自社構築の認証システム（IDaaSではない）をYiDA SSOと統合できますか？

​Q：SSO統合が正常に機能しているかを確認するには？

​Q：組織ドメインの有効化はSSO利用の前提条件ですか？組織ドメインはどこで確認できますか？

​Q：カスタマーの連絡先とDingTalk連絡先をどのようにマッピングしますか？

​Q：プラットフォーム管理コンソールに組織ドメインを変更するエントリが表示されないのはなぜですか？

​Q：DingTalk内でYiDAを開く場合も、SSOを経由する必要がありますか？

​Q：モバイル（DingTalk外）でSSO経由でアクセスすると、一部のYiDA機能が利用できないのはなぜですか？

​Q：設定ミスによりYiDAへログインできなくなった場合はどうすればよいですか？

​Q：SSOは上流・下流の相互運用に対応していますか？

対応プロトコル

設定

IDaaS側の設定

YiDA側の設定

YiDA SSOプロトコルのフォーマット例

主要な概念

FAQ

Q：YiDA SSOで他の製品をYiDAに統合できますか？

Q：自社構築の認証システム（IDaaSではない）をYiDA SSOと統合できますか？

Q：SSO統合が正常に機能しているかを確認するには？

Q：組織ドメインの有効化はSSO利用の前提条件ですか？組織ドメインはどこで確認できますか？

Q：カスタマーの連絡先とDingTalk連絡先をどのようにマッピングしますか？

Q：プラットフォーム管理コンソールに組織ドメインを変更するエントリが表示されないのはなぜですか？

Q：DingTalk内でYiDAを開く場合も、SSOを経由する必要がありますか？

Q：モバイル（DingTalk外）でSSO経由でアクセスすると、一部のYiDA機能が利用できないのはなぜですか？

Q：設定ミスによりYiDAへログインできなくなった場合はどうすればよいですか？

Q：SSOは上流・下流の相互運用に対応していますか？