Develop Reference

OWIN Produces Different Behavior Between IIS Express and IIS

I'm building a authentication app using OWIN. I'm trying to get both the Bear token and userinfo claims. The code below gets me to 85% of what I want. While initially writing the code I used IIS Express. I debugged and coded towards that environment. For whatever reason after the initial challenge called in the else block the request.isauthenticated is false after the return from the login screen (Using KeyCloak as idp). The code then drops the user into the else if block where I find request.form has my Bearer token. I must then execute the authentication.challenge again (no KeyCloak login screen opens) and I return to the top of the page_load and this time the request.isauthenticated is true and I can get the userinfo but the request.form is empty. This is find for me because I can store all the info off somewhere for later use.
Once I got to this point I targeted IIS. Ran the code and got different behavior. The code drops into the else block initially (same as before) I login but upon return from the idp this time the request.isAuthenticated is true. I have the userinfo but not the Bearer token. Any ideas why??
protected void Page_Load(object sender, EventArgs e)
{
if (Request.IsAuthenticated)
{
String str = String.Empty;
var qry = ((System.Security.Claims.ClaimsPrincipal)Request.RequestContext.HttpContext.User).Claims;
if (null != qry)
{
foreach (System.Security.Claims.Claim item in qry)
{
if (item.Type == "preferred_username")
{
str = item.Value;
}
}
}
}else if (!Request.IsAuthenticated && Request.Form.Count > 0)
{
HttpContext.Current.GetOwinContext().Authentication.Challenge(
new AuthenticationProperties { },
OpenIdConnectAuthenticationDefaults.AuthenticationType);
}
else
{
HttpContext.Current.GetOwinContext().Authentication.Challenge(
new AuthenticationProperties { RedirectUri = "/XXXapp locationXXX/" },
OpenIdConnectAuthenticationDefaults.AuthenticationType);
}
}

I've figured it out,. Needed to set the save token flag to true. This allowed the token to be carried along in the request. So, I don't need if else. Now that I got that working I'm changing this section of code. My main issue is it is hard to find complete and current documentation with sample code for my use case. --Thanks

OWIN Challenge method does nothing

I'm trying to integrate a Microsoft account login into my ASP.NET MVC app, and I have this controller method:
public void SignIn()
{
// HACK - we will be signed into only one account if we are not signed in to MS
if (Request.GetOwinContext().Authentication.User.Identities.Count() <= 1)
{
// Signal OWIN to send an authorization request to Azure
Request.GetOwinContext().Authentication.Challenge(
new AuthenticationProperties { RedirectUri = "http://localhost:31503/MicrosoftCalendar" },
OpenIdConnectAuthenticationDefaults.AuthenticationType);
}
}
What I expect to happen is that I'm prompted to log in to my Microsoft account; instead, what happens is this method runs over and over and over again, doing nothing at all, until I get a "too many redirects" error in my browser. How can I get the Challenge method to actually do something?
I have a class OwinStartup in my web project; I have it set to be the OWIN startup class like so:
[assembly: OwinStartup(typeof(Root.OwinStartup))]
However for some reason my breakpoints inside this startup class never get hit; OWIN is never being initialized... actually, wait a second, it is being initialized, but the event handlers for things like OnAuthorizationCodeReceivedAsync are never being hit...
If I step through the code, after Challenge is called in the SignIn method, I get redirected for some reason to a UserController, which in turn redirects me back to the SignIn method. I wonder why I'm winding up in the UserController?
edit: I need more code? all right, this method in Global.asax.cs executes immediately after the OWIN calls:
protected void MvcApplication_BeginRequest(object sender, EventArgs e)
{
#region Set the context GUID cookie
if (null == Request.Cookies[CookieName.ContextGUID])
{
Response.SetCookie(new System.Web.HttpCookie(CookieName.ContextGUID, Guid.NewGuid().ToString()));
}
#endregion
// check to see whether SSL is required
if (System.Web.Security.FormsAuthentication.RequireSSL)
{
// check where the request is originating from
if (Request.UserHostName != "127.0.0.1" && Request.UserHostName != "localhost")
{
// check if the request is secure
if (!Request.IsSecureConnection)
{
string url = null;
// check for querystring segments
if (!String.IsNullOrEmpty(Request.ServerVariables["QUERY_STRING"]))
{
url = String.Format("https://{0}{1}?{2}",
Request.ServerVariables["SERVER_NAME"],
Request.ServerVariables["SCRIPT_NAME"],
Request.ServerVariables["QUERY_STRING"]);
}
else
{
url = String.Format("https://{0}{1}", Request.ServerVariables["SERVER_NAME"], Request.ServerVariables["SCRIPT_NAME"]);
}
// redirect to the secure url
Response.Redirect(url);
}
}
}
// verify the request
if (null != Request)
{
// NOTE: This is a workaround for the following exception thrown by the ReportViewer control when
// using a non-IE browser:
// Missing URL parameter: IterationId
// See the following reference: https://connect.microsoft.com/VisualStudio/feedback/details/556989/?wa=wsignin1.0
if (Request.Path.EndsWith("Reserved.ReportViewerWebControl.axd") &&
Request.QueryString["ResourceStreamID"] != null &&
Request.QueryString["ResourceStreamID"].ToLower().Contains("blank.gif"))
{
// intercept the request and send to actual valid image path
Response.Redirect(Constant.ImageRoot + "blank.gif");
}
}
}
Not sure if this is what's causing the infinite redirect loop but here it is...

