I need to create a very basic log in system to allow access to an admin portal.
I'll need to hold email, password and a field to identify access level (admin, read-only or edit).
Users will be created by an admin, where they will get sent an email with a generated password. There will be no user registration page.
Asp.net core Identity would handle all this...but my question is it overkill for a small application?
That is really a matter of opinion. I don't mind overkilling small tasks, as I learn a lot in the process. If it's a system between a small group, you could just implement a reset-button for you, that resets whoever you want, and generates a new random password. I have done that in the past.
Also .Net Core Identity handles a lot of the boilerplate code, so it's not that difficult to implement. There are a lot of great guides out there.
...but my question is it overkill for a small application?
Depends on your definition of an overkill.
It will allow you to setup working identity system in a few clicks, so from that point of view, having to code all that stuff from scratch would be an overkill.
On the other hand, the generated tables have a few excess (for your use case) columns that might seem like an overkill. There is also support for functionality like 2FA, which you may not need.
Bottom line: by choosing to use the identity system, you save time and gain some extraneous functionality.
I have been using .net for a very long time, and for a long time implemented custom user management (overriding built in providers, and customising to my own database structures etc) This is required if implementing over legacy system but for new development and security, it worth using off-the-shelf authorization/authentication systems whether it's built in or supported by .Net or using 3rd party services.
Related
I want to make a quick, safe and nice application.
For many years I have been programming in PHP and regular ASP. But wanted to go on with .NET and vue.js.
So I have an idea, I wanted to create and plan to do it like this:
I was thinking of using hosting from an external service.
Then I would have three projects:
domain.com/index - Vue.js which will be a SPA, where the user can filter through a catalog, press like and send few api requests (mainly get-requests).
secure.domain.com - Here I will have a .net mvc project where I can use identity. This will make it simple to handle/register users. I will also give the correct session here for authenticated users. And it will affect domain.com/index, where they only are allowed to do some of the things if they are logged in
api.domain.com - This will be the webapi api. Only authenticated users will be allowed to send some of the requests.
I have used several weeks at looking into how to structure this.
But as I do not have much experience with this.
What pitfalls and bad consequences do you see in structuring it like this?
Are there any heads up you want to give me? Or any other recommendations?
I have been trying to melt all of this together in one project, but that has been difficult, because they operate in different ways. So now I have ended up with this, and look forward to
Size of project
It will be a relative small project.
People should be able to register/authenticate themselves (through facebook/google/server login).
Authenticated People should be able to add records(links) to a database. When adding this to the database they may also want to upload files, and choose some additional information.
All people should be able to filter through the catalog of records (5000+) ( Here I am using vue.js/vuex/axios). Here they should be able to comment too on links too.
Webapi will have 8 entities/tables and one view which will GET all the information. 3 tables should be able to have POST.
So it is more or less a catalog, where people should be able to add records and find new ones.
I was planning to use the identity from asp.net core 3.1. It is a "template" where I can easily add 3rd party logins. (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1&tabs=visual-studio)
Additional questions:
Can you tell me how request from SPA will be authenticated in your API? (Jwt or cookie)? Why would you like to have a separate identity service, also Why you would like to use asp.net identity (is it because of ease of setup)?
I have not been thinking about authenticating API requests. Was thinking to only have authenticated users who can send POST-requests. And the rest will be get requests. Limited only from the server. Should I have some additional authentication? Does JWT make web APIs safe enough for my use?
Was thinking of using .net identity because it is simple. And I don't want to use time on setting it up.
Since this is your first project of this type, I would recommend to keep it simple.
Just create one web site. Otherwise you might get issues with the cookies not working for subdomains and you will also get issues with CORS. That is, you will get all problems at the same to time (configuration issues, infrastructure issues and the pain from writing the application itself).
You can still have a clean separation by using sub folders (or Areas in MVC) and by using class libraries for the backend (API) business logic.
Once you have mastered the basics (i.e. writing the actual application) you can start looking at other means of separation etc.
Currently I've been tasked to create a bunch of small-to-medium applications, each of them having some common functionality.
Implement a preapproved boostrap-based graphical design. Therefore, they will use the same assets, images, css and JavaScript components.
Share the same licensing-based mechanism. An application service will be built where it will scan a file or database to get the number of licenses available for each app, thus granting or denying access to users. The only thing that varies is the name of the application instance itself.
Use AzureAD authentication.
Each must use the same authorization mechanism. A claims-based mechanism will be built to retrieve the claims from the database, given a user AAD account.
Each must share the same administration console.This console will be the one needed to populate user information and common catalogs.
A service will be built, to show toast notifications within the apps.
An email notification service will be built, to send emails to users when triggered by business rules.
And some other, less important features, but these are the core ones.
A first, perhaps naïve approach, was to create an ASP.NET Core 2 solution for each application, and implement the shared functionality in a sort-of Core assembly that can be shared by each app. However, while this could work for points 2 to 5, I'd still be repeating the graphical UI design for each app (basically, copying the wwwroot folder as well as the shared razor views five times). So, a change tomorrow in a CSS would have to be replicated five times.
Another approach would be to create a single ASP.NET Core 2 solution, implement the shared functionality and the UI, and then use the "areas" feature o ASP.NET Core 2, each area being a different app. The problem to this approach is shipping the app: if I have to install the five apps in a customer's server, no problem. If I have to install, say, only two apps, then I'd have to ship the five apps anyway and find a way to disable the other three apps.
So, I'd like to know if there is a feature in ASP.NET Core 2 for handling this type of scenarios, or alternatively, what are industry-standard architectural designs that could apply here.
In Windows Presentation Foundation with Unity, I can create a common shell, and then load modules in that shell, within the same shell window. So, using configuration files, I can add or remove modules as I see fit. What I'm looking is something similar in concept. I do not want to create five ASP.NET Core solutions and copy-paste the wwwroot folder and implement the same mechanisms of authorization, notification, email, etc., but rather, find a way to load the core, common features and then load additional features.
Thanks in advance.
As the title suggests, I am not sure how an Authentication Server works. I have implemented authentication on multiple websites but it hasn't ever sat on a separate server. So, how would this architecture work? Is there material online that can explain this (I couldn't find any)? Advantages/ Disadvantages of this approach when compared to an implementing authentication on the same machine.
Having different authentication systems per application would land the user to create multiple profile which could be cumbersome for the user. Also architecturally you are creating tight coupling between application and authentication.
You should consider & design authentication as a simple Service/API call, this would help you in removing the coupling, achieving re-usability and maintainability. Following are few benefits of Authentication as a service or separate system:
Isolating Authentication system would create a path for implementing Single Sign On feature.
Implement changes and testing would be easier.
You can have the road-map to apply standardization in elegant manner.
In future your authentication can also handle authorization responsibilities.
When you change your Authentication system to a new IDAM solution, the impact on the business applications is reduced or eliminated.
You can find lot of Identity Access Management Solutions in the market which are pretty much industry standard. I would recommend you to research on SSO & IDAM products, which should give you comprehensive idea about the above mentioned points.
Searching for oauth2 stuff seems to bring up dozens of Q&A's on client-side integration (like how to authorize with google/facebook apis) or using existing providers (like solutions for popular frameworks), but I am having a hard time finding info on building a solution on top of a pre-existing user/pw db.
Can someone please outline the bullet points of exactly what it needs to do in order to extend the existing system to provide oauth2 authorization? i.e. the existing system already provides registration, password recovery, login, forgot email - all that stuff without a framework (golang and password is hashed with first x bytes as salt, in case it matters). I don't want to toss it all out in place of an out-of-the-box solution which covers all that + oauth2. I want to add oauth2 by hand (or using minimal golang libraries) on top of the existing system.
I'm currently trying to reverse engineer and look at existing code, but it's a bit confusing and when it comes to authorization/security stuff I don't want to be making guesses, even educated ones. Could look at the spec too but I don't really need cover everything in there, just the bare minimum to let another site authenticate (by calling a "getprofile" API after authorized, maybe I'll make that compliant with openid connect but never mind that for now unless there's no increase in steps).
Sample code or libraries if any are preferred in go-lang since that's what I'm building in, but pseudo-code or vanilla code in other languages is fine too
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.