Federation Simplified (v2)

IDPro Body of Knowledgeの翻訳メモです。

元記事：https://bok.idpro.org/article/id/62/

IDPro Body of Knowledgeの翻訳メモのトップページ

Abstract

This article describes the fundamentals of enterprise identity federations, focusing on SAML and OpenID Connect (a protocol built on OAuth2.0). It will also contain common scenarios where federations are used and high-level terminology. Academic identity federations are out of scope but are mentioned briefly for comparison.

Keywords: Federation, SAML, OpenID Connect, Enterprise IAM, Single Sign On, OAuth, OAuth2.0

概要

本記事では、SAMLおよび（OAuth2.0の上に構築されたプロトコル）OpenID Connectに焦点を当てながら、企業のアイデンティティフェデレーションの基礎について説明しています。また、フェデレーションが利用される一般的なシナリオと高レベルの用語についての説明も含みます。学術的なアイデンティティフェデレーションについては範囲外であるものの、比較のために簡単に言及します。

Keywords: フェデレーション, SAML, OpenID Connect, エンタープライズIAM, シングルサインオン, OAuth, OAuth2.0

Capital One

© 2022 IDPro, Patrick Lunney

To comment on this article, please visit our GitHub repository and submit an issue .

Introduction

This article describes identity federation in the context of single sign-on in enterprises and outlines some use cases for enterprise federation integrations. Enterprises have various ways to manage federation connections: the connections may be full service within the enterprise, self-service with controls in place for governance, or manual integrations. Each integration model has its strengths and weaknesses, which will be discussed in turn below.

導入

この記事では、エンタープライズにおけるシングルサインオンの観点からアイデンティティフェデレーションについて説明し、企業におけるフェデレーション統合のいくつかのユースケースの概略を説明します。企業には、フェデレーション接続を管理するためのさまざまな方法があります：接続には、企業内のフルサービスである場合や、ガバナンス統制を備えたセルフサービスであったり、または手動の統合であったりします。各統合モデルには長所と短所があり、以下で順番に説明します。

Terminology

用語解説

Exploring Identity Federation in the Enterprise

There are several common scenarios where an identity practitioner is likely to encounter identity federation in an enterprise context. This section explores the most common protocols, OpenID Connect, and SAML.

Exploring Identity Federation in the Enterprise

アイデンティティ実践者がエンタープライズにおけるアイデンティティフェデレーションに遭遇する可能性が高い一般的なシナリオがいくつかあります。このセクションでは、最も一般的なプロトコルであるOpenID ConnectとSAMLについて説明します。

Use Case 1: SAML

ユースケース1：SAML

Figure 1 - Example of a Single Sign-On User Interface

See Appendix Item 1 for an example of a metadata file from an IdP. In that example, the IdP operator will give this metadata to the SP operator. The SP can then input this information manually (or import it, depending on their SSO platform) into their SSO system to allow the enterprise’s users to sign in to the application using their SSO accounts. The IdP operator will need to do the same, either by importing an SP metadata file or manually updating the configuration of the IdP.

An IdP metadata file contains the enterprise’s entityID, the various URLs used in SAML, and the attributes that will be passed in the SAML assertion (the data that is passed to the app). An entity ID is a unique name for a SAML entity, both an IdP and an SP. No two IdPs or SPs can share the same entityID.

Think of a SAML assertion as a voucher or ticket. The IdP gives the user a voucher to the user to get into the SP, and the SP is validating the voucher using certificate validation. After the voucher is validated, the SP will look at the attributes to see what the user can do. For example, in Appendix Item 2, you can see a user’s username and email address were passed to this SP.

For more information on the details of SAML assertions and components, see the SAML specification and associated supporting documents. ⁵

One last piece of information regarding enterprise SAML federations: there are two different types of URLs for applications. Sometimes it is the SP’s URL, for example, ‘https://myhrapp.com/enterprise’. This is known as an SP-initiated request. Other times, the IdP will initiate the request. For example, ‘https://authn.enterprise.com/idp/SAML20=myhrapp’. In both cases, the user will be logging into the same app tenant for the enterprise. Some applications only support IdP-initiated login requests. Some applications only support SP-initiated requests.

Here is a diagram flow of a standard SAML authentication:

