使用Windows凭据和.NET 4.5 WIF RequestSecurityToken [英] RequestSecurityToken using windows credentials and .net 4.5 WIF

问题描述

任何点都可以品尝code使用的NT凭据积极发出RequestSecurityToken的作为Thread.CurrentPrincipal中ClaimsPrincipal ？

Can anyone point to sample code for actively issuing a RequestSecurityToken using the NT credentials of the Thread.CurrentPrincipal as ClaimsPrincipal?

该方案是启用了Windows身份验证一个asp.net web应用程序（所以没有通过身份验证的WindowsIdentity）。我的愿望是要积极调用STS而不是启用passiveRedirect，并使用.NET 4.5身份库来做到这一点。

The scenario is an asp.net web app with windows authentication enabled (so there is an authenticated WindowsIdentity). My desire is to call the STS actively rather than enabling passiveRedirect, and to do this using the .Net 4.5 identity libraries.

大多数code的样品，如<一个href=\"http://blogs.objectsharp.com/post/2011/03/04/Claims-Authentication-Helper-Class-for-the-Windows-Phone-7.aspx\">Claims助手Windows Phone的或<一个href=\"http://koenwillemse.word$p$pss.com/2010/08/02/making-a-web-application-use-an-active-sts/\">Using主动STS 使用用户名/密码的输入和UserNameWSTrustBinding设置凭据。

Most code samples, such as Claims Helper for Windows Phone or Using an Active STS set the credentials with a username/pwd input and UserNameWSTrustBinding.

我以为解决方案可能涉及假冒或通话channelFactory.CreateChannelWithActAsToken（）从窗户身份创建的令牌。

I thought the solution might involve impersonation or a call to channelFactory.CreateChannelWithActAsToken() with the a token created from the windows identity.

- 以下.Net4.5 code确实得到GenericXmlSecurityToken撞上/ ADFS /服务/信赖/ 13 / windowsmixed端点时。
不过，索赔的域帐户下该网站正在运行，而不是域帐户验证用户​​。当我切换端点/ ADFS /服务/信赖/ 13 / kerberossmixed，我得到在几个问题和论坛记录不能谈判的错误，但我不能与.NET 4.5的应用提供的解决方案。人们不从Microsoft.IdentityModel移植过类是KerberosWSTrustBinding ...

-- The following .Net4.5 code does get a GenericXmlSecurityToken when hitting an /adfs/services/trust/13/windowsmixed endpoint. However, the claims are for the domain account under which the site is running, and not the domain account of the authenticated user. When I switch the endpoint to /adfs/services/trust/13/kerberossmixed, I get "cannot negotiate" errors as documented in several questions and forums, but I cannot apply any offered solutions with .Net 4.5. One of the classes not ported over from Microsoft.IdentityModel is the KerberosWSTrustBinding...

public static void CallSts()
{
    try
    {
        var wsMod = FederatedAuthentication.WSFederationAuthenticationModule;
        var appliesToEp = new EndpointReference(wsMod.Realm);
        var stsEp = new EndpointAddress(new Uri(wsMod.Issuer), EndpointIdentity.CreateSpnIdentity("stsSpn"));

        var msgBinding = new WS2007HttpBinding(SecurityMode.TransportWithMessageCredential, false);
        msgBinding.Security.Message.EstablishSecurityContext = false;
        msgBinding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;

        using(var factory = new WSTrustChannelFactory(msgBinding, stsEp))
        {
            factory.Credentials.SupportInteractive = false;
            factory.TrustVersion = TrustVersion.WSTrust13;

            var myRst = new RequestSecurityToken
            {
                RequestType = RequestTypes.Issue,
                AppliesTo = appliesToEp,
                KeyType = KeyTypes.Bearer,
            };
                var channel = factory.CreateChannel();
                var stsToken = channel.Issue(myRst) as GenericXmlSecurityToken;

                if(stsToken != null)
                {
                    Log.DebugFormat("Reply Token is {0}", stsToken.GetType().Name);

                    var handlers = FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers;
                    var token = handlers.ReadToken(new XmlTextReader(new StringReader(stsToken.TokenXml.OuterXml)));
                    var identity = handlers.ValidateToken(token).First();
                    //TODO write to session
                }
                else
                {
                    Log.Debug("Reply Token is null.");
                }
        }
    }
    catch(Exception ex)
    {
        Log.Error("Rst.Call has failed", ex);
    }
}