This is maybe a shot in the dark, but it looks like the controller isn't returning anything because it is a void method, try adding a return type, I'm not overly familier with OWIN so you'll have to forgive me there but here is an example of what I'm talking about:
public ActionResult SignIn()
{
// Signal OWIN to send an authorization request to Azure
return Request.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "http://localhost:31503/MicrosoftCalendar" },
OpenIdConnectAuthenticationDefaults.AuthenticationType);
}
two small changes which are in the method signature, returning ActionResult and not a void, you may have to do a bit of research here on the class that OWIN actually returns. and second adding the return keyword, note this will not work with the if statement that you have said is a "hack" because you would require two return statements in that scenario
Hope this helps.

ASP.NET Identity 2 and Anonymous Users

In our developing e-commerce solution we are using AspNet Identity 2.2.1 and it is required that any guest (anonymous) users should complete checkout without prior registration to the website. In order to fullfill this requirement have written an ActionFilter named UserMigrationAttribute which obtains SessionTrackId (string GUID) from cookie -which we set from a HttpModule for every request if SessionTrackId is not found along with request cookies- and creates and actual IdentityUser in database with the username something like SessionTrackId#mydomain.com.
We have decorated our BaseController class with this UserMigration attribute in order to utilize its functions throughout the site.
Everything up to this point works as expected with single downside issue, which is when the page is being loaded for the first time for any user, if we try to make an Jquery Ajax Call to a Method which have [ValidateAntiForgeryToken] attribute, the call fails with the 'The provided anti-forgery token was meant for a different claims-based user than the current user.' error, even though we are sending __RequestVerificationToken parameter with every ajax call.
But if user opens another page by clicking link and/or reloads/refreshes current page, all the subsequent ajax calls complete successfully.
In our understanding UserMigrationAttribute creates user on OnActionExecuting method, but after we signIn user in the process #Html.AntiForgeryToken() is not being updated with the right values.
You may find the UserMigrationAttribute code below;
[AttributeUsage(AttributeTargets.Class)]
public class UserMigrationAttribute : ActionFilterAttribute
{
public ApplicationSignInManager SignInManager(ActionExecutingContext filterContext)
{
return filterContext.HttpContext.GetOwinContext().Get<ApplicationSignInManager>();
}
public UserManager UserManager(ActionExecutingContext filterContext)
{
return filterContext.HttpContext.GetOwinContext().GetUserManager<UserManager>();
}
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
CreateMigrateCurrentUser(filterContext);
base.OnActionExecuting(filterContext);
}
private static readonly object LockThis = new object();
private void CreateMigrateCurrentUser(ActionExecutingContext filterContext)
{
lock (LockThis)
{
var signInManager = SignInManager(filterContext);
var userManager = UserManager(filterContext);
var sessionTrackId = GetSessionTrackId(filterContext);
if (!filterContext.HttpContext.Request.IsAuthenticated)
{
if (!string.IsNullOrEmpty(sessionTrackId))
{
var username = string.Format("{0}#mydomain.com", sessionTrackId);
var user = userManager.FindByName(username);
if (user == null)
{
user = new User() {UserName = username, Email = username};
var result = userManager.Create(user);
userManager.AddToRole(user.Id, StringResources.AnonymousVisitorsGroup);
}
signInManager.SignIn(user, true, true);
}
}
else
{
if (!string.IsNullOrEmpty(sessionTrackId))
{
var username = string.Format("{0}#mydomain.com", sessionTrackId);
var user = userManager.FindByName(username);
if (user != null)
{
if (!HttpContext.Current.User.IsInRole(StringResources.AnonymousVisitorsGroup))
{
var targetUserId = HttpContext.Current.User.Identity.GetUserId<int>();
var service = new Service();
service.Users.MigrateUser(user.Id, targetUserId);
}
}
}
}
}
}
private string GetSessionTrackId(ActionExecutingContext filterContext)
{
var retVal = string.Empty;
if (filterContext.HttpContext.Request.Cookies["stid"] != null)
{
retVal = filterContext.HttpContext.Request.Cookies["stid"].Value;
}
return retVal;
}
}
Any help or suggestions are highly appreciated.
Thank you,