IdPからのメタデータファイルの例についてはAppendixのItem1を参照してください。この例では、IdP運用者がこのメタデータをSP運用者に渡します。SPは、この情報を手動で入力（またはSSOプラットフォームに応じてインポート）してSSOシステムに入力し、企業のユーザーがSSOアカウントを使用してアプリケーションにサインインできるようにします。IdP運用者は、SPメタデータファイルをインポートするか、IdPの構成を手動で更新することによって、同じことをおこなう必要があります。

IdPメタデータファイルには、企業のエンティティID、SAMLで使用されるさまざまなURL、およびSAMLアサーションで渡される属性（アプリに渡されるデータ）が含まれています。エンティティIDは、SAMLエンティティ、IdPとSPの両方で、の一意の名前です。2つのIdPまたはSPが同じエンティティIDを共有することはできません。

SAMLアサーションは、バウチャーまたはチケットと考えてください。IdPは、SPに入るためのバウチャーをユーザーに渡し、SPは証明書の検証を使用してバウチャーを検証します。バウチャーが検証されると、SPは属性を調べて、ユーザーが実行できる操作を確認します。たとえば、AppendixのItem2では、ユーザーのユーザー名とメールアドレスがこのSPに渡されたことがわかります。

SAMLアサーションおよびコンポーネントの詳細については、SAML仕様および関連するサポート文書を参照してください。 ⁵

エンタープライズSAMLフェデレーションに関する最後の情報です：アプリケーションには2つの異なるタイプのURLがあります。SPのURLであることもあり、例えば「https://myhrapp.com/enterprise」など。これは、SP-initiatedリクエストと呼ばれます。それ以外の場合は、IdPがリクエストを開始します。たとえば、「https://authn.enterprise.com/idp/SAML20=myhrapp」のように。どちらの場合も、ユーザーは企業の同じアプリテナントにログインします。一部のアプリケーションは、IdP-initiatedログインリクエストのみをサポートします。一部のアプリケーションは、SP-initiatedリクエストのみをサポートします。

標準のSAML認証のフローを次に示します：

Figure 2 - SAML Authentication Flow

Use Case 2: OpenID Connect

Another common type of identity federation is internal to the enterprise and increasingly found in SaaS offerings. Previously, enterprises would use “agents,” which they would install on web servers hosting applications. The agents would communicate with something called a policy server to determine what a user could do, if anything at all. That agent/policy server technology is old and not used as much in enterprises anymore.

Instead, a popular protocol that is increasingly being used is OpenID Connect. OpenID Connect is newer than SAML and based on the OAuth2.0 protocol; most in-house enterprise apps are based on APIs and microservices, which is why OIDC is favored. ⁶ It should be noted that some SaaS applications do support OpenID Connect.

OpenID Connect uses the authorization_code grant type of OAuth2.0. It is important to note that OpenID Connect is meant to share user attributes, so it will be the only part of OAuth2.0 in this document. There are many other grant_types in OAuth2.0 which authenticate users or clients in different ways but are not part of user authentication and authorization and are outside the scope of this document.

ユースケース2：OpenID Connect

もう1つの一般的なアイデンティティフェデレーションは企業内部のもので、SaaS製品に見られることが多くなっています。以前は、企業はアプリケーションをホストするWebサーバーにインストールする「エージェント」を利用していました。エージェントは、ポリシーサーバーと呼ばれるものと通信し、もし可能であればユーザーができることを決定します。このエージェント／ポリシーサーバーの技術は古く、企業ではもうあまり使われていません。

その代わり、普及が進んでいるのがOpenID Connectというプロトコルです。OpenID ConnectはSAMLよりも新しく、OAuth2.0プロトコルに基づきます；企業内アプリケーションの多くはAPIやマイクロサービスに基づいており、これがOIDCが支持される理由です。 ⁶ 特筆すべきことに、一部のSaaSアプリケーションはOpenID Connectをサポートしています。

OpenID Connectは、OAuth2.0のauthorization_codeグラントタイプを使用します。OpenID Connectはユーザー属性を共有するためのものなので、このドキュメントではOAuth2.0の部分のみを扱うことにします。OAuth2.0には他にも多くのgrant_typeがあり、さまざまな方法でユーザーやクライアントを認証しますが、これはユーザー 認証 や 認可 の一部ではないため、このドキュメントの範囲外です。

