Simply I want to move development to .Net Core and Angular.
We have a legacy web site project written in C# ASP.Net application, functionally it meets the business needs, performance is good and it runs on the latest technologies. That said it is difficult to work with it, making changes takes time , it really needs an overhaul in the business layer , DAL needs to move to (EF) and want to move to a new GUI framework. These changes are all to improve quality, developer productivity, ultimately accelerate releases.
We have set of new features that need to be implemented, they are almost standalone "bolt-ons", ideal to develop as a separate site, but we need to use existing login details and session details, to make the user experience seamless. The goal is write new functionality in the "new world" and then re-write legacy pages in chunks.
This must be a common and obvious problem but research on how to achieve this have been fruitless.
The question really is how to dynamically share session data between sites.
It sounds like you're currently keeping your session in data in memory. The standard way to get around this is to move your session state out of memory and into something like SQL Server, MongoDB, Redis, etc so that both applications can access the shared state.
Update
Now we're getting to the crux of the problem. If you're depending on data that's stored in fields / hidden fields, you might already have a security problem (it's hard to say without knowing more about your implementation).
I'm guessing that the question you're trying to ask is, "How do I securely navigate from the legacy system to the new system (and vice-versa)". There are a couple of possible strategies here:
The first solution that comes to mind is an SSO (Single Sign On) approach. This is where you pass an opaque token from one system to the other that identifies the current user.
If you've able to serve the old/new applications from the same hostname you can use cookies to to store a user token of some sort.
Notes:
Don't pass something like a plain text user id being passed in the url.
The SSO token should be something completely separate from the user id (could be a guid that refers to a record in a shared database for example).
Related
Basically, I have a new desktop application my team and I are working on that will run on Windows 7 desktops on our manufacturing floor. This program will be used fairly heavily as it gets introduced and will need to interact with our manufacturing database. I would estimate there will (eventually) be around 100 - 200 machines running this application at the same time.
We're lucky here, we get to do everything from scratch, so we define the database, any web services, the program design, and any interaction between the aforementioned.
As it is right now, our legacy applications just have direct access to a database, which is icky. We want to not do that with the new application.
So my question is, how do I do this? Vague, I know, but basically I have a lot at my disposal here, and I'm not entirely sure what the right direction to go is.
My initial thought, based on what I've perceived others doing, is to basically wall off the database by using webservices. i.e. all database interactions from the floor MUST occur through the webservices, providing a layer of security by doing much of the database logic behind closed doors. Webservice calls are then secured to individual users via Active Directory.
As I've found though, that has some implications of its own... We have to abstract the data before it reaches the application. There's still potential for malicious abuse by using webservice calls repeatedly to ruin or spam data. We've looked at Entity Framework and really like what it provides, but as best I can tell, that's going to be unavailable by the time we're at the application level in this instance.
It just seems like I can't come to a conclusion on what is "right". So, what is right?
WebServices sounds like a right approach. Implementing a SOA-oriented layer on the webservices layer gives you a lot of control over what happens to the data at the database server.
I don't quite share your doubts about repeated calls doing any damage - first you can have an audit log of every single call so that detecting possible misuses is obvious. But you also could implement a role based security so that web service methods are exposed to users in roles, which means that not everyone will be able to call just any method.
You could even secure your webservices with forms authentication so that authentication is done against any datasource, not only the active directory.
And last thing, the application itself could be published as a ClickOnce application so that it is downloaded and executed from the web page and it automatically updates itself just as you publish new versions.
If you need some technical guidance, I've blogged on that years ago:
http://netpl.blogspot.com/2008/02/clickonce-webservice-and-shared-forms.html
My suggestion since you are greenfield is to use an API wrapper approach with Servicestack.
Check out: http://www.servicestack.net/ServiceStack.Northwind/
Doing that you can use servicestack authentication, abstract away your db layer (because you could move to a different DB provider, change its location, provide queues for work items etc...) and in time perhaps move your whole infrastructure to an internal intranet app.
Plus Servicestack is incredibly fast, interoperable with almost any protocol you through at it, and provides for running it through MONO, so you are not stuck with a MS backend that could be very expensive.
My two cents. :)
First of all this question is not appropiate for StackOverflow, you might get close-votes really quickly.
Second, You may want to have a look at WCF RIA Services for this.
These will allow you to create basic CRUD operations for all your entities, and stuff like that.
I never used this myself, no I'm not sure what the potential issues might be.
Otherwise, Just do what we did:
Create generic (<T>) interfaces and services and contracts and everything. This will allow you to adapt your CRUD functionality in your Services, DAOs, ViewModels and such to any entity type.
For web based applications, why doesn't PHP need middleware to run - yet languages like Java, C#, etc do?
UPDATE:
Re-worded: Why doesn't PHP need a middle tier, or business layer separating it from the database, whereas the others do.
Assuming that by the term "middleware" you mean "a middle tier", or "a business layer" the answer is that none of them need it.
For example, there is nothing to stop you in C# (or more correctly, on the .Net Framework "stack") from writing code in web pages that directly accesses the database. Indeed, lots of prototypes start out this way.
The issue here is more around good practice - it is generally considered A Bad Thing(tm) to write web pages (sticking with the same example) that directly access the database and the reasons for this are many. Testability, security, good decoupled code - all these require you to separate your code out, and having several tiers is a natural way to do this.
Why do you not see as much of this with PHP? I think Jeff's latest blog post covers this well :)
I'd go as far as to say that C# (the language), .Net (the Framework), ASP.NET (especially ASP.NET MVC) and much of the documentation and tutorials encourage you to do the right thing and not punch a whole from the web page through to the database.
But there isn't actually anything stopping you from doing it.
The use case that can appear is the following:
You have multiple web apps serving data that is stored in a database. Let's say the web apps are:
Front-end for your desktop web experience
Front-end for your mobile web experience
Front-end for your APIs that you expose to developers
Let's say each front-end accesses the database directly. Then, your eng team decides that the current database should be replaced. Now you have the problem of rewriting code in every front-end.
If you had a middle tier to abstract the actual data store, you'd only re-write one layer of code. Additionally, having unit tests for that middle tier would ensure that the way the middle tier exposes data remains uniform, regardless of the data storage platform.
In the production process of an internal-use ASP.NET/C# website, are there any advantages to starting with authentication/authorization/login FIRST, and building up from there? Or is it better to just build your site exactly how you want it, with unlimited restrictions and no logins or anything, and then do that at the end of production, before release? That's what I WANT to do --- just work on the functionality of the website, unrestricted, having one less thing to worry about. But I want to make sure that this approach doesn't cause problems later.
When it comes time to implement the ASP.NET authentication, it should just be a matter of running the script to generate the necessary tables and then using WSAT to manage the users and then provide restrictions to the already-existing content...should be...
You need to give your security consideration right up front. Even if you don't develop the final login screens and restrict access as you develop, IMO you should make sure that you can authenticate your users and limit access on at least one screen before going ahead with 'god mode' development. Include:
Authentication - Windows, Forms, etc.
Authorization / Access Control - will Role do or do you need Operation-level checking - e.g. AzMan
If you will be using SiteMap, you will need to look at security trimming to hide functionality to which the user doesn't have access (menus, breadcrumbs etc)
Auditing - e.g. changes to important data
Even though the site is for internal use, users can't be trusted, and you will need to ensure that you are safe from SQL Injection, XSS etc as well.
Definitely yes, that is the practical approach. You, said it, adding security creates no problem at all to an existing project.
Infact, when you come to securing the site there are a number of procedures before creating users. Also you shouldn't rely fully on WAT for user management it is better, I think, to have your own interface as you'll need it after deployment.
Your approach may sound faster but it have architectural drawbacks in following areas:
1- Missing security alignment with per page / per method level invocation.
2- Not clear Use case and work flow in terms of authentication / authorization.
3- Complete lack of security based testing while developing and adding up the new features gradually.
4- Lack of End-to-end dependency- What if security needs to be considered across layers, you will miss the whole vision on modular dependency and end-to-end testing.
Overall, if you do it 1st then you can just have one sample user/pwd/roles established and use that for all the secure areas of site, this will be sufficient to test and develop the application continuously.
Later when your application is ready; it's good to go with large number of user/pwd and associated roles to work with.
Hope this helps.
I have a working WinForms application, written in c#, which is divided in several layers (Data layer, Model, business logic, common layer, etc). I would like to allow users to use web browser also for data manipuolation. Do I need to make some kind of in-between layer, or I am safe with using business layer from Web forms? Also, what kind of MS technology should be used on the web layer, as I see that we can use both classic ASP.NET pages, Silverlight, or maybe something else? The application itself has several forms for entering data, and many, many different forms with charts and reports.
Thanks in advance.
It's hard to make a recommendation without knowing your existing app details. There's also no one right answer. Silverlight, ASP.net (MVC), Javascript/jquery/ajax are all good technologies that have their place and use. But, as you decide for yourself, here's some thoughts and things to consider.
A thick winform app is typically a fat client with local state. Your data model etc... may rely on state to be persisted across many requests in a fatter local process.
A thick winform app is typically used by the one user & process - unless you're coding concurrency, your app may not be thread safe.
A web process is shared by multiple users making requests - any shared state will need to consider concurrency and memory footprint.
You typically want the web process to hold less state and drive more of the client experience down to the client - thus the popularity in ajax, jquery etc... More javascript technologies.
Silverlight is closer to your winform process - it's hosted in the browser plug-in with the state and code being accessed by that one user. You will have to change the view layers to silverlight but you might be able to retain your model and data layers.
Running in a silverlight plug-in does have more restrictions (sandboxed) than a full winform app. http://msdn.microsoft.com/en-us/library/dd470128%28v=vs.95%29.aspx
Many folks like ASP.Net MVC - check it out.
Javascript approaches using ajax, jquery, etc... has gotten alot of momentum in recent years. Be aware that will be a bigger shift from your winform code which may be good or bad depending on how you look at it.
does anybody knows about Java/C# database independent authorization library. This library should support read, write, delete, insert actions across company organizational structure.
Something like this:
- user can see all documents
- user can enter new document assigned to his unit
- user can change all documents assigned to his unit and all subordinate units.
- user can delete documents that are assigned to him
I should also be able to create custom actions (besides read, write,...) connect them to certain class and assign that "security token" to user (e.g. document.expire).
If there aren't any either free or commercial libraries, is there a book that could be useful in implementing this functionality?
Thanks.
I, too, am surprised at the lack of security frameworks.
There is Rhino Security. Ayende has a handful of blog posts about it.
Another blog has a couple of articles on it, too.
It is possible to use it with S#arp Architecture as well.
Can't say I've implemented it in a project, just read up on it a while back. It was the only implementation of its sort that I could find.
I found one library that has functionality similar to my needs:
http://www.codeproject.com/KB/database/AFCAS.aspx
It is strange that there aren't any more of it on web since this is a problem that every serious application faces. As for documentation/example, the best I found are authorization modules of CRM systems like:
- Siebel - Siebel security guide - Chapter 10.Access Control
- Sugar CRM - http://www.sugarcrm.com/crm/products/capabilities/administration/access.html
- Microsoft CRM - http://msdn.microsoft.com/en-us/library/ms955698.aspx
That is a kind of functionality I need. I guess it will be DIY task.
The problem with implementing your security solution in your client library is that it is only effective with the client tool. That sounds pretty DUH on it's own, but you leave open the huge security hole that is the database itself. So if a user connects directly to a database (for example using an Access ADP to SQL Server) they have full control to whatever their user role is. Which they would need full access to everything in the database, if you are doing your restrictions in the client library.
The only case where this wouldn't be as big an issue would be with web applications and web services. If your web service did the security and hid it behind the web service interface (so there was no direct access to the database), then it would be safe. This may be what you're talking about, but didn't specify in your question.
If you are using a fat client, is there a reason why wouldn't want to put the security logic in the database side? You mentioned database independent, but nothing you specified would be difficult to provide in each platform. You basically are describing pre-/post- triggers that check if a user has rights to edit a record. A full RLS would also restrict the user's rights to view and make things slightly more difficult depending on platform.