To be clear, I am aware that the Identity model does not implement anything to do with the membership provider model.
Since MS seems to have abandoned the MembershipProvider model in their latest web code and Visual studio as too limited, and I have to admit that it was often frustrating to work with, it seems they would replace it with something that, at least, out of the box did what a standard membership provider could do out of the box.
While there's certainly a market for claims-based authentication and authorization, simple authentication and role-based authorization still work quite well for a great deal of web applications... especially business applications that, for security/ audit reasons, users should NOT be allowed to register for, but rather be provisioned upon verification that all the proper steps have been followed.
With the Membership Provider, you could add users, assign roles, etc., right from within Visual Studio. I don't see this sort of thing available any more, and it baffles me that MS would think that such a style of provisioning would no longer have value.
I'm building my first MVC5 application, and I find myself seriously considering ripping this stuff out and going with something that I know works, but I really don't want to put obsoleted tech into a brand new project.
Is there any documented way to explicitly provision users and assign roles like what was available in the MembershipProvider, preferably within Visual Studio? I'm not suggesting it has to be exactly the same, or use the same interface, but at least have the same capability... i.e., create new users in a database, and assign roles to them.
Have a look on MembershipReboot from Brok Allen. I have not used it myself, but it sounds promising. He also started IdentityReboot that is also looks like an alternative to MS library.
Related
I needed a quick web application users handling in my Blazor project. So I went with Microsoft.Identity and the scaffolding feature in Visual Studio.
However, at least in VS 2019 it doesn't work perfectly. It does require many manual tweaks, the code produced is ugly to my taste, it leaves a lot of "foreign" code in my project.
I have no easy way to customize its style and behavior to my application without editing a lot of files. CSS is not enough. A simple example: I wanted my users to be logged by their user name, not the e-mail, however the e-mail is required by registration. What's more, the user name is the primary key in the User entity since I needed it while importing the previous company database. I wanted the forms to be localized. I already made it, but is there a simpler way?
Do you know a library or a NuGet package to make this task easier and quicker? It would be nice if it supported various log on methods, like logging via Azure or Google or a kind of 2FA.
The requirement is my User entity is completely custom. Its primary key can be an int, a Guid or a string. Many optional properties, depending on the application. Microsoft.Identity satisfies all the requirements related to the backend, but it doesn't have a "proper" front end for Blazor. The scaffolding feature of VS provides a makeshift UI, but it's far from being the "real solution".
I wonder if not write such library myself, but it would be a huge waste of time if such thing is already available somewhere and I just don't know about it.
I'm starting a new project and I'm also a little bit of new to ASP.NET and WCF services and right now I'm trying to understand the logic behind the ASP.NET login and registration functionality but I can't seem to figure it out exactly.
I want to make a WebApp using N-Layer architecture and I want presentation layer to be completely data-free and the default ASP.NET registration-login functionality doesn't let me do that since it access the database directly, at least not through some logic I want to do myself. What I'd like to do is to continue using the register-login functionality but instead of fetching for data directly to the database, I want it to be fetched from a WCF service, but I can't seem to find how to configure the register-login to do so.
Any idea where to start reading? I've read something about WCF Authentication but that doesn't seem to be what I'm looking for.
Thanks in advance
There isn't as far as I know a WCFMembershipProvider or similar. This means that if you want to use build-in security features of ASP.NET you will need to create your own MembershipProvider.
Take a look at this tutorial it guide you on this process:
How to build a custom membership provider
For this case, you would need to implement your own membership provider to use the service you have as the backing for authentication.
MSDN has resources on how to do this.
Additionally, you may want to ask yourself WHY you want this service to provide authentication. What value does it give you? Keep YAGNI and DRY principles at the forefront of your mind while thinking about it.
#Dalorzo beat me to it
What is for sure, the more I read about WIF, the more I get confused about how to do things.
For something that was supposed to ease things, I can't imagine how it would be without. I guess there's too many scenarios and I have hard time to find the one that fits me.
For some (good for my point of view, but maybe bad) reasons, I want to avoid a official STS (ADFS or ACS) and then write my own to keep things simple!
What I'm looking for is being able to deal with Users (that I'll wrap from an AD identity), Groups of users (custom) and Roles that get users/groups assigned to (custom).
I want to decorate my client side methods with the ClaimsPrincipalPermissionAttribute (or a declarative equivalent) to check if the current user has the required role. I want to be able to use that from a Windows Client application or a WCF Service hosted on IIS/WAS (Net.tcp is my preferred choice of binding).
Some guidance will be greatly welcome as I'm tired to read on an on WIF materials without any improvement of how the solution could be shaped.
Thank you !
So first of all - there is no such thing as a simple STS. I hope you realize that an STS is criticial security infrastructure and probably should not be your first WIF project. If you want to have a look at an open source STS to get some ideas have a look here: http://thinktecture.github.com/Thinktecture.IdentityServer.v2/.
Next authZ happens on the server side (client side is usability). Simply roles checks are rather done with PrincipalPermission. ClaimsPrincipalPermission encourages you to separate service and security code - look up ClaimsAuthorizationManager for more information.
I'm working on a internal web application (only employees can log in) and need some help figuring out a good approach to handling an individual users permissions to the system.
The system itself is in C# / ASP.NET (4.0 / Webforms / Forms Authentication) / SQL Server 2008 and has several different areas which will have varying sets of permissions. You can think of it in a basic crud scenario (create, view, update, delete) though those would apply to different aspects of the system.
(I do want to mention this isn't a type of CMS system, so I can't pick an Open Source Project like DotNetNuke or anything. This is being developed from scratch. I can use open source libraries if they are available though.)
What would be a good approach to designing the User Permission system for a complex system with probably 5-6 different sections that have a good 10-15 different view/update/deletes contained in each section?
The goal here is to make it:
Understandable for Users (Admins) to use / set up.
Easy to Maintain Code Wise.
Easy to adapt as new permissions are needed (different types or in different spots).
There are two approaches that come to mind:
Approach 1:
Try to use the built in ASP.NET Roles system to define the different permissions and manage it from there. I could build custom pages to handle the different areas and assign permission sets to users. I believe that would also allow me to use the current session object by default to contain all of the permissions in the system for a user. (HttpContext.User.IsInRole() etc...).
Now, while I think that method would work, I'm not sure it's going to be easy to maintain or adapt to future needs. It seems like it'd be the quicker way to get it up off the ground and working but not the best long term.
Approach 2:
Roll my own. In this scenerio, I'd set up database tables to store true/false style permissions for each section of the application. Then I'd retrieve that information and place it in the session and basically access it anytime I need to check if someone has permissions to do something. I'd then build the custom pages to manage the lists, etc..
It seems this approach might be the more maintainable long term solution. It gives me more power in the set up and how it is handled. However, I'm basically still doing the work that the Roles system abstracts away for me in approach 1. I favor this over approach 1 still however.
In the end, I'm not sure if either approach is the best way to handle this. Can anyone help explain to me why either of the above would be good / bad? Or even to suggest a different alternative as to the "best" way to handle it in general would actually be. This is my first major undertaking in this area, so I don't have a great deal of experience in trying to "secure" an application like this by permissions. Any and all help is appreciated!
Use the built in approach, unless you've a specific architectural need not to. If you don't use the built in one, you can choose to roll your own provider implementations, but you should follow the same templates as the build in system, as it covers a lot of the security caveats that you should think about.
There's even the built in configuration page for quick and dirty user maintenance.
I would stick with the built in approach, you can always write a custom RoleProvider to match the roles and permission you need for your user base see (Implementing a RoleProvider)
My new assignment at work is to create a second version of our existing web application. Currently, our application supports only full time brokers, but now we our launching a second site specifically for part time brokers.
The new site will be almost identical to our existing site with the following exceptions:
It will have it's own branding.
A couple of the user controls used for displaying information will be different (but none of the pages will be different).
Our existing users should not have access to the new site and vice versa.
It needs to be easy to test both versions of the website from within Visual Studio easily.
We want to reuse as much our existing code as possible.
I have 2 weeks to do this.
I'm hoping that this is a common scenario and someone out there has some advice for how to accomplish this.
I really, really don't recommend branching projects or other routes which involve copying what is essentially identical code with the exception of branding and authorization. It will certainly be easier in the short run but, as you said, will become a nightmare very quickly trying to maintain almost-identical code bases.
Your pages can make the decision on what controls to show based who is logged in or even set globally to indicate this is the part-time broker version of the application. You could have a set of views and light logic to handle part time vs. full time brokers. Since the sites are deployed separately, a config setting would be straightforward. If you have other versions of the same site, you may have to give this some thought to ensure it would scale with your other variations.
I would even use the same database as long as you can separate the data appropriate using claims-based (preferred) or role-based authorization or similar.
All this said, there does not seem to be any great reason why you'd want to deviate from using the same code base.
I would create a branch of your code and then work against that. This is of course assuming that you are using version control. You are aren't you?
My first thought would be to
copy the entire source code to another IIS website
script the database over to another database (fresh start for new website)
make necessary adjustments to usercontrols and branding
roll out the new site (as Beta)
In Visual Studio, you can create a new project inside the same solution so that you have access to both projects at the same time.
If you're using Version Control... create a branch, and start customizing from there.
what this will do for you is give definitive separation between the two sites... no users have access across sites, all future customizations will be on a per-site basis, etc.
While I really like the idea CaptainTom posted another solution would be to break off the display layer of your application from the rest of the logic and create a new project that implements the new user experience while sharing the rest of the code
i.e. a FillTimeBrokers project and a PartTimeBrokers project with both implementing their logic from a common Brokers project.