We have an ASP.NET MVC4 web application and in our QA environment we set up different "sites" as WebApplications on the same website, e.g.
www.mysite.co.uk/WebApp1
www.mysite.co.uk/WebApp2
www.mysite.co.uk/WebApp3
For all our cookies, we ensure that the cookie key contains an ID that ties that cookie to the specific Web Application, so there's no cross contamination.
Now this all works perfectly well the vast majority of the time. However, very occasionally in our DEV environment, we find that the GUEST shopper (not authenticated) can access a controller's Action method that is marked with the [Authorize] attribute.
My guess here is that the browser has been used with multiple TABS, each one pointing to a different Web Application, and occasionally the browser/server is getting confused over which ASPXAUTH cookie to use, and is using one from a different Web Application for a shopper who has authenticated. As I said, that's only a guess, but by debugging the site we're definitely hitting a break-point in the code that's supposedly protected with this Attribute.
It's not clear at this point how I may prevent this behaviour.
Thanks
Griff
For all our cookies, we ensure that the cookie key contains an ID that ties that cookie to the specific Web Application, so there's no cross contamination
You are storing the ID within custom cookies, but it appears you are not storing this within the auth cookie that ASP.NET uses to grant access to code marked with the [Authorize] attribute.
You can either add the ID to the encrypted token that gets stored inside the auth cookie and check this per request, or you could encrypt the token with a different key per site.
Fortunately the FormsAuthenticationTicket constructor includes a userdata parameter that can be used for custom data.
public FormsAuthenticationTicket(
int version,
string name,
DateTime issueDate,
DateTime expiration,
bool isPersistent,
string userData
)
You can follow this guide in order to easily store multiple pieces of information using the JSON format like so:-
public static class HttpResponseBaseExtensions
{
public static int SetAuthCookie<T>(this HttpResponseBase responseBase, string name, bool rememberMe, T userData)
{
/// In order to pickup the settings from config, we create a default cookie and use its values to create a
/// new one.
var cookie = FormsAuthentication.GetAuthCookie(name, rememberMe);
var ticket = FormsAuthentication.Decrypt(cookie.Value);
var newTicket = new FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration,
ticket.IsPersistent, userData.ToJson(), ticket.CookiePath);
var encTicket = FormsAuthentication.Encrypt(newTicket);
/// Use existing cookie. Could create new one but would have to copy settings over...
cookie.Value = encTicket;
responseBase.Cookies.Add(cookie);
return encTicket.Length;
}
}
You should also have a custom name for this cookie per site so they can co-exist within your DEV environment.
Related
I have just added Piranha CMS to an existing ASP.NET MVC 5 site but am having a strange issue.
If I am logged into the site and then try to access site.com/manager and enter the piranha login details then the page just refreshes and nothing happens (trying with an incorrect password gives me an incorrect password message but correct login details just refreshes page)
If I try accessing site.com/manager without being logged into the site then it logs me in OK the piranha manager area.
Any ideas why this is? Ideally I'd like the user to only need to login once is this possible?
The current version of Piranha CMS doesn't integrate with other authentications. For now the only solution is to keep the user accounts separate like you noticed. This feature has however been planned for a couple of years but hasn't been implemented due to various reasons.
Pulling out the authentication mechanics imposes a lot of changes on the database schema and makes setting user priviliges for specific pages much harder.
Regards
HÃ¥kan
I found that this can be supported with a small change to the handling of the Piranha user class to support both FormsIdentity and ClaimsIdentity. I've posted the fix on the Piranah GitHub Issue log - I'm sure it will get included in a build in the future, but you might want to give the fix a try. With this change I can support MVC4/5 and Piranha (and HTTPS as well).
I use OWIN identity management in my application and switching from my application to Manager correctly asks me to login (Piranha uses Forms). This isn't a problem and I have no problem with the need to have separate logins between application users and content managers.
I noticed a problem under Https where the LocalUserProvider class was expecting to get a FormsIdentity back from the HttpContent.Current.User.Identity but in many cases it was getting a ClaimsIdentity. This caused it to refuse the login and keep cycling round the login form.
I locally modified the LocalUserProvider to add the following method;
/// <summary>
/// Piranha explicitly uses FormsAuthentication - this method is used to replace a calls to HttpContext.Current.User.Identity in this
/// module which would ordinarily return the users Idenity as an ClaimsIdentity, and the Name part of the ClaimsIdentity is the login name
/// not the Forms Authentication Guid expected by Piranha. The OWIN and Forms can co-exist side by side, but when Piranha gets the users
/// identity, it expects to get a Forms Identity.
/// </summary>
/// <returns></returns>
private System.Web.Security.FormsIdentity extractFormsIdentityFromHttpContext()
{
if (HttpContext.Current.User != null)
{
System.Security.Claims.ClaimsPrincipal claimsPrincipal = HttpContext.Current.User as System.Security.Claims.ClaimsPrincipal;
if(claimsPrincipal != null)
{
return claimsPrincipal.Identities.OfType<System.Web.Security.FormsIdentity>().FirstOrDefault();
}
}
return null;
}
and use it like this;
/// <summary>
/// Gets if the current user is authenticated.
/// </summary>
public bool IsAuthenticated {
get {
System.Security.Principal.IIdentity formsIdentity = extractFormsIdentityFromHttpContext();
if (formsIdentity != null && formsIdentity.IsAuthenticated) {
try {
// Check if this user has a Guid id.
var id = new Guid(formsIdentity.Name);
return true;
} catch { }
}
return false;
}
}
This means the LocalUserProvider will always deal with the contexts FormsIdentity explicitly and has the happy side effect of allowing manager login to work under https.
Hope its a useful suggestion
i have a MVC application that contains an ASPX page that will be called in single sign on mode.
How can i set the user that is passed by a request call?
I tried to use "Identity" with no fortune.
example:
string username = "MyUsername";
string userid = Guid.NewGuid().ToString("N"); //could be a constant
List<Claim> claims = new List<Claim>{
new Claim("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", username),
new Claim("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", userid)};
var genericIdentity = new GenericIdentity(username);
genericIdentity.AddClaims(claims);
var genericPrincipal = new GenericPrincipal(genericIdentity, new string[] { "aaa" });
Context.User = genericPrincipal;
The second problem is that i have some data regarding the user but i can't set to session (like expected by signalr design).
How can solve it?
Update:
After some search i understand what i really need. When the page is called i check validation of user on database and if it's verified i need to store this information in a way that is reachable everywhere. It's what i would have done with SESSION object.
For me a user is not a simple string, but it's a complex object that contains useful information for the behaviour of the program.
I hope i am clearer.
You can add state on the client proxy.
If your data is too complex for that, you need to pass it at apprpriate times using hub methods.
I have the following ntier app: MVC > Services > Repository > Domain. I am using Forms authentication. Is it safe to use Thread.CurrentPrincipal outside of my MVC layer to get the currently logged in user of my application or should I be using HttpContext.Current.User?
The reason I ask is there seems to be some issues around Thread.CurrentPrincipal, but I am cautious to add a reference to System.Web outside of my MVC layer in case I need to provide a non web font end in the future.
Update
I have been following the advice recieved so far to pass the username into the Service as part of the params to the method being called and this has lead to a refinement of my original question. I need to be able to check if the user is in a particular role in a number of my Service and Domain methods. There seems to be a couple of solutions to this, just wondering which is the best way to proceed:
Pass the whole HttpContext.Current.User as a param instead of just the username.
Call Thread.CurrentPrincipal outside of my web tier and use that. But how do I ensure it is equal to HttpContext.Current.User?
Stick to passing in the username as suggested so far and then use Roles.IsUserInRole. The problem with this approach is that it requires a ref to System.Web which I feel is not correct outside of my MVC layer.
How would you suggest I proceed?
I wouldn't do either, HttpContext.Current.User is specific to your web layer.
Why not inject the username into your service layer?
Map the relevant User details to a new Class to represent the LoggedInUser and pass that as an argument to your Business layer method
public class LoggedInUser
{
public string UserName { set;get;}
//other relevant proerties
}
Now set the values of this and pass to your BL method
var usr=new LoggedInUser();
usr.UserName="test value "; //Read from the FormsAuthentication stuff and Set
var result=YourBusinessLayerClass.SomeOperation(usr);
You should abstract your user information so that it doesn't depend on Thread.CurrentPrincipal or HttpContext.Current.User.
You could add a constructor or method parameter that accepts a user name, for example.
Here's an overly simplified example of a constructor parameter:
class YourBusinessClass
{
string _userName;
public YourBusinessClass(string userName)
{
_userName = userName;
}
public void SomeBusinessMethodThatNeedsUserName()
{
if (_userName == "sally")
{
// do something for sally
}
}
}
I prefer option number 2( use Thread.CurrentPrincipal outside of web tier ). since this will not polute your service tier & data tier methods. with bonuses: you can store your roles + additional info in the custom principal;
To make sure Thread.CurrentPrincipal in your service and data tier is the same as your web tier; you can set your HttpContext.Current.User (Context.User) in Global.asax(Application_AuthenticateRequest). Other alternative location where you can set this are added at the bottom.
sample code:
//sample synchronizing HttpContext.Current.User with Thread.CurrentPrincipal
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];
//make sure principal is not set for anonymous user/unauthenticated request
if (authCookie != null && Request.IsAuthenticated)
{
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
//your additional info stored in cookies: multiple roles, privileges, etc
string userData = authTicket.UserData;
CustomPrincipal userPrincipal = PrincipalHelper.CreatePrincipal(authTicket.Name, authTicket.UserData, Request.IsAuthenticated);
Context.User = userPrincipal;
}
}
of course first you must implement your login form to create authorization cookies containing your custom principal.
Application_AuthenticateRequest will be executed for any request to server(css files, javascript files, images files etc). To limit this functionality only to controller action, you can try setting the custom principal in ActionFilter(I haven't tried this). What I have tried is setting this functionality inside an Interceptor for Controllers(I use Castle Windsor for my Dependency Injection and Aspect Oriented Programming).
I believe you are running into this problem because you need to limit your domains responsibility further. It should not be the responsibility of your service or your document to handle authorization. That responsibility should be handled by your MVC layer, as the current user is logged in to your web app, not your domain.
If, instead of trying to look up the current user from your service, or document, you perform the check in your MVC app, you get something like this:
if(Roles.IsUserInRole("DocumentEditorRole")){
//UpdateDocument does NOT authorize the user. It does only 1 thing, update the document.
myDocumentService.UpdateDocument(currentUsername, documentToEdit);
} else {
lblPermissionDenied.InnerText = #"You do not have permission
to edit this document.";
}
which is clean, easy to read, and allows you to keep your services and domain classes free from authorization concerns. You can still map Roles.IsUserInRole("DocumentEditorRole")to your viewmodel, so the only this you are losing, is the CurrentUserCanEdit method on your Document class. But if you think of your domain model as representing real world objects, that method doesn't belong on Document anyway. You might think of it as a method on a domain User object (user.CanEditDocument(doc)), but all in all, I think you will be happier if you keep your authorization out of your domain layer.
Consider an ASP.NET MVC application using the Salt parameter in the [ValidateAntiForgeryToken] directive.
The scenario is such that the app will be used by many customers. It's not terribly desirable to have the Salt known at compile time.
The current strategy is to locate the Salt value in the web.config.
[ValidateAntiForgeryToken(Salt = Config.AppSalt)]
//Config.AppSalt is a static property that reads the web.config.
This leads to a compile-time exception suggesting that the Salt must be a const at compile time.
An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type
How can I modify the application to allow for a runtime loading of the Salt so that the app doesn't have to be re-salted and recompiled for each customer?
Consider that the Salt won't change frequently, if at all, thereby removing the possibility of invalidating form
The Salt property is meant to be a compile-time constant. It's simply a way to link a particular form to a particular action method. For example, if you have a login form, you may wish to use the salt "Login" for this form so that a token that was valid for the login form can't be used for the change password form, etc.
In all cases, the app's machine key is automatically used as an additional salt value. So an anti-XSRF token for one application can't be used for another application, even if both salt values read "Login". The machine key is settable in the Web.config <machineKey> section.
I had the requirement to have different salts for different customers. In this case, I used Dixin's solution for injecting the salt at runtime.
Anti Forgery Request Recipes For ASP.NET MVC and AJAX at the section titled "Specify non-constant salt in runtime".
Decorate your Controllers with a new attribute:
[ValidateAntiForgeryTokenWrapper(HttpVerbs.Post)]
public class ProductController : Controller
{
// Only HTTP POST requests are validated.
}
This new attribute is defined as:
public class ValidateAntiForgeryTokenWrapperAttribute : FilterAttribute, IAuthorizationFilter
{
public ValidateAntiForgeryTokenWrapperAttribute(HttpVerbs verbs)
{
this._verbs = new AcceptVerbsAttribute(verbs);
this._validator = new ValidateAntiForgeryTokenAttribute()
{
//load from web.config or anywhere else
Salt = Configurations.AntiForgeryTokenSalt
};
}
// Other members.
}
Where do I get information about the currently connected user? That is, how does shibboleth pass the information?
Can I set some restrictions on actions using [Authorize] attribute based on data acquired from shibboleth?
Shibboleth publishes user attributes associated with
sessions into HTTP request headers, based on header names defined
in Attribute Acceptance Policy (1.3.x) or Attribute Mapping (2.x)
files. These headers are transformed into CGI variables based
on mapping rules defined by the CGI specification.
You should be aware of this security advisory:
http://shibboleth.net/community/advisories/secadv_20090615.txt
I have never user shibboleth, but you can get information about the user from Controller.User property. It will return a generic principal of current thread. Using this principal you can check whether the user is authenticated and get a login name of the user. This is due to the reason that after logon an authentication cookie is set and this cookie contains limited amount of information. And on each request after logon only this cookie is checked (if it exists and valid - user is authenticated).
So if you need in some specific information you can manually load a user (it's better to use cache here) and check whatever you want.
Also you can create and attach your own principal with necessary information to the thread on start of a request (e.g. on start of a request load the user from db/cache using user name from base principal, create and set your own principal to thread). After this you can check all properties of the user you need.
Where would you attach your own principal? You say on the start of the request but what if you don't want every request authorizing?
You'll want to create a method in Global.asax.cs that has the following signature
protected void Application_PostAuthenticateRequest()
{
//Your code here.
}
This will be called automatically before almost anything else is done (MVC will call this method if it exists, you don't have to "turn it on" anywhere), and this is where you need to set the Principal. For instance, let's assume you have a header called RolesHeader that has a comma separated value of roles and another header called UserId that has (duh) the user ID.
Your code, without any error handling, might look something like:
protected void Application_PostAuthenticateRequest()
{
var rolesheader = Context.Request.Headers["RolesHeader"];
var userId = Context.Request.Headers["UserId"];
var roles = rolesheader.Split(',');
var principal = new GenericPrincipal(new GenericIdentity(userId), roles);
Context.User = principal;
}
It's the Principal/Identity that the [Authorize] attribute uses, so setting it here at the beginning of the request lifecycle means the [Authorize] attribute will work correctly.
The rest of this is optional, but I recommend it:
I like to create my own custom classes that implement IPrincipal and IIdentity instead of using the GenericPrincipal and GenericIdentity, so I can stuff more user information in it. My custom Principal and Identity objects then have much more rich information, such as branch numbers or email addresses or whatever.
Then, I create a Controller called BaseController that has the following
protected new CustomPrincipal User
{
get
{
return (base.User as CustomPrincipal) ?? CustomPrincipal.GetUnauthorizedPrincipal();
}
}
This allows me to access all my rich, custom Principal data instead of just what's defined in IPrincipal. All of my real controllers then inherit from BaseController instead of directly from Controller.
Obviously, when using a custom Principal like this, in the Application_PostAuthenticateRequest() method, you'd set the Context.User to be your CustomPrincipal instead of a GenericPrincipal.