Logto は、モダンなアプリや SaaS 製品向けに設計された Auth0 の代替です。 Cloud と オープンソース の両方のサービスを提供し、アイデンティティと管理 (IAM) システムを迅速に立ち上げるのをサポートします。 認証 (Authentication)、認可 (Authorization)、マルチテナント管理を すべて一つに まとめて楽しめます。
Logto Cloud で無料の開発テナントから始めることをお勧めします。これにより、すべての機能を簡単に探索できます。
この記事では、.NET Core (MVC) と Logto を使用して、SAML サインイン体験(ユーザー認証 (Authentication))を迅速に構築する手順を説明します。
前提条件
- 実行中の Logto インスタンス。始めるには 紹介ページ をご覧ください。
- .NET Core (MVC) の基本的な知識。
- 使用可能な SAML アカウント。
Logto でアプリケーションを作成する
Logto は OpenID Connect (OIDC) 認証 (Authentication) と OAuth 2.0 認可 (Authorization) に基づいています。複数のアプリケーション間でのフェデレーテッドアイデンティティ管理をサポートしており、一般的にシングルサインオン (SSO) と呼ばれます。
あなたの 従来の Web アプリケーションを作成するには、次の手順に従ってください:
- Logto コンソール を開きます。「Get started」セクションで「View all」リンクをクリックしてアプリケーションフレームワークのリストを開きます。あるいは、Logto Console > Applications に移動し、「Create application」ボタンをクリックします。
- 開いたモーダルで、左側のクイックフィルターチェックボックスを使用して、すべての利用可能な "従来の Web" フレームワークをフィルタリングするか、"従来の Web" セクションをクリックします。".NET Core (MVC)" フレームワークカードをクリックして、アプリケーションの作成を開始します。
- アプリケーション名を入力します。例:「Bookstore」と入力し、「Create application」をクリックします。
🎉 タダーン!Logto で最初のアプリケーションを作成しました。詳細な統合ガイドを含むお祝いページが表示されます。ガイドに従って、アプリケーションでの体験がどのようになるかを確認してください。
.NET Core (MVC) SDK を統合する
- 次のデモンストレーションは .NET Core 8.0 を基に構築されています。SDK は .NET 6.0 以上に対応しています。
- .NET Core のサンプルプロジェクトは GitHub リポジトリ で利用可能です。
インストール
プロジェクトに NuGet パッケージを追加します:
dotnet add package Logto.AspNetCore.Authentication
Logto 認証 (Authentication) を追加する
Startup.cs
(または Program.cs
)を開き、次のコードを追加して Logto 認証 (Authentication) サービスを登録します:
using Logto.AspNetCore.Authentication;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddLogtoAuthentication(options =>
{
options.Endpoint = builder.Configuration["Logto:Endpoint"]!;
options.AppId = builder.Configuration["Logto:AppId"]!;
options.AppSecret = builder.Configuration["Logto:AppSecret"];
});
AddLogtoAuthentication
メソッドは次のことを行います:
- デフォルトの認証 (Authentication) スキームを
LogtoDefaults.CookieScheme
に設定します。 - デフォルトのチャレンジスキームを
LogtoDefaults.AuthenticationScheme
に設定します。 - デフォルトのサインアウトスキームを
LogtoDefaults.AuthenticationScheme
に設定します。 - 認証 (Authentication) スキームにクッキーと OpenID Connect 認証 (Authentication) ハンドラーを追加します。
サインインおよびサインアウトフロー
進む前に、.NET Core 認証 (Authentication) ミドルウェアにおける混乱しやすい用語を 2 つ明確にする必要があります:
- CallbackPath: ユーザーがサインインした後に Logto がユーザーをリダイレクトする URI(Logto における「リダイレクト URI」)
- RedirectUri: Logto 認証 (Authentication) ミドルウェアで必要なアクションが実行された後にリダイレクトされる URI。
サインインプロセスは次のように示されます:
同様に、.NET Core にはサインアウトフローのための SignedOutCallbackPath と RedirectUri もあります。
明確にするために、これらを次のように呼びます:
使用する用語 | .NET Core 用語 |
---|---|
Logto リダイレクト URI | CallbackPath |
Logto サインアウト後リダイレクト URI | SignedOutCallbackPath |
アプリケーションリダイレクト URI | RedirectUri |
リダイレクトベースのサインインについて
- この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
- 複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。
リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。
リダイレクト URI を設定する
以下のコードスニペットでは、あなたのアプリが http://localhost:3000/
で実行されていると仮定しています。
まず、Logto リダイレクト URI を設定しましょう。次の URI を Logto アプリケーション詳細ページの「リダイレクト URI」リストに追加します:
http://localhost:3000/Callback
Logto サインアウト後リダイレクト URI を設定するには、次の URI を Logto アプリケーション詳細ページの「サインアウト後リダイレクト URI」リストに追加します:
http://localhost:3000/SignedOutCallback
デフォルトパスを変更する
Logto リダイレクト URI にはデフォルトパス /Callback
があり、Logto サインアウト後リダイレクト URI にはデフォルトパス /SignedOutCallback
があります。
特別な要件がない場合は、そのままにしておくことができます。変更したい場合は、LogtoOptions
の CallbackPath
と SignedOutCallbackPath
プロパティを設定できます:
builder.Services.AddLogtoAuthentication(options =>
{
// 他の設定...
options.CallbackPath = "/Foo";
options.SignedOutCallbackPath = "/Bar";
});
Logto アプリケーション詳細ページの値もそれに応じて更新することを忘れないでください。
サインイン / サインアウトボタンを実装する
まず、Controller
にアクションメソッドを追加します。例えば:
public class HomeController : Controller
{
public IActionResult SignIn()
{
// これにより、ユーザーは Logto のサインインページにリダイレクトされます。
return Challenge(new AuthenticationProperties { RedirectUri = "/" });
}
// `ControllerBase.SignOut` メソッドとの競合を避けるために `new` キーワードを使用します
new public IActionResult SignOut()
{
// これにより、認証 (Authentication) クッキーがクリアされ、ユーザーは Logto のサインアウトページにリダイレクトされ、
// Logto セッションもクリアされます。
return SignOut(new AuthenticationProperties { RedirectUri = "/" });
}
}
次に、リンクを View に追加します:
<p>Is authenticated: @User.Identity?.IsAuthenticated</p>
@if (User.Identity?.IsAuthenticated == true) {
<a asp-controller="Home" asp-action="SignOut">Sign out</a>
} else {
<a asp-controller="Home" asp-action="SignIn">Sign in</a>
}
ユーザーが認証 (Authentication) されていない場合は「Sign in」リンクが表示され、認証 (Authentication) されている場合は「Sign out」リンクが表示されます。
チェックポイント: アプリケーションをテストする
これで、アプリケーションをテストできます:
- アプリケーションを実行すると、サインインボタンが表示されます。
- サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
- サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
- サインアウトボタンをクリックして、トークンストレージをクリアし、サインアウトします。
SAML コネクターを追加する
迅速なサインインを可能にし、ユーザーのコンバージョンを向上させるために、アイデンティティプロバイダー (IdP) として .NET Core (MVC) を接続します。Logto ソーシャルコネクターは、いくつかのパラメーター入力を許可することで、この接続を数分で確立するのに役立ちます。
ソーシャルコネクターを追加するには、次の手順に従ってください:
- Console > Connectors > Social Connectors に移動します。
- 「ソーシャルコネクターを追加」をクリックし、「SAML」を選択します。
- README ガイドに従い、必要なフィールドを完了し、設定をカスタマイズします。
インプレースコネクターガイドに従っている場合は、次のセクションをスキップできます。
Standard SAML app を設定する
ソーシャル IdP のアカウントを作成し、SAML アプリケーションを登録する (IdP)
SAML コネクターの設定を見ていきましょう。
始める前に、SAML プロトコルをサポートするソーシャルアイデンティティプロバイダーにアクセスし、自分のアカウントを作成できます。Okta、OneLogin、Salesforce などのプラットフォームは、SAML プロトコルに基づく認証 (Authentication) をサポートしています。
IdP が SAML アサーションの暗号化と署名された認証 (Authentication) リクエストの受信を必須とする場合、RSA アルゴリズムを使用してプライベートキーと対応する証明書を生成する必要があります。プライベートキーは SP 用に保持し、証明書を IdP にアップロードしてください。
また、IdP の SAML アサーションを処理するために ACS (Assertion Consumer Service) URL を ${your_logto_origin}/api/authn/saml/${connector_id}
として設定する必要があります。connectorId
は Logto の管理コンソールの SAML コネクターの詳細ページで見つけることができます。
現在の Logto の設計では、認証 (Authentication) リクエストの送信にはリダイレクトバインディングのみをサポートし、SAML アサーションの受信には POST バインディングのみをサポートしています。これはあまりクールではないかもしれませんが、現在の設計はほとんどのユースケースを処理できると信じています。問題がある場合は、お気軽にお問い合わせください!
SAML コネクターの設定 (SP)
このセクションでは、各属性を詳細に紹介します。
entityID 必須
entityID
(つまり issuer
) はエンティティ識別子です。これは、エンティティ (SAML SP エンティティ) を識別し、各 SAML リクエスト / レスポンスでの同等性を一致させるために使用されます。
signInEndpoint 必須
SAML 認証 (Authentication) リクエストを送信する IdP のエンドポイントです。通常、この値は IdP の詳細ページ (つまり IdP の SSO URL
または Login URL
) で見つけることができます。
x509Certificate 必須
IdP のプライベートキーから生成された x509 証明書で、IdP はこの値を持っていることが期待されます。
証明書の内容は -----BEGIN CERTIFICATE-----
ヘッダーと -----END CERTIFICATE-----
テールを伴います。
idpMetadataXml 必須
このフィールドは、IdP メタデータ XML ファイルの内容を配置するために使用されます。
使用している XML パーサーはカスタマイズされた名前空間をサポートしていません。 IdP メタデータに名前空間が含まれている場合は、手動で削除する必要があります。 XML ファイルの名前空間については、参考を参照してください。
assertionConsumerServiceUrl 必須
アサーションコンシューマーサービス (ACS) URL は、IdP の SAML アサーション POST リクエストを受信する SP のエンドポイントです。前の部分で述べたように、通常は IdP 設定で設定されますが、一部の IdP はこの値を SAML 認証 (Authentication) リクエストから取得します。そのため、この値も必須フィールドとして追加しています。この値は ${your_logto_origin}/api/authn/saml/${connector_id}
のようになります。
signAuthnRequest
SAML 認証 (Authentication) リクエストに署名するかどうかを制御するブール値で、デフォルト値は false
です。
encryptAssertion
encryptAssertion
は、IdP が SAML アサーションを暗号化するかどうかを示すブール値で、デフォルト値は false
です。
signAuthnRequest
と encryptAssertion
属性は、IdP 設定の対応するパラメーターと一致する必要があります。そうでない場合、設定が一致しないことを示すエラーがスローされます。
すべての SAML レスポンスには署名が必要です。
requestSignatureAlgorithm
これは、Logto が SAML アサーションの署名を検証できるように、IdP の署名アルゴリズムと一致させる必要があります。その値は http://www.w3.org/2000/09/xmldsig#rsa-sha1
、http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
または http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
のいずれかであり、デフォルト値は http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
です。
messageSigningOrder
messageSigningOrder
は、IdP の署名と暗号化の順序を示します。その値は sign-then-encrypt
または encrypt-then-sign
のいずれかであり、デフォルト値は sign-then-encrypt
です。
privateKey と privateKeyPass
privateKey
はオプションの値であり、signAuthnRequest
が true
の場合に必要です。
privateKeyPass
は privateKey
を作成する際に設定したパスワードで、必要に応じて必要です。
signAuthnRequest
が true
の場合、privateKey
から生成された対応する証明書が IdP によって署名の確認に必要です。
encPrivateKey と encPrivateKeyPass
encPrivateKey
はオプションの値であり、encryptAssertion
が true
の場合に必要です。
encPrivateKeyPass
は encPrivateKey
を作成する際に設定したパスワードで、必要に応じて必要です。
encryptAssertion
が true
の場合、encPrivateKey
から生成された対応する証明書が IdP によって SAML アサーションの暗号化に必要です。
キーと証明書の生成には、openssl
が素晴らしいツールです。以下は役立つかもしれないサンプルコマンドラインです:
openssl genrsa -passout pass:${privateKeyPassword} -out ${encryptPrivateKeyFilename}.pem 4096
openssl req -new -x509 -key ${encryptPrivateKeyFilename}.pem -out ${encryptionCertificateFilename}.cer -days 3650
privateKey
と encPrivateKey
ファイルは pem 文字列として pkcs1
スキームでエンコードされることが強制されており、プライベートキーのファイルは -----BEGIN RSA PRIVATE KEY-----
で始まり、-----END RSA PRIVATE KEY-----
で終わる必要があります。
nameIDFormat
nameIDFormat
は、応答する名前 ID フォーマットを宣言するオプションの属性です。値は urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
、urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
、urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
、urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
、urn:oasis:names:tc:SAML:2.0:nameid-format:transient
のいずれかであり、デフォルト値は urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
です。
timeout
timeout
は時間検証のための時間許容範囲であり、SP エンティティと IdP エンティティの間の時間が異なる可能性があり、ネットワーク接続も遅延をもたらす可能性があるためです。単位はミリ秒で、デフォルト値は 5000 (つまり 5 秒) です。
profileMap
Logto は、通常標準ではないソーシャルベンダーのプロファイルからのマッピングをカスタマイズできる profileMap
フィールドも提供しています。各 profileMap
キーは Logto の標準ユーザープロファイルフィールド名であり、対応する値はソーシャルプロファイルフィールド名である必要があります。現在の段階では、Logto はソーシャルプロファイルから 'id'、'name'、'avatar'、'email'、'phone' のみを考慮しており、'id' のみが必須で、他はオプションフィールドです。
設定タイプ
名前 | タイプ | 必須 | デフォルト値 |
---|---|---|---|
signInEndpoint | string | true | |
x509certificate | string | true | |
idpMetadataXml | string | true | |
entityID | string | true | |
assertionConsumerServiceUrl | string | true | |
messageSigningOrder | encrypt-then-sign | sign-then-encrypt | false | sign-then-encrypt |
requestSignatureAlgorithm | http://www.w3.org/2000/09/xmldsig#rsa-sha1 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 | false | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
signAuthnRequest | boolean | false | false |
encryptAssertion | boolean | false | false |
privateKey | string | false | |
privateKeyPass | string | false | |
nameIDFormat | urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress | urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent | urn:oasis:names:tc:SAML:2.0:nameid-format:transient | false | urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified |
timeout | number | false | 5000 |
profileMap | ProfileMap | false |
ProfileMap フィールド | タイプ | 必須 | デフォルト値 |
---|---|---|---|
id | string | false | id |
name | string | false | name |
avatar | string | false | avatar |
string | false | ||
phone | string | false | phone |
参考
- OASIS Security Assertion Markup Language (SAML) V2.0 のプロファイル
- samlify - シングルサインオンのための高度に設定可能な Node.js SAML 2.0 ライブラリ
設定を保存する
Logto コネクター設定エリアで必要な値をすべて記入したことを確認してください。「保存して完了」または「変更を保存」をクリックすると、SAML コネクターが利用可能になります。
サインイン体験で SAML コネクターを有効にする
ソーシャルコネクターを正常に作成すると、サインイン体験で「SAML で続行」ボタンとして有効にすることができます。
- コンソール > サインイン体験 > サインアップとサインイン に移動します。
- (オプション)ソーシャルログインのみが必要な場合は、サインアップ識別子に「該当なし」を選択します。
- 設定済みの SAML コネクターを「ソーシャルサインイン」セクションに追加します。
テストと検証
.NET Core (MVC) アプリに戻ります。これで SAML を使用してサインインできるはずです。お楽しみください!
さらなる読み物
エンドユーザーフロー:Logto は、MFA やエンタープライズシングルサインオン (SSO) を含む即時使用可能な認証 (Authentication) フローを提供し、アカウント設定、セキュリティ検証、マルチテナント体験の柔軟な実装のための強力な API を備えています。
認可 (Authorization):認可 (Authorization) は、ユーザーが認証 (Authentication) された後に行えるアクションやアクセスできるリソースを定義します。ネイティブおよびシングルページアプリケーションの API を保護し、ロールベースのアクセス制御 (RBAC) を実装する方法を探ります。
組織 (Organizations):特にマルチテナント SaaS や B2B アプリで効果的な組織機能は、テナントの作成、メンバー管理、組織レベルの RBAC、およびジャストインタイムプロビジョニングを可能にします。
顧客 IAM シリーズ:顧客(または消費者)アイデンティティとアクセス管理に関する連続ブログ投稿で、101 から高度なトピックまでを網羅しています。