标签: wif

我正在玩Windows身份基础,我正在尝试创建一个基于MVC.NET的安全令牌服务,并将其用作单点登录应用程序.

我唯一的问题是我不知道如何生成federationmetadata.xml文件.

有手动生成此文件的工具吗？

我有一个WCF服务,需要由单独的WCF STS服务发出的安全令牌.这一切都只是花花公子.在我的应用程序中,我使用这样的服务:

MyServiceClient myService = new MyServiceClient();
myService.Open();
myService.DoStuff();

调用STS服务获取令牌,令牌用于调用服务方法DoStuff.

但是,一旦初始握手结束,myService对象就会缓存令牌并重新使用它直到它到期为止.这是很好的行为,但是如何强制它刷新令牌呢？

myService.ClientCredentials.Invalidate(); // something like this?

这样,如果我再次调用DoStuff(),它就会知道它需要再次像第一次那样再次进入STS.

我只是制作一个新的代理类对象,即myService = new MyServiceClient();？这有效,但它似乎是核弹解决方案.

或者,有没有办法只手动获取一个新令牌并替换当前的令牌,即myService.ClientCredentials.Renew();？

如果我必须创建一个自定义ClientCredentials类来执行此操作,我将如何实现上面的示例方法？

我正在尝试创建我们自己的WIF身份提供程序并在Azure上运行它,但在尝试自动生成联合元数据时我正在努力.

此行似乎不适用于Azure:

CertificateUtil.GetCertificate(StoreName.My, StoreLocation.LocalMachine, signingCertificateName);

证书上传到Azure,我该如何获取它？

谢谢

考虑使用访问控制服务(ACS)和Windows Identity Foundation(WIF)来保护我的WCF数据服务Web API应用程序.

如何使用声明来唯一标识用户？

我的想法是使用标准声明NameIdentifier和WIF声明IdentityProvider的组合来为任何用户创建唯一ID.

这个组合真的稳定而独特吗？IP会突然改变它的IdentityProvider字符串吗？

这里的想法是将两半的连接字符串存储为任何用户的唯一ID.

NameIdentifier声明是否有任何安全隐患？

干杯,

M.

我正在尝试在ASP.NET MVC应用程序中设置身份验证,如果是这样,请使用Azure访问控制服务(ACS)(2011年5月发布).我已经使用默认设置了.但是这里存在可用性问题.

当我使用我的Google帐户进行身份验证时...... Google说.. mydomain.accesscontrol.windows.net正在请求访问该帐户.这可能会让最终用户感到困惑,因为他们期望使用login.mydomain.com.

我指着一个DNS CNAME记录来自login.mydomain.com于mydomain.accesscontrol.windows.net并上传一个X.509证书login.mydomain.com通过访问控制服务控制面板.但是当我尝试访问https://login.mydomain.com时出现服务器错误,因为发送到浏览器的证书是*.accesscontrol.windows.net.NB.我无法看到Azure ACS服务器上的错误.

有没有人在这里设法成功为ACS设置自定义域,并可以建议如何做到这一点？似乎可以使用角色和存储帐户,但我找不到有关AppFabric服务组的任何文档.

我一直在使用WIF来验证我们的新网站,STS基于starter-sts实现.

为了使其在负载均衡环境中正常工作,我在global.asax中使用了以下内容来覆盖默认的证书行为.

void onServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
        {
            List<CookieTransform> sessionTransforms = new List<CookieTransform>(new CookieTransform[] 
            { 
                new DeflateCookieTransform(), 
                new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
                new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)
            });

            SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
            e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
        }

这一切都正常工作,人们已成功使用该系统,但不时我们得到一个爆炸:

ID1014:签名无效.数据可能已被篡改.

在事件日志中,所以我打开了WIF跟踪,并在日志中看到了以下提到的内容.

ID1074:尝试使用ProtectedData API加密cookie时发生CryptographicException(有关详细信息,请参阅内部异常).如果您使用的是IIS 7.5,则可能是由于应用程序池上的loadUserProfile设置被设置为false.

我有一种感觉,正如我想的那样,这导致我走入一条黑暗的小巷,因为我改变了使用RSA的实现,这不应该影响我.

有什么想法可以帮到我吗？

我已经阅读过MSDN论坛,Dominic Baier的博客,以及其他来源,DPAPI不​​会在Azure中开箱即用,并且在任何类型的Web场景中处理联合身份验证的一种方法是替换DPAPI转换使用可在整个服务器场中使用的私钥的服务器,例如使用X509证书的RSA加密.我在Azure MVC应用程序中采用了这种方法并配置SessionSecurityTokenHandler如下:

FederatedAuthentication.ServiceConfigurationCreated += (sender, args) =>
    {
        var sessionTransforms = new List<CookieTransform>(new CookieTransform[]
            {
                new DeflateCookieTransform(),
                new RsaEncryptionCookieTransform(args.ServiceConfiguration.ServiceCertificate),
                new RsaSignatureCookieTransform(args.ServiceConfiguration.ServiceCertificate)
            });
        var sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
        args.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);                    
    };

使用此配置,我们能够从身份提供商处接收令牌,并发布使用这些转换加密的安全cookie.在Azure模拟器中运行,一切都按预期工作.但是,在Azure环境中,我们间歇性地在浏览器中看到以下错误:

Key not valid for use in specified state.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.Security.Cryptography.CryptographicException: Key not valid for use …

任何人都可以指向使用NT凭据主动发出RequestSecurityToken的示例代码 Thread.CurrentPrincipal as ClaimsPrincipal吗？

