We developed a MVC 4 Web application with form cookie authorization.
Is a good approach use session variables and authentication cookie together?
Thank you.
I would know if is possible some synchronization between cookie and session timeout. Based in my research it's problematic due to its different lifecycle.
.NET 4.5 has incorporated the Windows Identity Foundation (WIF) as a core part of the framework and has made claims-based security a integral part of it. With claims-based security it easy to add custom information to the identity of the user as a new claim. Dominick Baier has a great training course on this in PluralSight called Introduction to Identity and Access Control in .NET 4.5. You can sign up for a free trial to check this course out. You can also get good information on security in .NET on Dominick Baier's Blog.
Ok, this is my answer. After some research and code testing, the best solution it's always read information from auth cookie.
Use of Session and cookie auth at same time it's hard to control due to its differents lifecycle.
If we have, for example, a valid cookie auth and a timed out session, in the next request we will have a renewed session without any user info.
Related
We have a .Net Web API (v2) serving an SPA that I aim to secure using OAuth 2.
In my OWIN Startup.Configuration(), I set my Provider in IAppBuilder.UseOAuthAuthorizationServer to an override of OAuthAuthorizationServerProvider. I have this successfully providing refresh tokens.
I want to be sure that these tokens cannot be spoofed by someone implementing a similar provider. No searching I have done has given me any kind of answer.
Does OAuthAuthorizationServerProvider ensure that the refresh tokens received are those issued by itself, and not any similar code on a hacker's machine?
My own experiment seems to confirm that it does - I tried the same code running on two different machines and took the unexpired refresh token (with a long expiry of 24 hours) from the other machine, and got a 401 as I'd hope. But just in case I've wrongly convinced myself, I'd like some reassurance and/ or advice from someone who knows more about OAuth in the .Net Web API than I.
Thanks,
Paul
I'm sure I eventually found a definitive answer in the doc for OAuthAuthorizationServerProvider but now can't find it.
However, Dominick Baier, an expert in this field, says:
Access tokens are protected using the machine key. Protection of refresh tokens is up to you. You need to manually set the machineKey element in web.config (otherwise the key gets auto generated and might change over time).
His comment comes from a reply to a post on implementing OAuthAuthorizationServerProvider.
We're developing an API and a single page application (that is one of more possible future consumers of it).
We already started on the web API, and basically implemented a system very similar to the one John Papa made in his course on pluralsight, named "Building Single Page Apps (SPA) with HTML5, ASP.NET Web API, Knockout and jQuery".
We now need to implement authentication and user managing in this application and need to find the easy way out to implement this in as little time as possible as we are in a hurry.
We realized the SPA template included in the ASP.NET update had very similar features to our needs, but we wonder what the best approach to implement a similar feature in our existing code.
We are novice developers, as you might figure.
Is it possible nstall some packages using the package manager, and voila, a simple membership and OAuth auth option be readily available?
Our use case is that we need to protect some resources on our API based on roles, and that one should be able to log in using a username and password, but also log in using ones facebook, google, or twitter account.
Found an interesting talk regarding the subject here: https://vimeo.com/43603474 named Dominick Baier - Securing ASP.NET Web APIs.
Synopsis: Microsoft’s new framework for writing RESTful web services and web APIs is appropriately enough called ASP.NET Web API. As the name applies, this technology is part of ASP.NET and also inherits its well-known security architecture. But in addition it also supports a number of new extensibility points and a flexible hosting infrastructure outside of IIS. There are a number of ways how to do authentication and authorization in Web API - from Windows to usernames and passwords up to token based authentication and everything in between. This talk explores the various options, and puts special focus on technologies like claims, SAML, OAuth2, Simple Web Tokens and delegation.
We eventually went with the SPA template, doing authentication on the API (separate MVC part).
Then the API would generate a unique token and redirect the user to the front-end with the token in url parameters.
The front-end then needs to send this token on every subsequent request.
Have a look here - Identity Server done by the security experts. This is all you need in one package.
In terms of OAuth, you would need to use Client-Side Web Application flow which the access token is issue immediately to the client and can be used.
I've searched the posts and have not found exactly what I'm looking for pertaining to my question. For example Security ... through AD asks more the question is it wise? My question is this:
We are implementing WCF applications and we are now putting WCF ... I mean ASP.NET Web Api ;)
into our server stack. I want to secure the services by requiring that the user log on to ADS, but if they already have logged on (via network login or other means) then I don't request a login. Rolebased authorization then occurs within the services.
I cannot find good discussions or examples of how I handle ADS authorization especilly through all of the future endpoints (tablet and phone).
My one thought was that the user does a login to ADS and the token then becomes what gets handled for security and rights. So now I'm a little bit concerned about how much coding has to be done to accomplish this. We are looking at FederatedServices to handle this in WCF but there is no such control in this weak API.
So I'm interested in any input or direct me to a great article on this. So far all I see is self-rolled security which our old server has and I do NOT want that crap again.
Oh yes, did I mention our target is single signon throughout our web services??? :)
Best place to start is Dominick's Thinktecture Identity for Web API. It is the de-facto security framework for Web API and supports token based identity.
I downloaded the WIF Extensions for SAML2 a few days ago and have been experimenting with them. The samples in the download use a WebForms application, and I am trying to figure out how to use them in MVC3.
I am currently able to auth against the sample Identity Provider that comes with the download, using this:
Saml2AuthenticationModule.Current.SignIn(
"~/sign-on/saml2/success", "urn:samples:identityprovider");
I have an action method at the "sign-on/saml2/success" route / URL, and when the application flow reaches it, the Thread.CurrentPrincipal.Identity is indeed an instance of IClaimsIdentity. Although the Identity.IsAuthenticated equals true, the Identity.Name is an empty string. (This will be problematic in our app, which so far has used FormsAuthentication, and relies on Identity.Name to resolve to a user account in the db.)
I also see that there are 4 new cookies at this point:
FedId
FedAuth
FedAuth1
[fourth cookie name is a GUID, changes for each SSO]
My inclination at this point is to delete these 4 cookies and use the claims NameIdentifier to create a new account in our app (unless one already exists), and then use FormsAuthentication to write a .ASPXAUTH cookie for the user.
The first affiliate IdP we will be integrating with uses Shibboleth, and they do not yet implement SingleLogOut. So my assumption is that the following would have no effect when we begin testing this integration:
Saml2AuthenticationModule.Current.SignOut("~/sign-off/saml2/success");
So, manually deleting the 4 cookies is the only way we would be able to get the Identity.IsAuthenticated back to a false value.
Am I going about this in an incorrect fashion? Are there any implications of trashing the IClaimsIdentity after it has been consumed and transferred to FormsAuthentication, that I am not considering?
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D