1

私はこれに対する答えを探しましたが（調べても）、これまでのところ有用なものは何も思いつきませんでした。私はADFS、STS全般、およびWIFにかなり慣れていないため、明らかな無知や用語の不適切な使用を許してください。;)

現在、カスタム MVC3 アプリを ADFS 経由で外部 IdP と統合しています。ADFS から IdP へのセットアップはすべて完了し、機能しています。

サイトの一部は、anon ユーザーがアクセスできます。web.config では、認証モードが none に設定されています。他の部分は、コントローラー/アクション メソッドをカスタム System.Web.Mvc.AuthorizeAttribute で装飾することによって保護されます。

WsFederationAuthenticationModule を使用するための web.config への通常の変更はすべて行われ、95% 動作します。ユーザーは、サイトの匿名アクセス可能な部分を参照できます。保護された部分をヒットしようとすると、Authorize 属性は、HttpContext.Current.User に関連付けられた IClaimsPrincipals に IdP からのカスタム情報があるかどうかを確認し、ない場合は ActionResult を 401 に設定します。WsFederationAuthenticationModule が開始され、IdP のログイン ページにリダイレクトされます。詳細を入力すると、いくつかの FedAuth Cookie を使用して正常にリダイレクトされ、認証が成功します。

問題は、IdP のログイン ページに到達したときに始まります。この特定の IdP には、この SAML 応答がどこかに埋め込まれた、当社のサイト (元の要求が行われたのと同じページ) に直接戻るためのリンクがあります (これは彼らのドキュメントによると)。

urn:oasis:names: tc:SAML:2.0:status: AuthnFailed

この時点で、それらは「無許可」になり、ユーザーが表示するのは (少なくとも開発環境では) 401 ページだけです。もう一度開始するには、セッションを強制終了するか、その Cookie を削除する必要があります。

私がする必要があるのは、IdP からのリダイレクト リクエストをインターセプトし、基本的にその特定の SAML ステータスをチェックすることです。これは、ユーザーが何も起こらなかったかのように、許可されていない領域の 1 つにリダイレクトされるためです。global.asax で次のようなことを試しました。

 protected void Application_Start()
    {
        // mvc stuff here....

        // add handler to intercept handling creation of security tokens by WsFederationAuthnticationModule
        FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
    }

    void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
    {
        FederatedAuthentication
            .WSFederationAuthenticationModule
            .SessionSecurityTokenCreated += WSFederationAuthenticationModule_SecuityTokenCreated;
    }

    public void WSFederationAuthenticationModule_SecuityTokenCreated (Object sender, SessionSecurityTokenCreatedEventArgs args) 
    {          
        var token = args.SessionToken;
        // do something with the session token here e.g. check for SAML status
    }

..しかし、そのトークンに役立つものは何もありません。特定の応答ステータスを示すものは何もありません。FedAuth cookieはまったくあるが Idp からのカスタム情報がないという事実は、ユーザーがそこにいたが何らかの理由で認証に失敗したことを完全に明らかにしますが、原則としてそのステータスを確認できるようにしたいと考えています。IdP でのタイムアウトにも対処する必要があるかもしれません....

たぶん、私はこれをすべて間違っているか、単に理解していないだけかもしれませんが、これらの応答ステータスを判断する方法を教えてもらえますか?

ふぅ。ありがとうございました！:D

4

1 に答える 1

2

わかりましたので、私は自分の質問に答えるつもりです。

IdP からそのカスタム ステータスを取得できるかどうかの答えは、現時点ではノーです。:(

ただし、これは ADFS がそれをキャプチャして渡すように設定されていないためです。どうやら、ADFS と IdP の間で開かれているバック チャネルから情報を取得するために、カスタム コーディングを行う必要があるようです。現在の作業範囲をはるかに超えています。

当面の回避策として：

  • サイトに対してリクエストが行われ、SAML トークンがない場合は、Idp で認証を試みていないユーザーによる新しいリクエストです。
  • SAML トークンはあるが、トークンに IdP からの ID がない場合 (これは、適切に認証された場合にのみ存在します)、ユーザーは何らかの理由で認証に失敗しました
    • ID が存在する SAML トークンがある場合、ユーザーは適切に認証されます

素晴らしいとは言えませんが、許容範囲です。ところで、すべてのクレジットは、SAML トークンを確認できる次のコードについて、このSO投稿のYMCに送られます。

void WSFederationAuthenticationModule_SecurityTokenReceived(object sender, SecurityTokenReceivedEventArgs e)
    {
        var message = SignInResponseMessage.CreateFromFormPost(Request) as SignInResponseMessage;
        var rstr = new WSFederationSerializer()
            .CreateResponse(message,
            new WSTrustSerializationContext(
                SecurityTokenHandlerCollectionManager.CreateDefaultSecurityTokenHandlerCollectionManager()));
    }

ピー！

于 2012-03-13T01:55:24.520 に答える