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のいずれもイントラネット上のファイアウォールの内側に配置できます。