This is happening because the anti-forgery token is set in a cookie, which will not be updated until the next request. If you're manually signing a user in, you should also issue a redirect (even if to the same page they were already headed to), simply to ensure that the cookie data is correct. This normally happens naturally, as the sign in form will redirect to the URL that needed authorization after the user is signed in, thus negating the problem. Since you're not redirecting currently, the data is out of sync.
However, I have to say that this seems like a very poor solution to this particular use case. Creating some sort of temporary-type user and signing that user in to handle guest checkout creates an unnecessary glut of useless data in your database, at best, and leads to bugs and other issues like this one you're experiencing, at worst.
I also run an ecommerce site, and the way we handled guest checkout is incredibly simplistic. The checkout data is just stored in the session (email, shipping/billing address, etc.). We build a view model to handle the actual checkout where the data necessary for submitting the sale comes either from the user object, if they're logged in, or these session variables, if they aren't. If the user is neither logged in, nor has the requisite session variables set, then they are redirected to the onboarding form where billing/shipping, etc. is collected.
For other aspects like maintaining an anonymous cart, we use a permanent cookie with the cart identifier. If the user ends up creating an account, we associate the anonymous cart with their user, and then remove the cookie. This ensures that their cart survives past the session timeout and things like closing the browser, even if they're anonymous.
In other words, in all these things, no user object is actually needed. If it's there (user is logged in), great, we'll use it. Otherwise, we collect and persist the requisite information for checkout via other means.

Web API Basic Auth inside an MVC app with Identity Auth

So I have a C# MVC app using Identity for its authentication. I now have a need to expose a few things via Web API to some of my clients. Instead of building a separate app, project, deployment... I've simply added an API Controller to my existing project. To keep things simple for my clients, I've decided to use Basic Auth, opting rather to force my clients into using SSL connections to my API.
I've followed this very useful tutorial to implement the Basic Auth in my API:
http://www.piotrwalat.net/basic-http-authentication-in-asp-net-web-api-using-message-handlers/
Problem is, that their instructions take over Auth for the entire app...
I need my MVC app to keep using the Identity Auth that it is currently using and hopefully roll my own custom attribute (like [APIAuthorize]) so that it only applies to my API Controller.
I can probably hack around and try to get this to work, but as this is concerning security, I decided to ask for some pro help on how to best implement this. Specifically, I need to know 1) what do I do in my Global.asax (if anything) as the above URL suggests I do this:
protected void Application_Start()
{
GlobalConfiguration.Configuration.MessageHandlers
.Add(new BasicAuthMessageHandler(){
PrincipalProvider = new DummyPrincipalProvider()
});
//...
}
But again, this would take over the Authentication to the entire app... 2) What do I need to do in my custom auth attribute to make all of this work seamlessly.
And of course, if there's a better way to do all of this (without creating a separate app or increasing the implementation difficulty to my clients) then I'm all ears.