Authorization_Code Flow

The authorization_code grant type is explained in the OAuth2.0 spec. ⁷ OpenID Connect 1.0 is based on this flow. An important consideration to note involves the scopes in OpenID Connect: they must contain openid (and most often include profile). Here is a diagram of that authorization_code flow: ⁸

Authorization_Codeフロー

authorization_codeのグラントタイプはOAuth2.0仕様で説明されています。 ⁷ OpenID Connect 1.0は、このフローに基づいています。OpenID Connectにおいて重要な考慮事項はスコープを含んでいることです：openidが含まれていなければなりません（そして多くの場合、profileも含まれています）。以下は、そのauthorization_codeフローの図です： ⁸

Figure 3 - OAuth 2.0 authorization_grant Flow

To see the API calls, please see Appendix Item 3.

APIコールを見るには、Appendix Item3を参照してください。

Challenges in Enterprise Federations

企業内フェデレーションの課題

When to Use SAML versus OpenID Connect

SAML対OpenID Connectでどちらを使うか

この質問に対する短い答えは、「場合による」です。SPができることに制限があり、IdPも同様です。両者に長所と短所があるため、実際にはIdPとSPの間の選択（または制限）の問題に過ぎません。 ⁹

Pamela DingleによるIDPro Body of Knowledgeの記事「Introduction to Identity - Part 2: Access Management」は、認証およびアクセス制御ツールの進化について興味深い見方を示しています。 ¹⁰ 特に、「モバイルとAPIの革新がOAuthと委任型認可フレームワークをもたらした」というセクションでは、SAMLの存在にもかかわらずOAuthの開発につながった進化について、興味深い洞察を示しています。

Attributes - Data and Formatting

Applications require different names for attributes. Sometimes an attribute must be called firstname, where other applications may need firstName, or perhaps even givenName. This can cause issues, as the application might not be able to pick up the attribute in the SAML Assertion / userinfo endpoint it needs to authorize the user. This is where the IdP and SP need to collaborate to determine how the attributes should be sent. In some enterprises, the attribute names do not change; the enterprise forces the application to adopt its formatting of the attribute. Other times, the application forces the IdP to change the attributes. There is also something called attribute mapping which can take place. Most SAML and OpenID Connect plugins allow this to take place in attribute mapping files, like Shibboleth. ¹¹ The IdP will send attributes, and upon receiving them, the SP can transform them into the correct format.

属性 - データとフォーマット

アプリケーションは、属性について異なる名称を要求します。ある属性がfirstnameという名称でなければならないことがありますが、他のアプリケーションではfirstNameやgivenNameという名称でなければならないこともあります。この場合、アプリケーションは、ユーザーを認可するために必要な SAMLアサーション/userinfoエンドポイントにその属性を取り込むことができないので、問題が発生する可能性があります。そこで、IdPとSPが協力して、属性をどのように送信すべきかを決定する必要があります。企業によっては、属性名は変更されず、企業はアプリケーションにその属性のフォーマットを採用させることがあります。また、アプリケーションがIdPに属性を変更するよう強制する場合もあります。また、属性マッピングと呼ばれるものがおこなわれることもあります。ほとんどのSAMLやOpenID Connectプラグインでは、Shibbolethのような属性マッピングファイルでこれをおこなうことができます。 ¹¹ IdPが属性を送信し、それを受け取ったSPが正しい形式に変換することができます。

Assertion Sizing

Quite a bit of information can be passed to SPs, and the assertion can become so large that it will break the SP. This is somewhat common when applications authorize users via Active Directory or LDAP groups (also known as SID bloat, essentially a large data blob of information about the user), and the IdP sends an array of all Active Directory groups. The SAML assertion will contain so much information that the SP will not be able to parse it out, and the user will not be able to get into the application. Resolving this issue often requires custom integrations, where there needs to be a special configuration within the IdP to manage assertions for that single application. Additionally, assertion sizes can be limited based on web servers, browsers, and even proxies. This problem can be alleviated via identity governance processes that limit the number of Active Directory groups and removes memberships no longer required.

アサーションのサイズ設定