该场景是一个启用了Windows身份验证的asp.net Web应用程序(因此有一个经过身份验证的WindowsIdentity).我的愿望是主动调用STS而不是启用passiveRedirect,并使用.Net 4.5身份库执行此操作.

大多数代码示例(例如,用于Windows Phone的Claims Helper或使用Active STS)使用username/pwd输入和UserNameWSTrustBinding设置凭据.

我认为解决方案可能涉及模拟或使用channelFactory.CreateChannelWithActAsToken()从Windows标识创建的令牌调用.

- 当访问/ adfs/services/trust/13/windowsmixed端点时,以下.Net4.5代码确实获得了GenericXmlSecurityToken.但是,声明适用于运行站点的域帐户,而不是经过身份验证的用户的域帐户.当我将端点切换到/ adfs/services/trust/13/kerberossmixed时,我得到了"无法协商"的错误,如几个问题和论坛中所述,但我不能在.Net 4.5中应用任何提供的解决方案.其中一个未从Microsoft.IdentityModel移植过的类是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 …

我正在使用WIF和STS提供商(所有使用开箱即用的Microsoft代码和示例)保护的几个WCF服务.这些服务都是使用.NET 3.5构建的,并且最近都已更新到.NET 4.0.与服务关联的所有 .dll也已更新为4.0.在我更新框架版本之前,这些服务已按原样运行多年.

现在问题是当对由STS WCF服务保护的WCF服务进行调用时,在将令牌传递回调用STS保护的WCF服务的客户端应用程序之后会产生错误:

从另一方收到了无担保或不正确安全的故障.请参阅内部FaultException以获取故障代码和详细信息.

HResult -2146233087

{"在处理邮件中的安全令牌时发生错误."}

服务器堆栈跟踪:在System.ServiceModel.Channels.SecurityChannelFactory 1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory1.SecurityRequestChannel.Request(消息消息,时间跨度超时)在System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation操作,目标的EndpointAddress,经由开放的,SecurityToken currentToken,时间跨度超时) System.ServiceModel处的System.ServiceModel.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan超时)处于System.ServiceModel.Security上的System.ServiceModel.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)的System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan超时) .Channels.CommunicationObject.Open(时间跨度超时)在System.ServiceModel.Channels.ServiceChannel.OnOpen(时间跨度超时)
在System.ServiceModel.Channels.CommunicationObject.Open(时间跨度超时)在System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System .ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel chan NEL,时间跨度超时)在System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(时间跨度超时,CallOnceManager级联)在System.ServiceModel.Channels.ServiceChannel.EnsureOpened(时间跨度超时)在System.ServiceModel.Channels.ServiceChannel.Call(字符串动作,布尔单向,ProxyOperationRuntime操作,对象[]项,在System.ServiceModel.Channels.ServiceChannel.Call(字符串动作,布尔单向,ProxyOperationRuntime操作对象[]奏,时间跨度超时),对象[]项,对象[]奏)在System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage包括methodCall,ProxyOperationRuntime操作)在System.ServiceModel.Channels.ServiceChannelProxy.Invoke(即时聊天消息)

在异常重新抛出[0]:在System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(即时聊天reqMsg,即时聊天retMsg)处MyProject.IMyService System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&MSGDATA,的Int32类型). GetInfo()位于c:\ Projects\Proxy.cs中的MyProject.Proxy.GetInfo():第36行

深入挖掘也表明:

InvalidSecurityToken作为InnerException.Code.Subcode.Name属性值.

所以我看了下面的内容,这些都暗示了系统上的时钟问题,但没有一个有效:

http://blogs.msdn.com/b/dhrubach/archive/2009/12/14/9936037.aspx
从另一方收到了一份不安全或不正确安全的故障.(使用SAML时)
http:// blogs. msdn.com/b/xiaowen/archive/2009/03/26/tip-add-a-clock-skew-to-prevent-some-security-faults.aspx?Redirected=true

我已经在这些服务中附加了调试器并尝试遍历代码,但我找不到罪魁祸首.有谁知道我可能会对此感到错误？

编辑:有趣的是STS服务中WIF 的艰难部分正在进行身份验证工作!我打开了日志记录并捕获了以下内容:

Service authorization succeeded.  
Service: http:// localhost:4068 /MyID/MyID.svc  
Action: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue  
ClientIdentity: Domain\allen; S-1-5-21-1234567890-1234567895-0987654321-45678 
AuthorizationContext: uuid-22fad22a-22fe-123c-9b69-a22c23f569ce-99 
ActivityId: <null>  
ServiceAuthorizationManager: <default>

我还打开了WCF日志记录.config来查看.svc文件,并且它们没有产生任何错误信息,指出了问题.这就像STS说:"嘿,你经过身份验证,我们通过你并生成令牌,现在我们已经完成了!" 看来调用客户端不喜欢令牌.然而,这已经成功了,直到我改变了框架版本.根据我的知识,从3.5 - > 4.0没有任何重大的WIF变化,而是在4.5中将WIF集成到框架中的重大变化.

因此,所有授权都有效,只是客户端认为令牌被接受存在问题？

我正面临着WIF ClaimsAuthenticationManager的一个奇怪问题.我在web.config文件中注册了ClaimsAuthenticationManager的自定义实现:

<identityConfiguration>
  <claimsAuthenticationManager type="<namespace>.CustomClaimsTransformer,<assembly>" />
  <claimsAuthorizationManager type="<namespace>.CustomAuthorisationManager,<assembly>" />
....

当我在IISExpress中运行应用程序时,将调用ClaimsAuthenticationManager的authenticate方法.但是,自从我在IIS 7.5上部署应用程序以来,它一直没有被调用.

是否需要进行任何配置？