Simple web forms cookies and openid connect

Assume things are as they once were (before things like ASP.NET identity came along). That is, you want a simple web forms site with a logon page (that sets cookies based on validating a couple of form field values), and optionally another page open to anyone that can induce an opened connect handshake with an IDP … whose grant types ultimately induce the site to create the same kind of cookie as was produced by the local logon page.

Here is what we learned to do (not that its perfect).

In owin startup class:

using System;
using System.Threading.Tasks;
using Microsoft.Owin;
using Owin;
using System.Web;
using System.IO;
using Microsoft.Owin.Extensions;
using Microsoft.Owin.Security;
using Microsoft.Owin.Security.Cookies;
using Microsoft.Owin.Security.OpenIdConnect;
using System.IdentityModel.Tokens;
using System.Security.Claims;

[assembly: OwinStartup(typeof(WebApplication2.Startup1))]

namespace WebApplication2
    public class Startup1

        public void Configuration(IAppBuilder app)

            app.UseCookieAuthentication(new CookieAuthenticationOptions
                AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
                LoginPath = new PathString("/SSOLogon.aspx"),
                CookieName = ".ASPX_AUTH_COOKIE",
                SlidingExpiration = true,
                ExpireTimeSpan = new TimeSpan(0, 90, 0)

                new OpenIdConnectAuthenticationOptions
                    ClientId = "2452697f-d1c2-431d-98ae-f93353f04f2e",
                    Authority = "",
                    SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType,

                    TokenValidationParameters = new TokenValidationParameters
                        IssuerValidator = (issuer, token, parameters) =>
                            return issuer;
                    Notifications = new OpenIdConnectAuthenticationNotifications()
                        RedirectToIdentityProvider = (context) =>
                            string appBaseUrl = context.Request.Scheme + "://" + context.Request.Host + context.Request.PathBase;
                            context.ProtocolMessage.RedirectUri = appBaseUrl;
                            return Task.FromResult(0);
                        SecurityTokenValidated = (context) =>
                          ClaimsIdentity t = context.AuthenticationTicket.Identity;

                          t.AddClaims(new[] {
                                new Claim("authnContext", "UserAuthenticated"),
                                new Claim("RapAuthnContext", "UserAuthenticated")
                          return Task.FromResult(0);

            app.Use((context, next) =>
                PrintCurrentIntegratedPipelineStage(context, "3rd MW");
                return next.Invoke();


        private void PrintCurrentIntegratedPipelineStage(IOwinContext context, string msg)
            var currentIntegratedpipelineStage = HttpContext.Current.CurrentNotification;
                "Current IIS event: " + currentIntegratedpipelineStage
                + " Msg: " + msg);


Note the use of SignInAsAuthenticationType. This says, mint the claimsidentity resulting from the openid connect handshake so that its treated as if the result of presenting the cookie. In this way, we are “injecting” the result into the cookie handling process, just as if we had minted it locally using a local login page.

Now the urlauthorization module of partially works, in the sense that a page resource tagged with “deny ?” (deny anonymous users) can intercept an authenticated claims principal.

What urlauthz does not do, despite issuing a 401, is invoke the own pipeline to issue an opened connect request (even if it is marked active, uniquely). It will, alternatively and when the cookie module is given a login property that redirect unauthenticated users go to the local page, do said redirect … to the login page that might itself have code to issue the session cookie.



Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in coding theory. Bookmark the permalink.