SPにはかなりの量の情報が渡され、アサーションが大きくなりすぎてSPが壊れてしまうこともあります。これは、アプリケーションがActive DirectoryまたはLDAPグループ（SIDの肥大化とも呼ばれ、基本的にユーザーに関する情報の大きなデータの塊）を介してユーザーを認可し、IdPがすべてのActive Directoryグループの配列を送信する場合によくあることです。SAMLアサーションには非常に多くの情報が含まれるため、SPはそれを解析できず、ユーザーはアプリケーションにアクセスできなくなります。この問題を解決するには、多くの場合、カスタム統合が必要であり、IdP内にその単一アプリケーションのアサーションを管理するための特別な構成が必要です。さらに、アサーションのサイズは、Webサーバー、ブラウザおよびプロキシによって制限されることがあります。この問題は、Active Directoryのグループ数を制限し、不要になったメンバーシップを削除するアイデンティティガバナンスプロセスによって軽減することができます。

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing, commonly known as CORS, causes issues in many enterprises. CORS is a standard that allows a server to relax the same-origin policy. ¹² Usually, an API call from one application cannot be returned to a separate application. For example, if I make a request to application1.com/api, I would expect the request to come back to me and not be sent to application2.com/api. These are two different domains and application1.com could potentially be sending malicious data to application2.com.

CORS is used to explicitly allow some cross-origin requests while rejecting others. For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. If I attempt to load application1.com, and that application requires resources from application2.com, my browser will make that request through application1.com into application2.com, thus making it a cross-domain API call. CORS allows the request to pass through and retrieve information so I can visit the application.

Setting up such a CORS configuration is a challenge. It is also potentially not secure. What most IdPs can do is relax their policies to allow sharing between top-level domains, for example, *.enterprise.com or *.partner.com. This way, there will be no restrictions on the origin of requests. ¹³

Cross-Origin Resource Sharing（CORS）

一般的にCORSとして知られているオリジン間リソース共有は、多くの企業で問題を引き起こします。CORSは、サーバーに同一オリジンポリシーを緩和することを許可する標準仕様です。 ¹² 通常、あるアプリケーションからのAPI呼び出しは別のアプリケーションに戻ることはできません。例えば、私がapplication1.com/apiに対するリクエストを送信した場合、リクエストは私に返ってきて、application2.com/apiには送信されないことを期待するでしょう。これら2つは異なるドメインであり、application1.comは悪意のあるデータをapplication2.comに送信している可能性があります。

CORSは一部のオリジン間リクエストを明示的に許可し、それ以外を拒否するために利用されます。例えば、サイトが埋め込み可能なサービスを提供しているとき、特定の制限を緩和する必要がある場合があります。application1.comを読み込もうとし、そのアプリケーションがapplication2.comからのソースを必要とする場合、ブラウザはapplication1.comからapplication2.comへのリクエストを送るため、オリジン間API呼び出しをおこなうことになります。CORSはリクエストの送信、情報の取得を許可することで、アプリケーションへのアクセスを可能にします。

このようなCORS設定をおこなうことは困難です。また、潜在的にセキュアではありません。ほとんどのIdPでできることは、例えば*.enterprise.comや*.partner.comのように、トップレベルドメイン間での共有を許可するポリシーに緩めることです。この場合、リクエストのオリジンに制限がなくなります。 ¹³

Conclusion

This document is a high-level review of application federations in the enterprise. The most common protocols used are SAML and OpenID Connect. Both are widely used today in the enterprise world as well as the consumer world as well. When you see this screen:

結論

このドキュメントでは、企業内でのアプリケーションフェデレーションをおおまかにまとめました。最も一般的に利用されるプロトコルは、SAMLとOpenID Connectです。今日では両方とも企業内だけでなく、コンシューマーでも広く利用されています。このような画面を見たとき：

Figure 4 - Sample Social Login Screen

With more and more applications becoming SaaS applications, enterprises are creating more and more federations. With that, there will continue to be innovations in the single sign-on community to make them safer, such as adding multifactor authentication into the flow.

ますますアプリケーションがSaaSアプリケーションとなっていくことで、企業はさらにフェデレーションを作成していきます。これにより、フローに多要素認証を追加するなどシングルサインオンコミュニティをさらに安全にするようなイノベーションが継続されるでしょう。