I us a filter attribute to adorn the actions i wanted to expose to Simple Auth. I cant remember where i got this code from (probably stackoverflow i just don't have the link so i cant claim credit for it)
public class BasicHttpAuthorizeAttribute : AuthorizeAttribute
{
protected override bool IsAuthorized(HttpActionContext actionContext)
{
if (Thread.CurrentPrincipal.Identity.Name.Length == 0)
{
// Get the header value
AuthenticationHeaderValue auth = actionContext.Request.Headers.Authorization;
// ensure its schema is correct
if (auth != null && string.Compare(auth.Scheme, "Basic", StringComparison.OrdinalIgnoreCase) == 0)
{
// get the credientials
string credentials = UTF8Encoding.UTF8.GetString(Convert.FromBase64String(auth.Parameter));
int separatorIndex = credentials.IndexOf(':');
if (separatorIndex >= 0)
{
// get user and password
string passedUserName = credentials.Substring(0, separatorIndex);
string passedPassword = credentials.Substring(separatorIndex + 1);
SimpleAES crypto = new SimpleAES();
string userName = crypto.DecryptString(ConfigurationManager.AppSettings.Get(Constants.SIMPLEUSERNAME));
string password = crypto.DecryptString(ConfigurationManager.AppSettings.Get(Constants.SIMPLEUSERPASSWORD));
// validate
if (passedUserName == userName && passedPassword == password)
{
Thread.CurrentPrincipal = actionContext.ControllerContext.RequestContext.Principal = new GenericPrincipal(new GenericIdentity(userName, "Basic"), new string[] { });
}
}
}
}
return base.IsAuthorized(actionContext);
}
}
Then i use it as so
[BasicHttpAuthorize]
public HttpResponseMessage MyExposedSimpleAuthAction()

HTTP Module and Cookies in Sharepoint 2007

I have some proof concept code for a HTTP module. The code checks to see if a cookie exists, if so it retrieves a value, if the cookie does not exist it creates it and sets the value.
Once this is done I write to the screen to see what action has been taken (all nice and simple). So on the first request the cookie is created; subsequent requests retrieve the value from the cookie.
When I test this in a normal asp.net web site everything works correctly – yay! However as soon as I transfer it to SharePoint something weird happens, the cookie is never saved - that is the code always branches into creating the cookie and never takes the branch to retrieve the value - regardless of page refreshes or secondary requests.
Heres the code...
public class SwithcMasterPage : IHttpModule
{
public void Dispose()
{
throw new NotImplementedException();
}
public void Init(HttpApplication context)
{
// register handler
context.PreRequestHandlerExecute += new EventHandler(PreRequestHandlerExecute);
}
void PreRequestHandlerExecute(object sender, EventArgs e)
{
string outputText = string.Empty;
HttpCookie cookie = null;
string cookieName = "MPSetting";
cookie = HttpContext.Current.Request.Cookies[cookieName];
if (cookie == null)
{
// cookie doesn't exist, create
HttpCookie ck = new HttpCookie(cookieName);
ck.Value = GetCorrectMasterPage();
ck.Expires = DateTime.Now.AddMinutes(5);
HttpContext.Current.Response.Cookies.Add(ck);
outputText = "storing master page setting in cookie.";
}
else
{
// get the master page from cookie
outputText = "retrieving master page setting from cookie.";
}
HttpContext.Current.Response.Write(outputText + "<br/>");
}
private string GetCorrectMasterPage()
{
// logic goes here to get the correct master page
return "/_catalogs/masterpage/BlackBand.master";
}

This turned out to be the authentication of the web app. To work correctly you must use a FQDM that has been configured for Forms Authentication.

You can use Fiddler or FireBug (on FireFox) to inspect response to see if your cookie is being sent. If not then perhaps you can try your logic in PostRequestHandlerExecute. This is assuming that Sharepoint or some other piece of code is tinkering with response cookies. This way, you can be the last one adding the cookie.