SAMLアプリの統合
Security Assertion Markup Language（SAML）はXMLベースのプロトコルであり、シングルサインオン（SSO）と、アプリケーション間での認証および認可データの交換に使用されます。SAMLのワークフローでは、OktaはIDプロバイダー（IdP）の機能を果たすこともあれば、サービスプロバイダー（SP）の機能を果たすこともあり、その役割はユースケースに応じて異なります。
SAMLはSSOおよびエンタープライズセキュリティを実現するプロトコルとして、大抵の組織で採用されています。SAMLの主な魅力は、組織に対する攻撃対象の範囲を狭め、顧客のサインインエクスペリエンスを向上させることができる点です。
ユーザーがSAMLを使用してアプリケーションにサインインすると、IdPはブラウザーにSAMLアサーションを送信し、それがSPに渡されます。多くの場合、IdPは、SAMLアサーションを発行する前に（たとえば多要素認証（MFA）を使用して）ユーザーを検証します。
SAMLアサーションは認証、属性、認可という3種類のステートメントを持つXMLファイルです。認証ステートメントは、サブジェクトがいつどのように認証されるかを扱います。属性ステートメントは、グループメンバーシップや階層内でのロールなど、ユーザーに関する詳細を提供します。最後の認可ステートメントは、異なるリソース間でユーザーに与えられている認可レベルをSPに通知します。このように、SAMLにはこれらの機能によってユーザーに複数の権限を許可し、プロセス内でアプリケーションを保護するという、認証だけに留まらない役割があります。
管理者はOINカタログから、SAMLを機能として使用するアプリ統合をフィルターを活用して検索できます。SAML対応アプリ統合が管理者によってorgに追加され、エンドユーザーに割り当てられると、Okta End-User Dashboardに新規アイコンとして表示されます。
IDプロバイダーとしてのOkta
SAML 2.0アプリケーションは、外部アプリケーションにSSOを提供するIdPとして統合できます。また、アプリセキュリティを向上させるMFAプロンプトもサポートされます。
Oktaに登録されている外部アプリケーションへのアクセスをリクエストすると、ユーザーはOktaにリダイレクトされます。OktaはIdPとしてSAMLアサーションをブラウザーに提供します。ブラウザーはユーザーをSPと認証するためにアサーションを使用します。
- ユーザーはOktaによって保護されているアプリケーションに対し、SAMLを使用してSSOアクセスを試みます。
- SAMLサービスプロバイダーとして機能するクライアントアプリケーションが、ユーザー認証をOktaに委任します。クライアントアプリケーションはユーザーセッションを確立するため、OktaにSAMLアサーションを送信します。
- OktaがSAML IdPとしてSSOとMFAを使用してユーザーを認証します。
- Oktaはエンドユーザーのブラウザーを介して、クライアントアプリケーションにアサーションを返します。
- クライアントアプリケーションは返されたアサーションの正当性を検証したうえで、ユーザーにクライアントアプリケーションへのアクセスを許可します。
サービスプロバイダーとしてのOkta
OktaはSPとして機能することもできます。その場合はIBM Tivoli Access ManagerやOracle Access Manager、CA SiteMinderなどのSSOソリューションによる認証を利用します。
このシナリオでは、ユーザーがOktaにサインインしようとすると、認証のために外部のIdPにリダイレクトされます。ユーザーが正常に認証されると、外部IdPはSAMLアサーションを返します。これがユーザーのブラウザーに渡され、ユーザーはOktaサービスにアクセスできるようになります。
- ユーザーがブラウザーでOktaを開き、クラウドまたはオンプレミスのアプリの統合にサインインします。
- SPとしてのOktaが、ユーザー認証を外部IdPに委任します。
- 外部IdPによってユーザーが認証されます。
- IdPがSAMLアサーションをOktaに返します。
- Oktaは外部IdPが発行したSAMLトークンを検証し、必要に応じてMFAを適用します。同じく必要があれば、ジャストインタイムプロビジョニングを利用してユーザーをOkta内に作成できます。
エンドユーザーがインターネット経由でOktaにアクセスできる場合、ユーザー、クライアントアプリケーション、外部IdPのいずれもイントラネット上のファイアウォールの内側に配置できます。