In learning WCF, I'm a bit confused where to go to figure out how I should be handling user authentication. My MVC 2 app uses an Active Directory Membership Provider and this works and is good, but my MVC app doesn't really do anything but call my WCF services. My business logic on the other side of WCF is what really does everything (as it should be).
How should I be handling authentication with WCF? Can I somehow have my MVC calls to my WCF services kinda impersonate my users' AD accounts or something? And yeah, I know I can do identity impersonation, but what is the right way to do something like this? My business logic is what needs to really do the heavy lifting when it comes to deciding what data and functionality a user can have.
We have decided to use the Identity Stack Propagation in iDesign's ServiceModelEx library. This allows us to track what user has logged in via Forms Authentication on the Service side without having to impersonate anybody.
Related
My team currently uses WebForms for projects, but I'm trying to convince everyone to switch to MVC. One of the problems that I'm running into is with authentication. I can't figure how to to implement our login process to work with MVC.
Our authentication is done via mostly a web service (we pass username & password and are told if it is valid or not), but occasionally we use ActiveDirectory for logins.
Right now we are using sessionstate to store information about the logged in person. How would I translate this to ASP.NET MVC? I've read a lot about various things -- Claims, Roles, MembershipProvider, IProvider, ASP.NET Identity, OWIN, but ASP.NET has been evolving so rapidly that I'm afraid that I'm reading old information on StackOverflow.
Right now we are using sessionstate to store information about the logged in person.
Don't do this. Ever. Not in WebForms, or MVC. It's highly insecure and easily spoofed. Session should never be used for anything to do with Authentication or Authorization. Plus, Sessionstate is volatile, and IIS can dump your session at any time, losing synchronization with your authentication.
The solution to your problem is very simple. You already have the authentication in your web service (though I question whether this would be secure either, given your Sessionstate authentication methods, but that's a different argument). All you need is the Authentication portion, which is easily provided by FormsAuthentication to set the cookie to allow logins.
You Validate against your service, if you succeed, you call FormsAuthentication.SetCookie(), and then you add [Authorize] to all the MVC action methods you want to protect. It's really that simple.
If you need to have information available about the user, then you would create a custom IIdentity and/or IPrincipal implementation that provides that information, making it secure (secured by encrypted cookie) and easy to access.
I have an app that uses my own membership system. It uses ASP.NET MVC 3 which I'm updating to ASP.NET MVC 5. It's not possible to change the membership to use a new one like ASP.NET Identity. But, for the authentication side, do you think it is a good idea to replace my auth-ticket system with OWIN.Security? Are there any traps that I should know about?
The Katana security middleware is independent from ASP.NET Identity. You can use them both or just one.
There are some cases where it makes very good sense to use just the Owin/Katana middleware, but not involve aspnet identity.
I just rolled up a prototype webforms application using OpenID Connect against an Azure Domain. My domain is Federated with an on-prem ADFS. By the time I got OpenID Connect and the GraphAPI working, I realized that I didn't really need much from aspnet identity.
I use the GraphAPI to grab extra info about the user and their group memberships, and I am adding that info as claims on the user principal... my site's code can operate against just the information in the claims.
Of course, if you want to do any custom profile or role stuff in your application, it probably makes sense to link it to aspnet identity too.. create an aspnet identity user when a new user authenticates, map that user's AD groups to roles, etc. Then you can manage application specific data for the user directly in the application via aspnet identity, while relying on Azure AD for the core authentication, basic profile, and group/role assignments.
The "dream" is to use WindowsAuthentication for an intranet site. However, we need to hit a 3rd party service to determine if the user has "permission" to use the site, thus "Roles". I have seen many examples that show how to add roles to the identity but they are all on "per request" basis. I don't want to do that. I would like for the user to hit the site once, I determine if the user has the permission, and add the role to the identity. The identity (with the role) sticks around for the session. I also don't want to have to cache users and their permissions. Is this doable or am I missing something?
Thanks.
The solution is to write your own Authentication and put caching in the middle. It is really easy to do as I have two methods of doing it.
Pre ASP.NET MVC 5
http://tech.pro/tutorial/1216/implementing-custom-authentication-for-aspnet
ASP.NET MVC 5+ OWIN
http://www.khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown-part-deux
My posts describe the basics of writing your own authentication, but it is pretty easy to integrate a third party service once you understand the basics. Hope that helps :)
I have a requirement for project to build a ASP.NET MVC4 (razor engine) "Front-end" and a WCF service as "backend" (with a sql server 2012 database).
A requirement is to login, register etc. I want to put this logic in the backend, but in the front-end I would like to make use of the [AllowAnonymous] and the logic to authenticate a user with roles (for example use of formauthentication, webmatrix.WebSecurity, Membership provider?).
Is it possible to realize? Do I have to create a login and register (and roles etc.) features by myself? Or can I use a built-in features/libraries of the ASP.NET MVC or WCF? Or both?
Could you give some examples/suggestions/tutorials to realize this?
Thanks in advance
I think this should work for you:
http://msdn.microsoft.com/en-us/library/bb386582.aspx
Edit: To elaborate you can use custom logic for WCF authentication including calling the ASP.NET membership providers which should work fine with MVC and the security attributes you mentioned.
Or is the WCF service on another server and you want to call from your ASP.NET controller to your WCF service for authentication? This is a bit more complex, but you should be able to do it by implementing your own Membership provider.
Depending on the scenario you can reuse some or all of the login and register views that come with MVC.
Edit: In the second scenario here are some pointers that might help:
http://singlesignon.codeplex.com/ - Seems to be what you need, but I didn't check out the code.
Custom membership that uses web service for authentication - No code, but it confirms that it should work.
I have been reading up on the .Net RIA Services that Microsoft is developing for use between Asp.Net and Silverlight applications, and it looks quite nice. I am curious about how it handles keeping track of authentication:
How does the Silverlight client keep track of who is logged in, and when they have timed out? And it shouldn't keep the password stored in memory, right?
How does the server side know that whoever is making a request (to a WCF service or other) is authenticated? I'm sure the user name and password isn't being passed around after the initial log in. Is there a token being passed around?
Last question, does authentication still work the same if you have your Silverlight app running out-of-browser, installed to the desktop?
I'm pretty sure the RIA services are closed source right now, but I'm hoping someone is familiar enough with the topic to have some ideas. Thanks!
All of the authentication is taken care of by the usual ASP.NET plumbing. RIA Services adds some interaction pieces through the ApplicationContext but the underlying security is still ASP.NET's usual security.