I'd like to use LiveID on an ASP.NET MVC site. Should I still use the ASP.NET Membership provider? How about the default MVC Account controller? I have things working without either, but:
Using the Membership controller lets me see when a user last logged in.
Using the Account controller makes setting authentication cookies a bit easier.
Thoughts?
Answered here before, Peter Bromberg has a nice sample. You would still use the Membership provider albeit as a custom provider.
Related
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.
How do you now configure the membership, profile and role manager using the new MVC template with DotNetOpenAuth enabled? I don't see the configurations in the web.config so how do you now implement a custom profile provider?
With the new MVC4 template, it is very relevant. Instead of using a specified ProfileProvider:Profilebase, all authentication is handled by OAuth and Webmatrix.Security. Out of the box, it doesn't look like there is any support for extending Profilebase. Instead it looks like you will have to create your own table to hold any custom profile attributes. Take a look at this: http://www.asp.net/web-pages/tutorials/security/16-adding-security-and-membership.
See the solution for MVC 4 and built in oauth support/discussion:
See for plugging custom OAuth/OpenID providers.
MSDN has a detailed article explaining how to implement a profile provider. All that you would need to do differently is plug in DotNetOpenAuth.
Profile and role managers are independent of the mechanism used to authenticate the user and are therefore irrelevant to DotNetOpenAuth. Only the Membership provider would be impacted by your use of DotNetOpenAuth, and this question has been asked and answered.
I'm new to the ASP.NET world. Since I want to use the ORM it seems I would want an Entity to represent the User or Member or whatever, not some data tucked away by the forms authentication api. In fact I don't see how I can live without one.
How do people deal with this? Roll your own authentication? Or is there a best practice for incorporating forms authentication with the Entity Framework?
In short, since I need a User and Role Entity for queries anyway, should I skip the forms auth or find a way to use it?
Thanks
EF and Forms Auth are really two different areas. You can use Forms Auth without ASP.NET Membership very easily and roll your own provider with very little effort.
This tutorial will show you how:
http://msdn.microsoft.com/en-us/library/ms172766(VS.80).aspx
With ASP.NET MVC you should really use standard Auth since you can manage access to controllers using attributes for Roles very easily.
FormsAuthentication on its own does not care about the identity store and can validate only credentials stored in the web.config <credentials> section, through the Authenticate method. Standard implementations of the login page use the static Membership class to manage the identities and credentials in the MembershipProvider specified in the config file (usually SqlProfileProvider).
However, you don't have to use the membership provider functionality of ASP.NET to maintain your identities and you can still use FormsAuthentication just fine. The forms authentication control flow shows that forms authentication deals primarily with creating and maintaining the auth ticket for the user in a cookie. It does not deal with the user identity or profile itself, as it does not care about those.
Thus, you can safely use EF to maintain your user profiles, including credentials and do authentication of the provided credentials in your login page, while still using FormsAuthnetication.
If I have an ASP.Net MVC applicaiton where users can only access via an NTLM authenticate account, do I need to use ASP.Net Membership services and issue cookies?
Or do I have completely the wrong end of this particular stick?
You never have to use the asp.net membership provider, it is just an option. If all you need to do is authenticating the user, NTML works just fine by itself. If you need to use the user's identity for further authorization or personalization on the site you need to use some sort of user management, but it doesn't have to be the membership provider, you can write your own or your own.
I doesn't make any difference whether you are using mvc or web-forms.
Is it possible to use the commom ASP.NET role's configuration on an ASP.NET MVC application?
Thanks!!
Yes. ASP.NET MVC and ASP.NET Web Forms can both use the role configuration that ships with ASP.NET.
Yes! The role provider just provides a set of common contracts to manage users and groups ("roles") they are in. Everything works the same in MVC as in traditional WebForms - once the user is identified via login or however you handle that (authentication provider and membership provider), any role-specific code you write will work in either.