有关@leastprivilege建议，我添加此code：

For @leastprivilege suggestion, I add this code:

    var user = Thread.CurrentPrincipal as ClaimsPrincipal;
var winId = user.Identity as WindowsIdentity;
if(winId != null)
{
    // shows my domain account after I was prompted for credentials;
    // my domain account does not exist on the client machine, so it is a true domain credential
    Log.DebugFormat("WindowsIdentity Name is {0}", winId.Name);
}
using(winId.Impersonate())
{
    // again, shows my domain account
    Log.DebugFormat("Impersonation Context {0}", WindowsIdentity.GetCurrent(true).Name);
    var channel = factory.CreateChannel();
    var stsToken = channel.Issue(myRst) as GenericXmlSecurityToken;
    // request is issued, but results in SecurityNegotiationException: The caller was not authenticated by the service.
}

哪个失败，该呼叫者不是由服务认证。同样的STS将验证处于被动的情况下重定向我的域帐户...所以虽然我知道我做错了什么，该帐户本身应该得到认可。

Which fails with "The caller was not authenticated by the service". The same STS will authenticate my domain account in a passive redirect scenario...so although I know I am doing something wrong, the account itself should be recognized.

更新：

我收到通知，这个问题收到的意见数量显着，所以我会提供以下为一体的解决方法：
虽然我们配置了服务器的授权（如多米尼克以下建议），我们仍然没有超越双跃点的问题。如果我没记错，我们打一个路障，从简单的网络管理策略，我们上面的本地IT即任何企业会打为好。
因此，虽然模仿对着使用Windows身份验证服务器的双跃点是不允许的，凭据可模拟在使用基本身份验证双跳。这可能是也可能不是一个可接受的情况（内联网为我们的情况下）。如果你这样做，你想补充

I received a notification that this question received a notable number of views, so I will offer the following as one workaround: Although we configured our servers for delegation (as Dominick suggested below), we still did not surmount the double-hop issue. If I remember, we hit a roadblock from simple network management policies above our local IT that any enterprise might hit as well. So, while impersonating over a double-hop against a server with Windows Authentication is not allowed, credentials can be impersonated over a double hop using Basic Authentication. This may or may not be an acceptable situation (intranet for our case). If you do, you would add

msgBinding.Security.Message.NegotiateServiceCredential = true;

以上ChannelBinding配置。

to the above ChannelBinding configuration.

推荐答案

好了 - 这其实是不平凡的。你需要做的Kerberos的模拟和委派。

Well - This is actually not trivial. You need to do Kerberos impersonation and delegation for that.

所有模拟的第一位。你需要调用模拟（）上的WindowsIdentity你得到Thread.CurrentPrincipal中

First of all impersonation. You need to call Impersonate() on the WindowsIdentity you get from Thread.CurrentPrincipal.

您可以确保您拨打WindowsIdentity.GetCurrent冒充。这个身份必须指向客户机随后（相对于服务器标识）。

You can make sure you are impersonating by calling WindowsIdentity.GetCurrent. This identity must point to the client then (as opposed to the server identity).

然后冒充而你需要做的WS-信任请求。这是最有可能默认不允许的。所以，你的网络管理员需要为断绝身份到STS配置委派。

Then while impersonating you need to make the WS-Trust request. This is most probably not allowed by default. So you network admin needs to configure delegation for the sever identity to the STS.

这篇关于使用Windows凭据和.NET 4.5 WIF RequestSecurityToken的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！