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.
Related
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
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.
We currently use WIF to secure our application and back end services. I'm trying to determine if we really have a need for WIF in our solution, or if its just an extra layer that consumes resources without providing any benefit.
Our current application is split up into 2 separate web applications, a Client and Admin and several WCF services. Identity is not shared between the two applications(You have different credentials for admin and client). Identity is only ever shared between the client and the WCF services. This occurs between machines, but never across networks or enterprise boundaries.
We use a third party to perform authentication, however the 3rd party is not used as an Identity Provider. That function is performed inside the application itself.
We currently have no future plans to share identity between other applications or services, or to use a 3rd party Identity Provider, etc.
Given the way our application is setup, do we really gain much from using WIF as an additional means of securing our back end services? If WIF was removed what are we losing?
If you remove WIF, you'll have to replace it with something. Unless you decide that you don't need user authentication and authorization at all. Remember that in addition to authentication, WIF gives you the claims-based authorization model.
Another benefit of WIF is that it's becoming a well-known standard way of securing applications, meaning that when you bring on new developers in the future, they'll likely be familiar with your security model. That's a big benefit. Compare that to a custom security model that you'd have to train the new developers on.
Also, WIF is a proven technology with well-known security benefits. If you implement WIF as recommended, your applications are secured. That's not necessarily true of other models, especially a custom-designed security model.
Also, you say that you currently have no future plans to use the more advanced features of WIF. There's a big difference between not currently having plans and never ever going to do it. With your current WIF implementation, you have the flexibility to add those things if plans change in the future. If you replace WIF with something else, you're giving up that flexibility. Or at least making it much more difficult.
Were it my project, the first questions I would ask are:
Does the existing WIF security model work? If no, then fix or replace. If yes, then ...
Is it causing any trouble (materially affect memory usage, application response, or developer productivity)? If not, then leave it alone. If yes, then ...
Are the benefits of replacing it worth the cost and the risk of breaking something or failing to implement some other feature?
If you have something that works and doesn't impede your ability to improve your application, then any time you spend working on that piece is at the cost of some other feature.
This may have already been asked before but I did not see it anywhere.
Essentially, what I'm looking to do is to have a small C# app (EDIT: or BHO) run and detect when IE (8 or higher) has been launched by a user. Once it has launched, it needs to just sit there until it notices that an authentication challenge popup has been presented from within IE. It would then hide the IE popup and present the user with a custom authentication popup. This new popup would then pass the entered credentials back to IE for authentication.
The app (or service) would cache the credentials and pass them to any further authentication popups received on a local Intranet. So, this is a sort of custom quasi single sign-on solution.
Before people start suggesting changing settings in IE or on the server(s), please know that this is not possible. The above explanation is exactly what we need to do. I don't like it either.
We currently have a small in-house utility written in C++ (not .NET) that handles this exact identical behavior very successfully, but the source code is no longer available for fixes/upgrades.
Anything would be helpful. Thanks all!
FYI - Just saw the first comment. No, this is not a type of malware, pwd spoofer, or similar. The employee gets a customized, company-logo'd credential pop-up to handle everything. The purpose of it is to handle multiple different types of authentications (some are custom) specific to the varying sites within our Intranet.
I finally found and decided upon a solution that is already working as a prototype (very limited prototype). There's still much work to be done, but at least there is light at the end of the tunnel. If I head a different route or receive better suggestions, I'll be sure to update this information. For those whom might ever need something similar (doubtful), here's essentially what I'm doing.
Browser Helper Object
Instantiated with each new IE instance.
Registers with IE to receive events and new windows/controls being created.
Hooks to receive descriptions of controls for logic to decide what to do.
Handles to each authentication dialog windows or control.
Handle to UIAutomation COM to inspect requesting server and realm.
Multi-threaded support capable of thread blocking.
Encrypted credentials cached in memory.
.... and a whole lot more.
I hope that helps anyone needing to do the same. Thanks all for any assistance you could give. I guess everyone is as much of a noob with BHO's as I am.
EDIT 2/14: This is indeed the answer. I have the BHO working as desired. There is still some very minor tweaking to accomplish. (Actually, it's not that minor but it's working.)
Honestly this concept is dangerous. You are side-stepping the security model of the operating system to accomidate lazy users.
The other problem is that your architecture is fragmented. If you have tonnes of workstations across a big organization that don't use a proper platform for unified authentication (Such as AD / LDAP / Etc...) then you're going to run into a very-hard to maintain mess.
What you're doing here is plugging a hole, you're not fixing the crack. I strongly suggest you use this lack of source-code to keep "patching" the system together as the catalyst for change.
If you're so hell-bent on keeping the infrastructure as-is, then you should look to tested & proven software solutions to help aid in keeping things sane for your users.
Take a look at a FOSS Application KeePass. It will allow you to store your passwords securely (a problem your proposal would have to address anyway) and you can have your users store thier DB on a USB-Stick they keep with themselves at all times. They can log in once to thier KeePass DB and use the Auto-Type hotkeys to enter thier passwords in the various login boxes they are prompted for. This can work for more than just IE authentication requests, it can do all your applications.
The nice part about this is you can get people to use relatively strong passwords as they'll only have to remember the one (KeePass DB).
Ultimately you're going to run into issues trying to catch Authorization Challenges, even your existing solution is probably doing it in a very hack-ish way and you're going to find it increasingly hard in the future to continue this behaviour. This is mainly because it's an "IFFY AT BEST" solution, and will likely be made harder to execute as security matures.
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)