Let's say I have an administration view. In the constructor of the view, I check that the user have ADMIN role. Then I create a view. During interaction of the user with the view, I see many Vaadin internal client-server calls. Should I worry about the security aspects of these calls, where I may potentially be hacked. Or it is safe and Vaadin will handle the security aspects of these calls?
The security model in Vaadin Flow is based on views and components, rather than the request-based model that is common in web frameworks that work on a lower abstraction level.
As long as you trust that the regular session mechanism provided by the servlet container is safe enough, then you can assume that the Vaadin components that you create for one user will only be available for that user. Vaadin takes care of individual requests to see that they are related to a component instance that belongs to the session that the component was created for.
Related
I went through different Architecture books such as this one: Microsoft Application Architecture Guide, 2nd Edition
And now I am building a new n-tier website with ASP.Net MVC as Presentation layer.
My question is, If I will use the asp.net Identity, on which tier/layer should I implement the user authentication?
I thought it should be in the Cross Cutting Concerns, because I will need to check if user is authorized or authenticated to access some functions plus I may use the user name on many tiers, such as the Business, Services and Presentation layer.
and also thought it will be better to put it in the Presentation layer specially because the presentation layer is MVC and it will be easy to deal with ASP Identity from there and will allow me to user [Authorize] and [AllowAnonymous] easily.
I know that this question answer depend on many other factors but I am trying here to achieve the most best practice, so need to get your point of view and discuss it.
There are quite a few similar questions here on stackoverflow, and just many answers. Here my view on the matter.
You have to separate the abstraction from the implementation.
The abstraction (an interface) defines the questions you need to able to ask to the authentication service. This interface is used by all other parts of your application that are going to use your authentication service. This means that your abstraction must be defined somewhere that can be referenced by the other parts of your application. My suggestion would be to put this in the business layer, since the methods in the interface (in other words the 'questions that you want to ask to the service') are usually business related. Another suggestion is to put it in a Core layer (if you have one).
That leaves us with the implementation of the interface. I would implement this in the easiest place that you can that works. Can you do it in the business layer, fine. Do you need to use the identity classes from MVC, good too, place it there. It doesn't really matter where you put it, since it isn't used directly.
Of course, to make this all work you do need to use a little Dependency Injection, to register your implementation for the interface.
I have found that this is usually a pretty straightforward answer if you separate the concern of authentication from authorization. Authentication always ends up having to sit in front of presentation. It's a layer in front of the presentation layer. It really has to be.
After authentication occurs, passing that authenticated identity down into the other layers is just another model object, and should be treated as such. Binding authentication/authorization to all the different layers as a cross cutting concern makes your code much harder to reuse in different contexts. Also makes it much harder to test.
Hi I have a question related to SAAS model and multi-tenancy.
As far as I know SAAS multi-tenancy application means common functionality
for all clients, with some customizations of UI and functionality underNeath.
If I need make for some customers additional client specific-customization , how I can achieve it?
I know about approach of SalesForce
As for answer I apreciate to see you experience with such
- customizations under database level,
- architecture of backend in general or in
- any links for this topic.
There are the following two ways of customizing a multi-tenant application
1. Presentation tier changes
2. System change.
The following are the typical customization options preferred in web applications in a multi-tenant environment, they are
1) user interface and branding,
2) workflow and business rules,
3) data model extensions, and
4) access control
In which 1 belongs to the presentation tier change and the rest all form the system level change in a multi-tenant application.
MVC is considered as presentation tier customization option where in we have the option of allowing the tenant to have their own theme , logo and custom layout or custom controllers and custom page sections.
For System settings, there are many ways to achieve this, however the following are the most pervasive
Customization at the database level
Customization at the middleware level.
In SaaS app, there are features and implementation. In the case of the later, there will be a tenant specific configuration that governs which implementation to be invoked for the tenant under consideration based on his configuration and then provides the service. These are achieved using a custom dependency injection mechanism which is tenant aware and also will be required a tenant specific configuration that can be consumed during the runtime to facilitate this process.
In the case of (1), the data in the db should be isolated based on the tenant identifier so that the configuration or the metadata are not shared between the tenants in a multi-tenant environment.
So the main components will be
a tenant identifier obtained from a tenant context
multi-tenant datastorage
Tenant specific authentication [form signing / Single SignOn etc..]
IMHO, since your topic is broad, if you can present us more specific areas, we will discuss on their implementation.
Hope this answers your query, please do post your update.
My ASP.NET MVC application includes a number of View files that are editable by the end-user (they're stored in a database and loaded via a VirtualPathProvider).
I'd like to allow my users to edit their view files, however I'm wary of the security implications.
Is there any way I can enforce some kind of code-access-security that ensures that any code in the view cannot perform any dangerous tasks (i.e. minimum trust, it can only access the database via a passed-in repository object and render itself. No filesystem access, no debugging its host process, etc).
I can restrict the superclass that the view derives from (by having my VirtualPathProvider provide the header <%# Page directive, while only the render function body is returned from the database), so can I enforce CAS by applying attributes to this superclass, or is it something more involved and this is no easy task?
MVC runs in a homogeneous AppDomain, which means that all code in the framework runs with the same permission set. As such, there is no way to lower the CAS permissions of a given view. (You wouldn't really want to do this anyway, as it would prevent the MVC framework from working properly.)
The only feasible solution - though unfortunately this is a great deal of work - is to define your own view format that simply can't be used to do anything dangerous, then have a custom view engine that knows how to serve views of that type. This gives you the ability to define "dangerous" however you want, from blocking server-side code execution to even attempting to block Javascript execution (which is quite a difficult task in its own rite).
I am interested in general approach for building interactive GUI using MVC3.
The idea is to build set of different components that can be integrated (plugged in) into various scenarios.
Each Component MUST have it's own model definition, controller and views.
Component encapsulates not just the view but also behavior through it's controller.
All internal implementation details, model, behavior, etc... must reside inside component,
so that component becomes independent, modular - black box.
This allows component to be changed without breaking anything in context in which component is used.
Context in which component runs must not make any assumptions about internal details of component implementation.
On the other side the component does not make any assumptions about context in which it will be used.
Finally, the component must provide mechanism to "communicate" or "interact" with outside world. Beside internals, component must provide some kind of "external" interface (like parameters, data, functions, events whatever...) which would allow component to be integrated into execution context.
The Context (or scenario) is part which contains components.
Now, the basic challenge for the context is to manage interaction between components.
Real-world Categories component example:
Component displays list of categories and allows user to perform various actions such as sorting, paging and record selection.
Internally, it has it's own model which stores relevant information like current page, sort, selection, etc...
Internally, it implements all required actions (for basic render, for user actions response, etc...) in it's own controller.
Internally, it handles model state persistence in the view and model state restore in it's own controller.
Real-world Products component example:
Component displays list of products and allows user to perform various actions such as sorting, paging and record selection.
Internally, it has it's own model which stores relevant information like current page, sort, selection, etc...
Internally, it implements all required actions (for basic render, for user actions response, etc...) in it's own controller.
Internally, it handles model state persistence in the view and model state restore in it's own controller.
Real-world Dashboard page (context, scenario) example:
Page displays both Categories and Products components.
Products component displays all products for the currently selected category and thus must provide external interface (parameter or something) to receive selected category identifier from the context.
Categories component must provide some kind of external interface so that context can act when selected category changes and provide selected category identifier for the products component.
Technically, communication approach for page updates would mostly go through AJAX but if this is possible without AJAX, it would be even better.
In the case of AJAX, I would like solution which uses server side controller(s) which decides and renders what should be updated on the client (JSON or something).
I would not like solution in the client script (client side "like" controller) which decides what actions to call and what parts of page to update - this as said in previous paragraph must be decided by controller(s) on the server.
Important: It is not necessarily for the components to work when directly called via some route.
How would you generally implement described system?
I think you need to investigate real projects and see, what approach do you need to use. Try following project and u can find many best practices:
Here u can find implementing of security measures, services, auth and many many useful.
Kigg
http://www.nopcommerce.com/downloads.aspx
http://orchard.codeplex.com/
It's hard to say for me how it's should be implemented. Better to code it. But using of Dependecy Injectction of Views, Controllers, Services, and Repositories are must in your case.
Each controller handles a whole user-machine pattern. That is, roughly, each controller is responsible for orchestrating the user-machine interaction for a user-case(the user-machine patterns that are the result of the analysys phase).
Now if you put "standard behaviours" in controllers who will coordinate the user-machine interaction pattern?
This way you will have "components" without something that coordinate their execution.
In web forms you have pages that coordinates the execution of components put in them...but in Mvc thi coordination role is played by the Controllers themselves.
You can do black-boxes composed of Controllers and Views just if each of them is responsible of a whole user-machine interaction pattern. That is a "Big Components" not a small building blocks, as its is the case when you implement a CMS.
The Orchard CMS use a similar approach. However what you call components are actually pre-defined blocks that play the role of whole sections of the websites being built by the user.
It seems to me that you are trying to achieve something which may not be out-of-the-box compatible with the philosophy of web MVC (other implementations of MVC might support it).
However, if you wanted to go to the trouble of writing a framework on top of ASP MVC, I am sure you could achieve what you want. For example, by using Areas, you could achieve a form of encapsulation of your controllers, view models, and views.
To compose different areas for the same master view, you could write the equivalent of a front controller with its own view that took in a view model - that view model would be primed by the front controller to render actions from the different areas.
You might achieve more mileage by using a client framework such as Backbone.js on top of ASP MVC.
I have a site which has an area that requires authentication. Right now I use the roles attribute on all the controllers in that area, and I run a query to retrieve that users ID, and all their settings.
It seems like a code or design smell to me that I am retrieving the userid and settings each time a controller in that area loads up? I'm not sure if I should be using sessions, or if ASP.Net MVC 2.0 provides some unique way to handle this. Another concern is security.
Overall, I don't really know which way to turn. Design wise I would like the userId and settings retrieved only once when the user logs into the area. Right now I grab the userId each time a controller loads up, and then if required, I query the database for their settings each time as well.
One of the rules about security is that you shouldn't try to do it yourself. There are many pitfalls in doing an authentication system correctly without leaving loopholes or backdoors. Thus, in that regard, you might consider the SqlMembershipProvider that comes with .NET. It can be used with MVC and provides the means to get roles and the current security context, is easy to setup and configure and will be more secure than rolling your own.
If you are not using SQL Server, you have a couple of choices. One solution would be to use something like SQL Server Express or SQL Server Compact Edition to maintain the credentials. Another solution would be to mimic the SqlMembrershipProvider database schema and then write a custom provider that communicates with that schema.
The last choice would be to write a custom MembershipProvider class. While this is still rolling your own, it forces you into the structure of the MembershipProvider so that you can swap it out at a later date for a different one (e.g. ActiveDirectoryMembershipProvider) and provides a common interface for interacting with credentials and logins which for example enables easy use of the built-in Login control.
If you are already using a MembershipProvider and are asking about storing additional user-specific data, then I would suggest the SqlProfileProvider with all the caveats I mentioned above about the SqlMembershipProvider. the ProfileProvider provides a structure for maintain user-specific data with the currently logged on user.
For more information:
Introduction to Membership
Implementing a MembershipProvider
ASP.NET Profile Providers
You could also implement a custom identity. They are very easy to implement, and they let you store whatever user information you want in Identity, which is then stored in the cookies that Identity puts down, so you're not hitting the DB every time to get that info.
Just create a new class that inherits from GenericIdentity, and you'll be on your way.
You of course have to be careful how much info you put there since it's in a cookie, but usually user related information in the case you're talking about here isn't so big.
We use a custom identity to store a few bits of info about the user, and it works out pretty well.
You could store an object in session that holds all the required user information. You will just need to add a property in the Controllers, Views or other base classes where you want to retrieve the user information/profile. This would be the authorisation info as opposed to any authentication info (eg Forms authentication)
You might try "Windows Identity Foundation". I've been using it on one of my projects for a while. It allows for "claims-based authentication", which basically means that you get to designate "claims", strings of information that describe the user when she logs on.
Once logged on, the user's claims can be read from the HttpContext.Current.User field. You can also use "Role" claims that seamlessly integrate with a role-based authentication schema; meaning that you can give the user a "manager" role claim and then use `if (User.IsInRole("manager")).
As an added bonus, WIF makes it very easy to re-use your login screen in other applications.
All in all, it's very flexible, but the documentation is very poor. I've asked and answered a number of questions about "Windows Identity Foundation" on StackOverflow.
We have done this quite a few times in the past. Similar to what Thomas mentions, what we have generally done is implemented a new Membership provider based on the Microsoft SQL Memberhsip provider to do this. We inherit from the base MembershipUser class and add any custom properties we would want to have on the user object. You have to implement a database read for the Membership provider on the GetUser implementation, so you can consolidate your extra properties you need into that database read.
If you are using SQL server, Microsoft has release the 2.0 code for it. You can get more information at Scott Gu's blog.
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx
If you want to start from scratch, they also have good resources at MSDN.
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
and
http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
Once you have implemented your provider, you can then add the Membership user to the Items collection of the current web context to get access to it from your code. The non extended properties from the base base user class are also available on the Request thread like normal.
With the Microsoft release of the 2.0 version of the source code , we found it helped us alleviate some concerns that exist about reinventing. Another thing to consider for your implementations is based on your scenario, you can bypass implementing some of the code. An example of this would be the CreateUser code if you are hitting a back end system that already has the credential information.
It seems like you're relatively happy with your authentication process but you want to explore other options for session/settings.
My suggestion has to do with settings only (roles, preferences, etc.)
In my opinion, having to traverse the whole technology stack from UI to Business Tier to DB tier to DB is sometimes a bit overkill.
For data that isn't likely to change during a session, this adds a lot of overhead... There are potentially several data transformations happening (DB (Relational Format) -> ORM -> Web Service XML Serialization -> Web Tier deserialization).
You might consider a session system that doesn't rely on a heavy RDBMS system or on the ASP.NET Caching / Session model. There are options that are very performant and that scale well.
You could use RavenDB by Ayende Rahien (Built for .NET). Its main goal is to provide low latency, high performance access to schema-less JSON documents.
Using this solution, you would set up ravenDB in the web tier so that access to data is very quick.
The first time you authenticate and retrieve settings, you would store the userID and settings information in this session DB.
Every time you load your controller after that, the settings data is accessible without having to go back to the RDBMS.
This DB could also be used to cache other web related data.
As for security, the settings data makes it to the web tier regardless of the method you use. This solution would be no more or less secure than the other options (more secure than an unencrypted cookie). If you needed to, you could encrypt the session data - but that will increase your overhead again.
Just another one of the million options to consider.
Good Luck,
Let us know what you decide!
Patrick.