标签: thinktecture-ident-server

从授权服务器检索访问令牌后,在AngularJS中存储访问令牌的最佳做法是什么？我已经看到很多使用localStorage服务的建议,但后来我读过其他帖子/博客说永远不会使用localStorage来存储令牌,它不安全等等.

由于上面的混合信息,我很难用Angular包围安全性.

我正在使用Identity Server 3作为我正在构建的.Net MVC Web应用程序的中央身份验证服务器.

我已将身份验证服务器配置为使用Open ID Connect身份提供程序,以允许用户使用混合流程对多租户Azure Active Directory帐户进行身份验证.

目前,登录按预期工作,我的客户端应用程序重定向到身份验证服务器,然后身份验证服务器重定向到Microsoft进行登录,然后返回到具有正确填充的访问令牌的客户端应用程序.

但是,当我尝试注销时,我被正确地重定向到Microsoft,但页面在返回到身份验证服务器时停止,而不是继续返回到我的客户端应用程序.

我相信我已按照此处的说明正确设置了帖子注销重定向,我认为我的所有设置都可以.

当我下载Identity Server 3代码并对其进行调试时,它正确设置signOutMessageId到查询字符串上,但在UseAutofacMiddleware尝试重定向到我的映射signoutcallback位置时,在方法内部遇到以下错误:

抛出异常:mscorlib.dll中的"System.InvalidOperationException"

附加信息:已发送标头

我的验证服务器设置:

app.Map("identity", idsrvApp => {
    var idSvrFactory = new IdentityServerServiceFactory();

    var options = new IdentityServerOptions
    {                
        SiteName = "Site Name",
        SigningCertificate = <Certificate>,
        Factory = idSvrFactory,
        AuthenticationOptions = new AuthenticationOptions
        {
            IdentityProviders = ConfigureIdentityProviders,
            EnablePostSignOutAutoRedirect = true,
            PostSignOutAutoRedirectDelay = 3
        }
    };
    idsrvApp.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
    idsrvApp.UseIdentityServer(options);

    idsrvApp.Map("/signoutcallback", cb => { …

我在依赖方应用程序中实现了滑动会话,如WIF 4.5的滑动会话中所述.尽管这样做很有效,但是有一个问题似乎没有人谈论过.

正如链接的博客文章指出的那样,当RP令牌到期时,下次发出请求时,将从STS重新发出令牌.当然,假设STS会话的生命周期比RP的会话生存期长,如果你正在实现滑动会话,几乎可以肯定.

无论如何,这完全打败了滑动会话的全部要点.

似乎没有人在谈论RP会话到期时该怎么做.我想要的是,如果RP会话超时(通常是因为有人离开他的桌子10分钟),我的应用程序是否会重定向到用户可以重新进行身份验证的STS登录页面,然后被重定向回我要求的页面; 或者也许是我提出请求时我所在的页面.

我几乎可以肯定这是可能的,但我完全不知道它是如何完成的.

这是我在global.asax中的代码:

    private const int InactivityTimeout = 5; // minutes

    void SessionAuthenticationModule_SessionSecurityTokenReceived
        (object sender, SessionSecurityTokenReceivedEventArgs e)
    {
        var now = DateTime.UtcNow;
        var validFrom = e.SessionToken.ValidFrom;
        var validTo = e.SessionToken.ValidTo;
        double halfSpan = (validTo - validFrom).TotalMinutes/2;
        if (validFrom.AddMinutes(halfSpan) < now && now < validTo)
        {
            // add more time
            var sam = sender as SessionAuthenticationModule;

            e.SessionToken = sam.CreateSessionSecurityToken(
                e.SessionToken.ClaimsPrincipal,
                e.SessionToken.Context,
                now,
                now.AddMinutes(InactivityTimeout),
                e.SessionToken.IsPersistent);
            e.ReissueCookie = true;
        }
        else
        {
            // re-authenticate …

我声称使用Thinktecture Identity Server设置MVC网站.我现在要求允许第三方访问网站的某些部分.

是否可以通过编程方式向Identity Server进行身份验证并将其发布到网站,以便第三方的用户不需要手动完成正常的登录过程？

我之前使用身份服务器获取SAML令牌以进行WCF调用,我想知道是否可以重用这种方法？

由于第三方使用基于桌面的Java应用程序并且内置了一些浏览器组件来访问MVC网站,因此出现了复杂情况.用户已经使用桌面应用进行了身份验证,因此我们不希望他们再次输入凭据来查看这些网页.

我有一个SaaS Web应用程序,可以满足多个教育机构的需求.所有客户端都托管在同一个应用程序/数据库中.该应用程序目前用C#编写,用于ASP.Net 4 Web窗体.

目前,我的应用程序使用本地/本机数据库进行用户身份验证/授权

我们的客户要求我们支持单点登录,其中客户端是身份验证提供者,而我的应用程序是消费者.

问题是客户端通过不同的协议/机制(如Shibboleth和OpenID Connect)要求SSO.这意味着我需要/应该创建一个适用于所有这些或至少可扩展的解决方案.

我遇到了Thinktecture的IdentityServer,我认为它可以抽象出我的客户使用的各种SSO机制,并将我的应用理解的基于声明的身份令牌返回给我的应用程序.

尽管我对这个概念感到苦苦挣扎.这是否意味着我的应用程序将所有身份验证请求重定向到IdentityServer,让IdentityServer来回处理OpenID Connect,然后从IdentityServer接收一个令牌以获取有关用户的信息？身份服务器如何知道用户的领域(即,它知道哪个客户端身份验证提供程序将用户发送到)？IdentityServer是否需要在我的应用程序的本地/本机数据库中验证用户的存在？IdentityServer可以同时处理SSO和本地登录吗？

是一个单独的身份服务器的方式去？看起来好像是,允许我的应用程序与一个点(身份服务器)集成.但是,Thinktecture的IdentityServer上没有很多文档,除了如何配置它.ADFS可能会提供类似的解决方案,但大多数示例都与ADFS和Azure有关.

最后,我假设我仍然会维护有关每个用户的本地/本机授权数据,因为第三方身份验证提供程序不可能知道我的应用程序的特定授权需求.

有什么想法或建议吗？

我正在尝试创建一个AngularJs Web,它将登录名和密码发送到ASP.NET WebApi后端,并使用Thinktecture登录该用户.

我使用WS-Federation让Thinktecture与其他项目ASP.NET MVC一起正常工作.现在我正在尝试做类似的事情,但改变一些组件,我不能让它工作.

如何从ASP.NET WebApi将用户名和密码发送到Thinktecture并验证它？

using System.Collections.Generic;
using System.IdentityModel.Services;
using System.Web.Http;
using WebApi_AngularJs.Model;

namespace WebApi_AngularJs.Controllers
{
    public class AuthorizationController : ApiController
    {    
        // POST: api/Authorization
        public LoginResponse Post([FromBody]Login data)
        {
            //HOW TO SEND data.user and data.password to ThinkTecture and get
            //response if user valid or not??
            var response = new LoginResponse { access_token = "token", data = "data"};
            return response;
        }   

    }
}

谢谢!

摘要

在SAML中,存在IdP启动登录的概念,这意味着识别方(IdP)可以向依赖方(RP /消费应用程序)发送未经请求的令牌,并且用户可以登录而无需呼叫IdP .我有一个场景,我需要这样做,但我希望ThinkTecture Identity Server v3处于中间位置,因为我将在那里处理我的正常身份验证(如在非SAML日常工作中).由于我无法控制的原因,我无法打电话给SAML IdP.我想做的是:

我花了很多时间看这个,我也查看了从第三方开始登录的规范,但如果我理解正确,它仍然从第三方开始指导用户到RP然后,它向IdP(可能是ThinkTecture身份服务器)发送登录请求,这不是我真正需要的.

总之,我认为OpenID Connect不具备SAML的IdP发起的SSO.这是正确的还是我无法弄明白,或者ThinkTecture IdentityServer不支持它？

更多细节

• 我已成功使用KentorIT的AuthServices OWIN中间件将IdP启动的SAML SSO直接实现到网站中,而不是完全使用IdSrv.
• 我还将Kentor的OWIN中间件与IdSrv集成,以便我的网站重定向到IdSrv,然后重定向到我登录的SAML服务器,返回IdSrv,然后转换SAML令牌并将OpenID身份令牌发送回我的网站.
• 为了好玩,我还使用了Kentor的库来获得一个解压缩SAML令牌的MVC控制器,所以如果我想要我可以用它做一些手动认证.

这一切都很有效,非常感谢ThinkTecture和KentorIT.唉,这一切仍然从我的网站开始,最终导致重定向到SAML服务器,由于非技术原因,我无法在我的方案中做到这一点.

替代方案

在这种情况下,我当然可以完全免除IdSrv,但我有理由让IdSrv处于中间位置,并通过我的所有身份验证.所以我现在的想法是做这个流程:

1. SAML服务器将SAML令牌发送到我网站上的特定URL.
2. 我的网站将按原样将该令牌重新发布到Identity Server.Identity Server已经安装了KentorIT OWIN中间件,因此只需将用户登录到IdSrv,这意味着IdSrv会设置一个auth cookie.
3. IdSrv执行简单的重定向回到我网站上的另一个URL,并且不包含任何令牌.到目前为止,这与IdSrv无关.
4. 我的网站现在向IdSrv发出身份验证请求
5. 由于用户已登录到IdSrv,因此IdSrv将立即响应并使用身份令牌将用户重定向回我的网站 这是很多重定向,但它应该工作.

在我开始实施它之前,有人能告诉我这是否是正确的方法,或者我错过了一些非常明显的东西？

编辑1

看起来这个想法也不起作用.基本上我需要做的是使用IdP启动的SAML SSO向Identity Server进行身份验证,然后重定向到RP并使用身份验证请求将RP重定向到Identity Server.但是,据我所知,除非作为RP请求的一部分,否则无法让Identity Server登录.换句话说,即使我的SAML中间件很乐意接受未经请求的令牌,IdSrv也会忽略SAML中间件请求将其登录(我认为这是公平的).

因此,我认为另一种解决方案是编写一个控制器,该控制器可以验证SAML令牌并直接在同一服务器上运行的代码中调用IdSrv ,并告诉它使用我手动构造的主体来记录用户.

(新)问题是,Identity Server是否公开了一种机制,让我在代码中记录用户,以便Identity Server为用户设置适当的cookie？

我正在尝试遵循简单的指南mvcGettingStarted.现在,我已经实现了两者GoogleAuthentication和FacebookAuthentication提供者,一切都按预期工作,我实际上可以登录,如果我使用我的身份服务器登录,我还获得了每个用户的角色声明.我想知道,如果我想保留外部提供商提供的所有索赔怎么办？简单的例子.这就是我的Facebook提供商设置的样子:

var facebookOptions = new FacebookAuthenticationOptions() {
            AuthenticationType = "Facebook",
            Caption = "Sign in with Facebook",
            AppId = "*****",
            AppSecret = "****",
            SignInAsAuthenticationType = signInAsType,
            Provider = new FacebookAuthenticationProvider() {
                OnAuthenticated = (context) => {

                    foreach (var x in context.User) {
                        context.Identity.AddClaim(new Claim(x.Key, x.Value.ToString()));
                    }

                    return Task.FromResult(context);
                }
            },
        };

        facebookOptions.Scope.Add("email");
        facebookOptions.Scope.Add("public_profile");
        facebookOptions.Scope.Add("user_friends");

        app.UseFacebookAuthentication(facebookOptions);

在for each循环中,我试图将所有Facebook声明存储在Identity中,但是当我回到SecurityTokenValidated回调中时,我的身份并没有它们.

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions() {
            Authority = "https://localhost:44302/identity/",
            ClientId = "my_client",
            Scope = "openid profile roles email",
            RedirectUri …

我的目标是使用Web服务的Angular应用程序,使用Windows身份验证对应用程序/ Web服务的用户进行身份验证.用户应该能够登录我们的Windows域中的计算机,打开浏览器并使用Angular应用程序而无需再次登录.

研究

我从https://github.com/IdentityServer/IdentityServer3.Samples/下载了所有源代码示例

我使用了最简单的OAuth2演练示例.没问题.

然后我打开了Web Host(Windows Auth All-In-One)示例.在评论出导致问题的两行代码后,我可以恢复和构建项目(Clients.cs行313,359,设置'AllowAccessTokensViaBrowser = false'.可能不相关.)

当应用程序运行时,我可以在localhost:44333上看到IdentityServer3登录页面.大.

我还可以在localhost:44333/windows上看到Windows身份验证服务元数据(SAML文档).还有,很棒.

问题是,我不知道接下来该做什么.本文档似乎建议下一步涉及编写一个调用Windows身份验证服务来获取令牌的客户端:

http://github.com/IdentityServer/IdentityServer3/issues/1463

这是正确的方法吗？我无法使代码示例工作.我甚至不确定我是否可以指向OAuth2Client正确的地方.请有人解释这个过程,或者给我一个工作客户的例子吗？提前谢谢你的帮助:)

编辑

我一直在做进一步的研究.我检查了Identity服务器的日志,以确保在配置期间完成添加WS-Federation端点操作.确实如此.

然后我创建了一个简单的控制台应用程序来调用Windows身份验证服务,如下所示:github.com/IdentityServer/IdentityServer3/issues/2318

导入Thinktecture.IdentityModel.Client后,我修改了该页面上的代码以适应我的端口号等,我最终得到了这个:

   var handler = new HttpClientHandler
   {
       UseDefaultCredentials = true
   };
   var oauthClient = new OAuth2Client(
                    new Uri("https://localhost:44333/windows/token"),
                    handler);

   var result = oauthClient.RequestCustomGrantAsync("windows").Result;

我的结果对象仍然有一个NotFound的HttpErrorStatusCode ,这让我很伤心.

另一个编辑

我尝试将客户端指向Identity Server端点,如Branimir所示.所以我的代码现在写道:

var oauthClient = new OAuth2Client(
   new Uri("https://localhost:44333/connect/token"),
   handler);

这也不起作用.这是Identity Server日志所说的内容:

Start token request …

TL; DR:当IdentityServer3将表单发布到返回URL(始终是根URL)时,MVC应用程序如何知道在经过身份验证过程后重定向到某个操作？

此问题中的示例取自IdentityServer3随附的示例应用程序"MVC身份验证".

将IdentityServer3插入MVC应用程序时,会提供一些客户端信息,包括重定向URL,通常是根URL.因此,当某个操作需要身份验证时,它将重定向到执行身份验证的IDP.之后,有一个表单帖子返回url,如下所示:

POST https://localhost:44319/ HTTP/1.1
Host: localhost:44319
Connection: keep-alive
Content-Length: 2213
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://localhost:44319
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: https://localhost:44319/identity/connect/consent?client_id=mvc&redirect_uri=https%3A%2F%2Flocalhost%3A44319%2F&response_mode=form_post&response_type=id_token%20token&scope=openid%20profile%20roles%20sampleApi&state=OpenIdConnect.AuthenticationProperties%3DAzAv5NequrWeysjiZ6TDUYTh4UQkWPvgTAIQ4RNg6rCzbdNLvQsHNSwRLyJfRuR1Kvn0IbQFrbiJ4hLD3LCTRRK6PZY0eL2uB8BKEioOCou2SUSCpDTG-dkSk-0SqkOc_17_x0yFjB171-VoGfTPYzBxbd-JkFWrEQQ2_fRP4mvbw7Uo7vo9Udu9c_u2nxL_R8LYc9kS5t8iuNt4Ydbxdw&nonce=635757605373442818.ZDBkNGNkMjgtYzBkNS00OGVjLTg0MzMtNGJjMjdmODRjMDYzN2M4MmE0ZjMtMzM4YS00YzA1LTgwYzEtYmNiODFiZjdiNjZm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: OpenIdConnect.nonce.OpenIdConnect=el9COXpSbS1PWmdPbW9oUHNTcEFfLUxkVklJQ3lPUzJsYkpTbU1NcXlfZ0JMMlVDWW9BVnowNEpNZDVNUTgyWG9lZ3hiQ3FlUXY1dUJmdmdhMHhzNkRZSnBIcmZoeHFGR214Qmt6cHl6a0lJc2NiTUJPRk1yeWduX3hoODBGaC1fMnZWbXZUajRjX2pEQ1gtMkJ2SDcyTXhRZjVVeHNoUzV2SVRlbXRPWk9iNWtRdHJfdU8weVNHQVZnQTNBSUVZelNMcFB6ZDZuT09kcW40RU9COUN1NW1TbklqMnR4MWl6NEtOcExDaVMtTQ%3D%3D

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSIsImtpZCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSJ9.eyJub25jZSI6IjYzNTc1NzYwNTM3MzQ0MjgxOC5aREJrTkdOa01qZ3RZekJrTlMwME9HVmpMVGcwTXpNdE5HSmpNamRtT0RSak1EWXpOMk00TW1FMFpqTXRNek00WVMwMFl6QTFMVGd3WXpFdFltTmlPREZpWmpkaU5qWm0iLCJpYXQiOjE0NDAxNjM3NTIsImF0X2hhc2giOiJNTlRZTmtMVDhhY2NtcTdWQVJvOThnIiwic3ViIjoiMSIsImFtciI6InBhc3N3b3JkIiwiYXV0aF90aW1lIjoxNDQwMTYzNzQ5LCJpZHAiOiJpZHNydiIsImlzcyI6Imh0dHBzOi8vbG9jYWxob3N0OjQ0MzE5L2lkZW50aXR5IiwiYXVkIjoibXZjIiwiZXhwIjoxNDQwMTY0MDUyLCJuYmYiOjE0NDAxNjM3NTJ9.EgM5TogdDx3o25Otw9VVgXBzWQfzwt3s9pu4YmajNgiVh4ujj4eg2klrti7YDkd7jdxawNdogewc1ajxYR-r4TAxg3Brd3c8kFSCfXhEsr3DLakbYkWA8CaBJTqnVUnq_jadzUX4OkW9VPfLWlqkl0qRazogH06MAFVyge8k8PgGdf1Zk4RaRoX7bPyZ95ULivuXBt4aySQCVMS_GC03VxQksw3h3O-hzsJvm73OKKSo_wOikzsiozOkkA5sOZrVHGl7vQbLtsDTsMxXSLg6n-Kf4gySwskfAc-5okjgjBjjBm3OuzsaspHBZC2mlchaD_tllA0LHooi9Lna0REY7Q&access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSIsImtpZCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSJ9.eyJjbGllbnRfaWQiOiJtdmMiLCJzY29wZSI6WyJvcGVuaWQiLCJwcm9maWxlIiwicm9sZXMiLCJzYW1wbGVBcGkiXSwic3ViIjoiMSIsImFtciI6InBhc3N3b3JkIiwiYXV0aF90aW1lIjoxNDQwMTYzNzQ5LCJpZHAiOiJpZHNydiIsInJvbGUiOlsiR2VlayIsIkZvbyJdLCJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo0NDMxOS9pZGVudGl0eSIsImF1ZCI6Imh0dHBzOi8vbG9jYWxob3N0OjQ0MzE5L2lkZW50aXR5L3Jlc291cmNlcyIsImV4cCI6MTQ0MDE2NzM1MiwibmJmIjoxNDQwMTYzNzUyfQ.nDSz4uQcyW6deZDxU2BXRjd5nKlMhbgbilEpD_yLhtbxg91N0DpNBOqVDmt4JbaOAKP9gIMDpaE8ZQR-NLQVtyKzNL8JuYLngmKrQPJJ-GM75qthpGIj72y8fo-OvOoiKEa3zQdbYjfVuSaQxmDiQ4mK4COSrvkB4SyIlEhvkMHFCrJFoktuhgpZl-jNe1ISGB6aDgZO2YTMo5LbVwBx0GS90cP0dMi8uCrDxql84P8Wg7_XTMkMYuVYeyYoukeNoaALBfWiCehOsdECQYZEMtaFTn47qaxvEpECdKaekoMCeJvqavGqpkCmRc-IK6Y3_qgtedibOhHTAIsbrpWzeg&token_type=Bearer&expires_in=3600&scope=openid+profile+roles+sampleApi&state=OpenIdConnect.AuthenticationProperties%3DAzAv5NequrWeysjiZ6TDUYTh4UQkWPvgTAIQ4RNg6rCzbdNLvQsHNSwRLyJfRuR1Kvn0IbQFrbiJ4hLD3LCTRRK6PZY0eL2uB8BKEioOCou2SUSCpDTG-dkSk-0SqkOc_17_x0yFjB171-VoGfTPYzBxbd-JkFWrEQQ2_fRP4mvbw7Uo7vo9Udu9c_u2nxL_R8LYc9kS5t8iuNt4Ydbxdw&session_state=9WBSt6Ko4espJ13yDbna9KIFe5kH8T4r8XtqeyoiIbA.ceb624206fccd4d72d79b53949693b3c

此特定请求将导致302重定向到MVC应用程序中的/ Home/Contact

HTTP/1.1 302 Found
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Location: https://localhost:44319/Home/Contact
Server: Microsoft-IIS/8.0
Set-Cookie: OpenIdConnect.nonce.OpenIdConnect=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
Set-Cookie: .AspNet.Cookies=JTvNM4i1jqb21SRYih59M2T1dPrbreQAXZ5d8DRlQmQf4vH-3r6wKxOABocffMC7tDSXFbqydxyllXZChSRvlrzaUmVkrZoCuoENMzBukchjdRxsnJLCV9pf3PCJsXCBOj_b8bLLDioqaKSOOSbBgAHdHplVEdBpcmt2EDcwDfWpTsiRlhn03pd4-nKc22OA-qZuGCEenG3OlDzMitCdbufgW7p2Z1rZ0WpSv70O_DFKdcP0zvGB8nm5YazpUPGthn3f-B5u7YpeCrLTifesKFBQz4hmsczbzKI2_NUJDEw-WqUucVN4DCLaSngoRrnR-PS0xB4PqgNt39nPD2KeaiQzmTf0kBNMsqSjspOWWNpUqYzFB3zstxPipRvCG4dUOPfqnrqJwyNuDxDCe15yFpcjmvqDaXjLnXQO_-3OfxlOjxG2VDqJXo6ZufimKiKfPxm5jINPvZ_ci__ZGOeRvulFex0bZk6DD8ZgOxBuTPtW7dSqypv-h-M817MIO5Su3AITbq3tznAY_nZwo7bkfQiGmciE5BNHVPfWtBo3bSPLNBr0ZoKsgVGUfRoRBoY-dndiNTZftZNysfsEcod5aDInZvlQSv1cJpShJqdZEJA6VeIe9JUpWgDzKikDYFWsUJ3bXTNrv28aC_XJjuVyyEXH3onVrpoyvB1QD9BGQ9FKERvNf3xMV9jr_aMgJvf-Q3rdmmlPadQnvvy4S0_kYaTt69dtgJL_HIjyKPduqCAnwjWkksIIHsONU07JgClcS3C9oHwb0iUUWzk7MmgLWHP1S6GQCOUIIgxgTOUdNf8DnC6Zzthbhfev92QymQ8vQxrFIgF-ImK0TjHnJdijJBTzbRJSBdVdi-lUalDlzsO0pgePzKL3fYfQcyHKMqG9_eQ-rgo7lVYwWY10WT3ZMNawVQmIQoIIJ5AXH4RLu0tUnuzxOk-alJukEE8Z8n1k6IIcfPul50skTv2B7rrsZfJZRCJu3_zZZ6WvgRAuFvhtLVFEgCVLX5_b_9Q7kIk-ZB_j1iJ9pUe29P1SFUVC1i9Sl41RbeAQN0v7NzQ9SM2S49-4xZ7C5CkYl8_5XxhUwc4Gh0EC9-AuXRBzAQKx3UjUhwUsEfibloxVz9fdz79-ouRadNPovlII-WU9MuL6_iyijROyWzAiKYiAR800pHbmPxAZQjQ6QYt1fj-M-bckDzyI8hX4ZhKxn3Gin5mzlGCJWe2dL5sInOq5tTz2fvPP24JxuHCjASalAqDl4j-QmiL0KlNXwzL7ttXlX9dEB9ptYA50b9Wr9h8Y-HbdZW8Zs5HMRZV763z5uEL613ZCbBZuDuhgz8_y5rHkQtpDrVU8xjtyRhpB2WdMaxKBWEXO-Qw5CZR5IkXbfGJ84k6F3TH3f4IkEhVPhAwinsphht1TQnibkxRpv0xP2Zn9VLZ0lTvWL5-T9gFCNru25wl7otoDFlFqWwyQcXwjKpRgrZIH3ebbqw86iIY1DavOPEWZBe1h8HQN8OroMNgYPWiB9G1nKrIj0ZQHxaaKCHkso4IMnnPe30kXjeGoA83kSQCN8z8iVdamqoem7zHt1RfRIwQNii8cy_MPZ_He0F1p8xdjiyGzJkjGpGk0xxCAD_T_pa7rcIHtLGgi9VfP_oQy_VWqaua9pRMObuczC9mj9MTEK-mQQvWEiewHK0ioMu4yxbN22OPSRKrEbmSzF3-P4lLMgQo8MXnMGJ7CeeZuXZ4nu8qAaWIOS1jGbCNXbZWDZ5GBmB-VTn_jqR_tjvO1_p011alg7g0rCtgjnlYaO1wYtDILx79sPwvxeVOOWefVR7TkTQ__3ZFn6z4NISg4CJ9eKDTd3y7Q8eKo4_i3jljxXGhpwXyCFL2Ks2TzGQ6BWv7R9kXAbDCTGBq-PG_eUppkM1o8VUaXmQ8SQoLxA8rlgR54hO1CHPqe8fR9st_DRsk42cjn-ftsOvX63-8FxkzivIiIyaUW7y0V7HEIFuBJDGZHj_TJCK69xVLyu0KwsxhraXlQF5jhAOm5AnrPa-jQMNxdc65yj1H95nFM6SjZeCVfdMs5W_unD3WI2Q; path=/; secure; HttpOnly
X-SourceFiles: =?UTF-8?B?QzpcRGV2XElkU3J2U2FtcGxlc1xzb3VyY2VcTVZDIEF1dGhlbnRpY2F0aW9uXEVtYmVkZGVkTXZj?=
X-Powered-By: ASP.NET
Date: …