We Keep Coding

How to implement basic security for my CRUD web app in ASP.net Core 2.2?

I have followed a wonderful tutorial by Microsoft on creating a MVC web app using Core 2.2 (https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/?view=aspnetcore-2.2). After completing this tutorial I was able to build a similar web app using a different product. For simplicity I will stick with the "Movie App" example from the tutorial to ask my question.
Below is the view of the basic CRUD application created.
I would like to provide some basic security for the web application. So far I have been unable to find a solution that meets my needs which are as follows:
Simplicity. There will be only one user who needs any privileges and that is me. The privileges will be full use of CRUD features (I am the only one who can click on any of the blue link in the above image).
No login requirements for the public. I would like anyone who visits to be able to be able to make a query from the search box (not shown in the picture) and see the results. I just don't want them to be able to make any changes.
Not to have to spend too much time on security so I can continue learning in areas better suited to newer developers.
The bulk of the options I am finding are enterprise level, complex beyond my skill level at the moment, or require everyone to be a user. If I am the only user is there a way for me to easily create one user account and maybe a second factor like an IP lock? If not is there a better approach for me to take in tackling this issue?

OK, one thing you have to implement is "some" kind of security / Login - so that the application knows "someone" has logged in. In your case, it needs to know that "you" have logged in. So you have to implement some kind of basic Authentication mechanism, so that the user "identity" is known. You can take a look at basic cookie authentication here. You don't need to implement any major claims system - a simple authentication is enough (for your non production / learning scenarios).
Once you have implemented some kind of authentication / login system, after a successful login (authentication), the system knows that the "user" is authenticated. Then in your Razor code you could simply check for this condition & then remove the links for Unauthorized folks & on controllers you could add the "Authorize" attribute so that back-end code also checks for authenticated users for relevant functionality.
eg: In Razor code, you could include conditional links to Edit / Delete etc, like so:
#if(User.Identity.IsAuthenticated)
{
//Include links for Edit / Delete
}
And you can include a mix of [Authorize] attribute on relevant controllers and [AllowAnonymous] on relevant methods.
Hope this helps. There is no escaping some basic understanding & work.

ASP.Net Upgrading a Web Site in a phased approach

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).

Reporting Solution web-based using .net framework suggestions

I have a situation, where we have a MS SQL Server 2012 database and the client is requesting a number of reports to be generated from this db. The client is also requesting that this data should be seen in his current portal (custom web based using .Net C# and ASP.NET) or a hosted web-application in his IIS.
I was thinking of going for something which lets you create queries on the fly with the least amount of effort and with the possibility to customize them through code (since the requirements always get changed + certain reports are very easy to make). Just to give you an example of what I had in mind is Ubiq (see video here: https://www.youtube.com/watch?v=UgXrbdnsa9Y )
Kindly can you please give me some examples or solutions that can be used.

There are a lot of reporting solutions out there, i recommend you to try them all and pick the one that better fits your needs, with that in mind, you can start by trying DBxtra, which lets you create queries easily (although not on the fly) and lets you customize them if you need/want to, it also runs on the .NET Framework, so you can easily host it along with your customer's application.
P.S.: I'm a DBxtra evangelist.

What's the deal with custom ASP.NET MembershipProviders?

I'm hoping someone can help me wrap my head around what's going on when I try to implement a custom MembershipProvider. This is probably more of a theory question than a code question...here's what I have:
MVC 2 app (started from an empty MVC 2 project)
SQL Server DB with my own "users" table
A User class, UserRepository, UserService, blah blah blah
Currently, my application authenticates via the UserRepository which returns a User object if successful. This User object is then stored in the session and is subsequently interrogated by all controller actions that require authentication.
Now...I understand that storing this in the session leaves me vulnerable to session hijacking and that a more secure method would be to implement my own MembershipProvider. What I don't understand is, where would this custom Provider end up storing my User object? I see that the overridden ValidateUser() method just returns a bool, but I can't figure out where that information is persisted for that user's time on the site.
I'd really like to keep my existing process while making it more secure by taking away the dependence on session for user authentication. I like having a complete user object at my disposal throughout the application once the user is logged in, but I'm open to suggestions otherwise. It seems that a lot of the MembershipProvider documentation is kinda black-box. I'm hoping that someone can explain what it's actually doing under the hood to persist user authentication.
Thanks in advance

Once a user is validated ASP.Net Membership creates a token (a large encrypted string) that is stored as a cookie or as part of the URL string depending on how you configure it in the config. It can optionally do either based on whether cookies are available or not. The token is used to persist the identity of the user to answer your main question about how it works at low levels. Everything else associated (roles, profile, etc) is retrieved from the server depending on how the custom provider is implemented.
It's not necessarily true that this is more secure than session - it has the same vulnerabilities of URL or cookie replay if the site is not protected by SSL encryption (worse with URL in case the users email around url's to others).

Take a look at the way Microsoft did there's they released the source
Provider Source
Also remember nothing is a black box in .Net you can use Just Decomile or reflector to learn more about how others(Microsoft) have done the same thing you want to do.

Aside from all the answers, I believe the missing link in your post is ASP.Net Forms Authentication - this is actually what uses ASP.Net Membership in an ASP.Net web application.
So if you have your own db and auth scheme (already) in place, you can use Forms Authentication with it - even without trying to make it work with Membership (you really don't have to).
Here's (quickly becoming my most used link) an overly simplistic MSDN example of Forms Authentication with the scheme hard coded. It shows you that you can even do it that way - not that you should of course, but just shows you the possibilities.
As all the answers above have stated, you can build your own provider if you require. The farthest I've gone (so far) hasn't been to build one, but just customize a few methods. Reason: the existing user db of a project I had was using MD5. This meant I just overrode 2 methods (if memory serves that is) - ValidateUser() and CreateUser()....
Hth

Here's an excellent tutorial on implementing your own custom MembershipProvider.
http://www.codeproject.com/Articles/165159/Custom-Membership-Providers
That being said, you really need to read the article. Once you read the article and follow the steps, you'll start to understand the answer to your questions. There's really not a great way to understand it other than going through the drudgery of following a tutorial like this. At least, that is my opinion. I just implemented my own custom membership provider for the first time by going through this tutorial. After a few hours, I was able to start implementing my own encryption algorithms.

I would highly recommend using the standard Membership Provider but creating a link table to join your existing user repository to the asp net membership provider. Best of both worlds.

Database independent row level security solution

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.