I have three current thoughts on how to do this:
re-implement AuthenticationService, which uses lots of internal constructors and internal helpers,
implement custom IIdentity and IPrincipal types and somehow hook these into FormsAuthentication.
give up and roll my own.
The problem is that we've got web apps and fat client apps using authentication and storing cookies. However, logging out of a web app does not log out of a fat client app, and we have now way of forcing a refreshed cookie, atm.
Found what I needed. Use number 2, implement my own IIdentity, and then implement the FormsAuthentication_OnAuthenticate on Global.asax [1].
[1] http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationmodule.aspx
Related
I had a question regarding best practice when it comes to building a global utility class in EmberJS when the class will exhibit user-specific behavior.
The following conditions are all true:
The class's methods could be accessed from anywhere in the entire application.
The application performs JSON based authentication using Ember-Simple-Auth.
The authentication confirmation payload comes with some information about the user.
The information received in the token payload will determine the behavior of the utility class's function.
My Questions
Is a Util the best option?
Should I be using services and somehow "initialize" this service on a confirmed authentication? My end goal is to use this class from almost every route/template/component in my application.
How chill are authentication payloads? Is it OK to send crumbs of user specific information information in the authentication payload in addition to any tokens?
The best choice is using services.
They are :
singleton
could be injected to any object extended from Ember.Object
Is a Util the best option?
No. Services is best option. You can initialize it after successful authentication hook of ESA. And it could be injected everywhere
How chill are authentication payloads?
You can send anything. Your authenticator is responsible to process it. The payload is saved in data.authenticated object in ESA session service
I have been doing a lot of research on the best way to secure my MVC 5 application.
We have one Web.csproj with many WebAPI Controllers and also an MVC site with two areas - one for Admin and then the public facing website.
After reading this article which states that the Base Controller is best way, I decided to go with that approach.
However, I am personally not OK with the use of base controllers (see this stackoverflow answer for some of my reasoning).
So, given that I am using MVC 5 (ASP.Net Identity and OWIN Authentication) - can anyone shed some light on the pros and cons of each approach?
The current practice in MVC 5 is to apply the AuthorizeAttribute as a Global filter, and open up individual Actions/Controllers with the AllowAnonymousAttribute
So in App_Start\FilterConfig.cs add the following lines:
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
... existing filters
// use the [AllowAnonymous] attribute to open up individual Actions/Controllers
filters.Add(new System.Web.Mvc.AuthorizeAttribute());
filters.Add(new RequireHttpsAttribute());
}
note: for good measure I have also added the RequireHttpsAttribute as every authenticated request with ASP.Net Identity carries the auth cookie, which is vulnerable to Man In The Middle attacks if carried over regular HTTP.
I would always use a base controller, for more reasons than just authentication and authorization...
To get to your question, what we ended up doing was rolling our own custom Authorisation Attributes with complex rules that all inherit from AuthorizeAttribute. Its pretty simple, all you do is inherit from the given attribute and then overwrite the OnAuthorization and AuthorizeCore methods.
Generally, all our controllers do not allow anon access, based on our baseController class. From there it gets as complicated as needed. But it always makes sense to use a base class for things like this and build on top of that. If you ever need to make a very wide system change quickly you tap it into the baseClass and thats it.
In my ASP.NET MVC controllers, I want to call a servicestack based service (not hosted in MVC site). In order to make the code testable, I want to inject this service client into the contoller constructor.
Assuming I have my own class that inherits from JsonServiceClient, can I use a singleton of that service client for all the MVC calls? This means the client would have to be thread safe.
Either the (Autofac) registration can be a singleton:
builder.RegisterType<SomeServiceClient>().SingleInstance();
or it has to be per http request:
builder.RegisterType<SomeServiceClient>().InstancePerHttpRequest();
Found a blog article where another servicestack user seems to use a singleton, but I was not sure: Blog Article Showing an Example
Each request is generally re-entrant so it's mostly ThreadSafe to use as a Singleton, the one caveat is that it shares the same CookieContainer, whilst the ServiceClients doesn't mutate the CookieContainer Collection itself, the underlying WebRequest would and it's not known whether WebRequest synchronizes access around it - although I've never personally seen any issues with them.
You can disable Cookies being used (i.e. if your client doesn't require a session) with:
client.StoreCookies = false;
I am working on application using GWT platform, and now i want to add security part. What is the best practice to do this?
My requirements for security are:
having user authorities;
hide some places from users without required authorities;
hide some elements on page from users without required authorities;
secure server side from unauthorized requests;
comfortable managing all of this things (like in spring using annotations or something like this )
having user authorities;
Model your users with permission atribute, like
private int user_type;
hide some places from users without required authorities;
Use the concept of Gate Keeper
A Gate Keeper is Singleton that obligates you to inherit a method called
boolean canReveal()
Using this, you can call server and search for user permission, then reveal or not the presenter called.
If a Presenter need security, just add #UseGateKeeper on it Proxy interface, like:
SomePresenter extends Presenter<V,P>{
#UseGateKeeper(YourGateKeeper.class)
SomePresenterProxy extends ProxyPlace{}
}
This will block users without some permission to access a presenter.
hide some elements on page from users without required authorities;
A good question, I've never seen this type of security in GWTP Projects. But you can always use Widget.setVisible(false) ;D, but I don't know if gwtp has a good practice for this.
secure server side from unauthorized requests;
GWTP GWTP makes it possible to link each of your ActionHandlers with a server-side ActionValidator that determines whether or not the current client can execute the action
You can hide some server calls using ActionValidator's.
read this
comfortable managing all of this things (like in spring using annotations or something like this)
As you can see, many of this security concepts use Annotations and other's stuff to manage easily your Application.
I need a gear for custom authorization in business logic classes. It has to be permissions based system, but I can not decide how to apply authorization rules to methods.
My first thought was to apply custom attributes to method
[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
// some code goes here
}
My business logic class has interface, so I can use, for example, Unity Interception behavior and check in runtime if current user has required permissions. And throw an exception if he has not.
But now I'm concerned about reliability of this method.
Usually the reference to business logic class injected by unity container. So there is no problem because it is configured to apply interface interception mechanism.
But what if some developer will instantiate my business logic class directly? Then no interception will be applied and he will be able to call any method even if current user has not permissions to make some actions or even he is not authenticated.
Also somebody can change unity container configuration, turn off Interception extension completly. Again my authorization system will not work.
I saw ASP .NET MVC is using similar mechanism for authorization. Authorization rule is applied only when request came by standard way (IController.Execute). I think this is not a problem in this case because end user of controller (web user) has no way to access controller class directly.
In my case end user of business logic is a programmer who develops front end and he can intentionally or unintentionally screw things - create instance of business logic class and call any methods.
What can you suggest me? How do you deal with this kind of problems?
Thank you.
The .NET Framework supports a mechanism for declarative permission verifications that does not depend on Unity interception or other "external" AOP. In order to take advantage of this, your attribute must inherit from System.Security.Permissions.CodeAccessSecurityAttribute. The System.Security.Permissions.PrincipalPermissionAttribute that is included in the BCL is an example of using this mechanism to evaluate user permissions. If it does not suit your needs, there's nothing stopping you from creating your own attribute that does.
If your constructors are internal and your objects instantiated from a factory, a developper won't be able to bypass your security by error.
If someone really, really wants to create your objets without the security, he could still do it using reflection, but this would have be pretty intentional to do so.