I have noticed that if a user is still logged in or has a persistent cookie, even if he gets "banned", or disabled in the database (Users Table flags), the user can still access everything until that cookie goes away or the user logs out of the site. Great security right.
So I am putting together a ActionFilterAttribute that checks for this, the disturbing thing for me is I have to hit the database for every controller that his ActionFilterAttribute is applied to. There has to be a better way of doing this but I have not found one yet.
Any ideas would be awesome..
There has to be a better way of doing this but I have not found one yet.
No there isn't. Sorry. If the notion of disabled/banned user exists only in your database there is no other way but hitting your database. ASP.NET only verifies the validity of the authentication cookie which is sent on each request. It doesn't even know what a disabled user means so you cannot expect it do more than it already does.
There are a few options:
1) You can validate whether the user authentication is valid by hooking session start. This way if the user has a persistent cookie, you can validate the username and expire the cookie if needed.
2) You can use a time based mechanism to check the user auth status every few requests (every 5mins or whatever). You could store the lastChecked timestamp value in the user session or in the auth cookie itself using the UserData field. This allows you recheck if the user auth cookie needs to be expired more frequently, but keeps database calls to a minimum.
MyThis is the solution I came up with:
In the User Account Membership service add a function to return whether the user's account is still active.
public class UserAccountMembershipService : IMembershipService
{
public bool UserIsActive(Guid userId)
{
if (userId == new Guid()) throw new ArgumentException("Value cannot be null or empty.", "userName");
MembershipUser user = _provider.GetUser(userId, true);
return user.IsApproved;
}
}
Override the AuthorizeAttribute as follows:
public class MyAuthorizeAttribute : AuthorizeAttribute
{
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
IMembershipService membershipService = new UserAccountMembershipService();
//Check to see if the user's account is still active
bool isActive = false;
if (httpContext.User.Identity.IsAuthenticated)
{
Guid userId = (Guid)Membership.GetUser(httpContext.User.Identity.Name).ProviderUserKey;
isActive = membershipService.UserIsActive(userId);
}
if (!isActive)
{
//If the user's account is no longer active log him/her out
IFormsAuthenticationService FormsService = new FormsAuthenticationService();
FormsService.SignOut();
}
//Call the base AuthorizationCore method
return base.AuthorizeCore(httpContext) && isActive;
}
}
Related
I have an application that is authorizing an OAuth2 token with Spring Security. Using the #PreAuthorize tag, I can easily make sure that a user has a permission before allowing them to access a method:
#PreAuthorize("#oauth2.hasScope('account.read')")
public void getAccount(int accountId);
{
//return account
}
This works great at restricting users without the account.read permission from accessing this method.
The only problem is now any user with this permission can access any account. I want to restrict the users to only access their own account. I'm sure this is a common scenario. How do other applications deal with this?
So, the question here - how would system know if account belongs to user?
The answer would be that you are probably storing User<->Account relationship in the database. The most simple solution would be to do the check right in your method:
#PreAuthorize("#oauth2.hasScope('account.read')")
public Account getAccount(int accountId) {
// get account from db
Account account = repository.findById(accountId);
// you will need a little helper to get your User from
//Spring SecurityContextHolder or whatever there for oauth2
User user = securityManager.getCurrentUser();
if (account.belongs(user)) {
return account;
} else {
throw new UnathorizedException("User is not authorized to view account");
}
}
Upd. one of possible improvements may be to first get the user, get id from it and do a repository.findByIdAndUserId(accountId, userId) or somthing like that. (or even repositoryFindByIdAndUser(accountId, user))
I'm trying to design a solution where a ServiceStack server can just use an authentication cookie from ASP.NET. (In reality, it could be any cookie. It's just getting a session ID that it can lookup details using a back channel). The custom auth providers don't seem to be the right direction since they are based on credentials being sent. Instead, a GlobalRequestFilter made more sense to me. In there, I check the cookie, get the external session information, then set them to the ServiceStack session and set IsAuthenticated. This works fine in the request service as it has access to the session details that it needs. Fine so far.
The issue, is that when I decide to lock down services with the Authenticate attribute, it apparently runs the attribute prior to my filter so it always wants to redirect them to login. What is the recommended place to add my logic so it fires before the Authenticate attribute and validates properly?
ServiceStack's [Autenticate] attribute is for use with ServiceStack's AuthProvider model so you'll still want to use a Custom AuthProvider. You can have a look at the IAuthWithRequest Auth Providers in the last release notes for examples of creating Custom Auth Providers that aren't based on using credentials:
JwtAuthProviderReader.cs
ApiKeyAuthProvider.cs
AspNetWindowsAuthProvider.cs
By implementing IAuthWithRequest interface in your AuthProvider the [Authenticate] Request Filter will call PreAuthenticate() to perform any Auth validation before validating whether the User is Authenticated or not. Here you can populate the Users Session if the User is Authenticated, e.g:
public class MyAuthProvider : AuthProvider, IAuthWithRequest
{
public override bool IsAuthorized(IAuthSession session, IAuthTokens tokens, Authenticate request = null)
{
return session.IsAuthenticated;
}
public override object Authenticate(IServiceBase authService, IAuthSession session, Authenticate request)
{
throw new NotImplementedException("Authenticate() should not be called directly");
}
public void PreAuthenticate(IRequest req, IResponse res)
{
//Do any Auth validation...
//populate the Session in the Request to Authenticate this user
req.Items[Keywords.Session] = new AuthUserSession {
UserName = ...,
Email = ...,
//populate other fields
IsAuthenticated = true,
};
}
}
Then to register your custom Auth Provider add it to your AuthFeature plugin in AppHost.Configure(), e.g:
Plugins.Add(new AuthFeature(() => new AuthUserSession(),
new IAuthProvider[] {
new MyAuthProvider (),
}));
Can you explain the differences between HttpApplication.AuthenticateRequest and HttpApplication.AuthorizeRequest in ASP.NET MVC 3 please? When will they occur? Assume this scenario:
My User has a property called IsBanned and I want to check his/her IsBanned property in each request. If it was true, I redirect the User to an error page. But not for all requests, just requests that their action signed by [Authorize] attribute. OK, atthis type of actions, will HttpApplication.AuthenticateRequest occur or HttpApplication.AuthorizeRequest or anything else?
I know I can check this property in SignIn|LogOn action. But I means this:
A user requests logging in
I check the property IsBanned and it was false
The user logged in
User view some pages of site
The admin banned the user (while he is logged in)
User requests a page (action) that have [Authorize] attribute
User is logged in (before this. remember?)
So I have to show the requested page
But the user give a banned flag by admin
How can I prevent user from viewing requested page?
Thanks in advance.
I dont think you need to deal with either of HttpApplication.AuthenticateRequest or HttpApplication.AuthorizeRequest. I would solve it by using a custom Authorize Attribute.
public class MyAuthorizeAttribute : AuthorizeAttribute {
protected override bool AuthorizeCore(HttpContextBase httpContext) {
bool authorizerPrimarily = base.AuthorizeCore(httpContext);
if(authorizedPrimarily){
return user_not_banned;
}
return authorizerPrimarily;
}
}
You can get user's name from httpContext.User.Identity.Name. Use it to grab data from database.
Update for comment-1
To redirect banned users to a specific page, you may do this:
if(authorizedPrimarily){
if(user_banned){
httpContext.Response.Redirect("url of banned message");
return false;
}
return true;
}
Is there an integrated way in asp.net mvc 3, to permit authentification and actions based on the time of the day ?
For example, if it's 18:00 o'clock, users that belong to a specific role are not allowed to log in or if they are already authenticated, they will be automatically logged out or not being able to do actions.
I guess in the log in method I could check for user role and time of day and then on each action, I will also check for role and time of day and permit but is there and easier way to accomplish this ?
UPDATE:
I guess there is no easier way to just set the time and user/roles so I ended up implementing the answer(solution).
You could write a custom Authorize attribute and override the AuthorizeCore method in which you would perform the necessary check:
public class MyAuthorizeAttribute : AuthorizeAttribute
{
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
var authorized = base.AuthorizeCore(httpContext);
if (!authorized)
{
return false;
}
// At this stage standard authorization passed =>
// you could now check the user roles in the database
// and the time of the day and return true or false from here
...
}
}
and now all that's left is decorate your controllers/actions with this custom attribute.
For certain actions like changing email settings or administrator activities, I want users to re-authenticate before the action is completed. Is there a good pattern for doing this in ASP.NET MVC 3?
Descpription
You can create your ActionMethod with Username, Password and the field you want to change (Email) for example. Than validate this data in the [HttpPost] of your data. If the authorization has success, change it and if not add the error to the ModelState.
Use a ViewModel for that.
Sample
public class ChangeEmailViewModel
{
public string Username { get; set; }
public string Password { get; set; }
public string EmailAddress { get; set; }
}
public ActionResult ChangeEmail()
{
return this.View(new ChangeEmailViewModel());
}
public Action ChangeEmail(ChangeEmailViewModel model)
{
// authorize
bool isAuthorized = // your logic.
if (isAuthorized)
{
// change email
} else
{
ModelState.AddModelError("Username", "Username is not valid");
}
return this.View(model);
}
If you want to dynamically intercept and re-authenticate someone who is already authenticated, you could probably also handle this with a special cookie. The actions that require re-auth could be decorated with a custom filter that overrides OnAuthorization to check for the cookie, then redirect to take username & password if it is not found. Pattern, no code:
User clicks link to uber-protected action.
Filter on action looks for cookie and does not find it, redirects to sign in.
User signs in, and you write a special cookie
(different from the forms auth cookie),
then redirect back to original action.
Filter on action looks for cookie and finds it authorizing user.
The lifetime of the cookie would at least have to go all the way to the http post of the uber-protected action. You will have to decide when to delete it. For example, after user re-auths for one uber-protected action, do you want them to re-auth for second uber-protected action in the same browser session?