Author Bio

My name is Patrick Lunney. I have managed/owned identity providers in two fortune 50 companies over the past eight years. In that time, I’ve worked with 100s of SaaS applications as well as in-house applications to ensure federations are set up securely and properly. Currently, I am the product owner for Capital One’s internal workforce Single Sign-On and Multi Factor Authentication products. All applications in our enterprise must use either OpenID Connect or SAML for SSO, with very few exceptions. I have held this role since July of 2019.

Change Log

Appendix:

Item 1: SAML Request

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="mzWO1kVu-dAmFIdmN.08s9bOaCH" cacheDuration="PT1440M" entityID="IdProvider">

<md:IdPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">

<md:KeyDescriptor use="signing">

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:X509Data>

<ds:X509Certificate>

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://authn.enterprise.com/idp/SSO.saml2"/>

<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://authn.enterprise.com/idp/SSO.saml2"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="firstname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="lastname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="userid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>

</md:IdPSSODescriptor>

<md:ContactPerson contactType="administrative"/>

</md:EntityDescriptor>

Item 2: SAML Response

<samlp:Response Destination="https://serviceprovider.com/acs"

ID="HpiyLr_zVMK.jxdUHXxRvjJ8Fwy" IssueInstant="2020-11-24T01:53:06.809Z" Version="2.0"

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">IDprovider</saml:Issuer>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

<ds:Reference URI="#HpiyLr_zVMK.jxdUHXxRvjJ8Fwy">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue>PwJICHFA1QIlML2p5MyJaRib5TDY4TWj5J7IEAjn1Yo=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue> Signature

</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>

</ds:X509Certificate>

</ds:X509Data>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>

</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</ds:Signature>

<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</samlp:Status>

<saml:Assertion ID="bJUFiJZEXV0rDgdTh9HnF2CbrIq" IssueInstant="2020-11-24T01:53:07.104Z"

Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<saml:Issuer>IDprovider</saml:Issuer>

<saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">ztl593</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2020-11-24T01:58:07.104Z"

Recipient="https://serviceprovider.com/acs"/></saml:SubjectConfirmation>

</saml:Subject>

<saml:Conditions NotBefore="2020-11-24T01:48:07.104Z" NotOnOrAfter="2020-11-24T01:58:07.104Z">

<saml:AudienceRestriction>

<saml:Audience>http://www.serviceprovider.com/</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

<saml:AuthnStatement AuthnInstant="2020-11-24T01:53:07.103Z"

SessionIndex="bJUFiJZEXV0rDgdTh9HnF2CbrIq">

<saml:AuthnContext>

<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Telephony</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

<saml:AttributeStatement>

<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Patrick.Lunney@idprovider.com</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

</samlp:Response>

Item 3: OpenID Connect

To begin the process the user agent will first make a GET request against the authorization server, passing along information about the application the user wishes to go to.

curl --request GET \

--header ‘content-type: application/x-www-form-urlencoded' \

--url “${sso_prefix}/authorization?response_type=code&redirect_uri=${redirect_uri}&scope="openid profile”&client_id=${client_id}

What will return from this request is the login page (assuming there is no session), and a user will enter their credentials so the authorization server can authenticate the user. Afterward, an authorization_code is sent to the application in the browser. The application backend must take that authorization_code and exchange it for an access token.

To exchange the authorization_code for the access token:

curl --request POST \

--url “https://${sso_prefix}/token” \

--header 'content-type: application/x-www-form-urlencoded' \

--header 'Authorization: Basic base64(urlencode("${client_id}:${client_secret}))' \

--data “code=${code}” \

--data “grant_type=authorization_code” \

--data “redirect_uri=${redirect_uri}” \

--data 'scope=openid profile'

After this exchange, the application can then make a backend API call to the authorization server to obtain additional information about the user for further authorization.

curl --request GET \

--header ‘content-type: application/x-www-form-urlencoded' \

--header 'Authorization: Bearer ${token}

--url “${sso_prefix}/userinfo

This will give applications information like this:

{

"sub" : "83692",

"name" : "Alice Adams",

"email" : "alice@example.com",

"department" : "Engineering",

"birthdate" : "1975-12-31"

}