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.
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.
I am building an ASP.net MVC web application and I am starting to look into security.
What would be the best way to identify the user on subsequent requests (after they have logged in). I'm thinking of some form of authentication token or maybe using a cookie?
Ive read about Forms-Based Authentication but I'm not sure what would be a good approach?
This is a very broad question and there are many ways to answer it. I would recommend that you learn the basics of identity and access in ASP.NET by reading each topic in the ASP.NET Identity section and understanding what options you have. At a basic level, you need a mechanism to register users in a repository/database of some sort, validate their credentials when they log in, and a way to persist their user session in a browser (such as via a cookie). All of this is discussed in that section with examples.
The good news is that there are many valid authentication options that are pretty easy to implement and don't require you to be an expert on security. You can create/maintain your own member database, use Windows authentication, outsource authentication entirely to external identity providers such as Facebook/Google/Azure Active Directory/etc, and so on. The new tooling in Visual Studio 2013 also makes this much easier for you to manage. I would highly recommend you familiarize yourself with all of these options before jumping in and writing any code.
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.
Are there any decent examples of the following available:
Looking through the WIF SDK, there are examples of using WIF in conjunction with ASP.NET using the WSFederationAuthenticationModule (FAM) to redirect to an ASP.NET site thin skin on top of a Security Token Service (STS) that user uses to authenticate (via supplying a username and password).
If I understand WIF and claims-based access correctly, I would like my application to provide its own login screen where users provide their username and password and let this delegate to an STS for authentication, sending the login details to an endpoint via a security standard (WS-*), and expecting a SAML token to be returned. Ideally, the SessionAuthenticationModule would work as per the examples using FAM in conjunction with SessionAuthenticationModule i.e. be responsible for reconstructing the IClaimsPrincipal from the session security chunked cookie and redirecting to my application login page when the security session expires.
Is what I describe possible using FAM and SessionAuthenticationModule with appropriate web.config settings, or do I need to think about writing a HttpModule myself to handle this? Alternatively, is redirecting to a thin web site STS where users log in the de facto approach in a passive requestor scenario?
An example of WIF + MVC is available in this chapter of the "Claims Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
I do suggest reading the first couple chapters to understand all underlying principles. This blog post covers the specifics of MVC + WIF:
Link
Controlling the login experience is perfectly fine. You should just deploy your own STS (in your domain, with your look & feel, etc). Your apps would simply rely on it for AuthN (that's why a app is usually called a "relying party").
The advantage of the architecture is that authN is delegated to 1 component (the STS) and not spread out throughout many apps. But the other (huge) advantage is that you can enable more sophisticated scenarios very easily. For example you can now federate with other organization's identity providers.
Hope it helps
Eugenio
#RisingStar:
The token (containing the claims) can be optionally encrypted (otherwise they will be in clear text). That's why SSL is always recommended for interactions between the browser and the STS.
Notice that even though they are in clear text, tampering is not possible because the token is digitally signed.
That's an interesting question you've asked. I know that for whatever reason, Microsoft put out this "Windows Identity Foundation" framework without much documentation. I know this because I've been tasked with figuring out how to use it with a new project and integrating it with existing infrastructure. I've been searching the web for months looking for good information.
I've taken a somewhat different angle to solving the problem you describe.
I took an existing log-on application and integrated Microsoft's WIF plumbing into it. By that, I mean that I have an application where a user logs in. The log-on application submits the credentials supplied by the user to another server which returns the users identity (or indicates log-on failure).
Looking at some of Microsoft's examples, I see that they do the following:
Construct a SignInRequestMessage from a querystring (generated by a relying party application), construct a security token service from a custom class, and finally call FederatedSecurityTokenServiceOperations.ProcessSignInresponse with the current httpcontext.response. Unfortunately, I can't really explain it well here; you really need to look at the code samples.
Some of my code is very similar to the code sample. Where you're going to be interested in implementing a lot of your own logic is in the GetOutputClaimsIdentity. This is the function that constructs the claims-identity that describes the logged-in user.
Now, here's what I think you're really interested in knowing. This is what Microsoft doesn't tell you in their documentation, AFAIK.
Once the user logs in, they are redirected back to the relying party application. Regardless of how the log-on application works, the WIF classes will send a response to the user's browser that contains a "hidden" HTML input that contains the token signing certificate and the user's claims. (The claims will be in clear text). At the end of this response is a redirect to your relying-party website. I only know about this action because I captured it with "Fiddler"
Once back at the relying party web site, the WIF classes will handle the response (before any of your code is run). The certificate will be validated. By default, if you've set up your relying party web site with FedUtil.exe (by clicking "Add STS Reference in your relying party application from Visual Studio), Microsoft's class will verify the certificate thumbprint.
Finally, the WIF framework sets cookies in the user's browser (In my experience, the cookie names start out with "FedAuth") that contain the users claims. The cookies are not human readable.
Once that happens, you may optionally perform operations on the user's claims within the relying party website using the ClaimsAuthenticationClass. This is where your code is running again.
I know this is different from what you describe, but I have this setup working. I hope this helps!
ps. Please check out the other questions I've asked about Windows Identity Foundation.
UPDATE: To answer question in comment below:
One thing that I left out is that redirection to the STS log-on application happens by way of a redirect with a query-string containing the URL of the application the user is logging in to. This redirect happens automatically the first time a user tries to access a page that requires authentication. Alternatively, I believe that you could do the redirect manually with the WSFederationAuthentication module.
I've never tried to do this, but if you want to use a log-on page within the application itself, I believe the framework should allow you to use the following:
1) Encapsulate your STS code within a library.
2) Reference the library from your application.
3) Create a log-on page within your application. Make sure that such page does not require authentication.
4) Set the issuer property of the wsFederation element within the Microsoft.IdentityModel section of your web.config to the login page.
What you want to do is an active signin. WIF includes WSTrustChannel(Factory) which allows you to communicate directly with the STS and obtain a security token. If you want your login form to work this way, you can follow the "WSTrustChannel" sample from the WIF 4.0 SDK. Once you have obtained the token, the following code will take that token and call the WIF handler to create a session token and set the appropriate cookie:
public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}
Once you have done this, your site ought to behave the same as if passive signing had occurred.
You could use the FederatedPassiveSignIn Control.
Setting your cookie like this:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens't work for SSO to other domains.
To cookie should be set by the STS not at the RP.
I have reviewed some of the similar questions on this site but could not find one with an answer appropriate for my situation.
I am using asp.net mvc, and it is communicating securely with stateless wcf services. for each service call, i need to pass in the username and a few other ints for identification purposes. - not password, the services are not authenticating.
I am using forms auth to authenticate the users. I am just not sure where, after the user logs in, I should store their username and other account details used for the scope of the user's time logged into the site. suggestions for webforms apps include in "Session". Is there an equivilent alternative in MVC? is storing the info in the forms auth cookie the best solution? it seems like it would be slow to have that info in a cookie as opposed to somewhere else in memory..
thanks
If you need access to a select few bits of information about the current user over and over again, you could combine FormsAuthentication with a custom principal implementation.
The Forms authentication mechanism will write a cookie to your client's disk, and will recreate the custom principal based on that cookie for each call. You could e.g. store something like a user "level", a user "profile" or other small chunks of information, which would then be accessible through the HttpContext.Current.User at any time during the lifetime of your request.
Check out these resources on the topic:
MSDN docs on How to Create a Custom Principal Identity
Using Custom Principal with Forms Authentication in ASP.NET
and I'm sure googling or binging for "ASP.NET custom principal" will render quite a few more hits for you!
yes, unless it's a lot of information, the preferred location is to store it in the cookie. Aside from that, session is the next best place.