I'm trying to implement SAML as service provider in our ASP.NET 4x application using Sustainsys SAML2 but I'm starting to wonder if this is the right way to go.
The application is technically ASP.NET MVC, but we only use one mvc page to load the frontend SPA (angular). As the application is also multitenant I have mostly focused on the OWIN-version of Sustainsys (as the ASP.NET MVC version doesnt seem to support different configurations based on the request). But we also use custom authentication and the Sustainsys library seems tightly linked to the ASP.NET cookie authentication, which I dont know that much about. Is it possible to use this library without ASP.NET authentication?
Yes, it is possible. Hook the AcsCommandResultCreated notification and set the HandledResult flag on CommandResult to true to supress the default handling, including calls to the cookie authentication. Then do whatever you want to do.
Note that you would need to copy parts of the CommandResultExtensions.Apply method to clear the state cookie and apply the redirect.
Related
I had created a login form using MVC 5 No authentication template and connected with MS-SQL local Server, Now I need to verify the login status using session. I tried surfing about it but I can't able to find the optimal solution. So please some one help me to identify the optimal solution.
Unless you are a security expert I would strongly advise that you don’t roll your own authentication.
Most of the documentation you will find on the web for authentication in an mvc app will be referencing asp identity. I would recommend using that unless you have a good reason not too.
Things like using
[Authorize]
On controller actions
And using
User.Identity.IsAuthenticated
To check if a user is logged in is all baked in.
No need to re-invent the wheel
I am build a small web app with all HTML controls and have used javascrip and webservices for all my work.
Now i need to add Login Authentication to my App. Normally i would have done this with ease with Server side code.
FormsAuthentication.SetAuthCookie(strUSername, createPersistentCookie)
But i need to achieve this using purely Javascript and Webservice calls.
function Autheticateuser(strUser,strPwd)
{
Webservice.AuthenticateUser(strUser,strPwd,SetAuthentication,FailAuthentication)
}
But since Javascript is not secure, any one can manipulate this on the browser. How can i make this secure and also keep it away from Server side code.
web service calls are lying open in javascript it can be called by any malicious script easily to try combinations of username and pwd to break into the system.
The forms authentication controller is not very different from a web service. It takes a form post from an anonymous user with id/password and returns a cookie. This can be called by a script just as easily. That's why you build safeguards (lockout after several unsuccessful attempts) for the authentication.
You don't want to use cookies with Web API services. The easiest thing to do for you is to look into MVC5 SPA application or Web API 2.0 authentication. These come with Visual Studio 2013 and .NET 4.5. The web services have built in OAuth token support, which is the proper way to do authentication/authorization for web services. You can do it with earlier versions of MVC, but need to get external libraries for OAuth support.
This is a good video to get into web api security.
I'm currently developing a web application that will use Facebook as a authentication service. Does it make sense to implement it as an ASP.NET Forms Authentication custom membership provider? While I made my research, I didn't come across any concrete significant advantage of using the Forms Authentication. However, it instinctively seems to me as a good thing to do, because aside from creating a completely custom implementation of authentication using Facebook, I didn't find any extensibility point inside ASP.NET where I could plug in the Facebook auth behavior.
Can you then tell me whether the Forms Authentication is a good idea or not. And if not, is there any other way than completely custom code (I'd like to avoid managing the session cookies, loading the current user, etc. manually).
I'm using ASP.NET MVC 3, Entity Framework and I'd like to avoid the Facebook C# SDK (the extensive use of dynamic types is a bit of a turnoff for me :-) ).
Thanks for any advice.
A simple answer is to use .NET 4.5 oAuth templates, they are incredibly easy to link Facebook up to forms authentication.
http://www.asp.net/vnext/overview/videos/oauth-in-the-default-aspnet-45-templates
However you may struggle to find a decent server if you are planning on releasing immediately. In a couple of months plenty of servers will support .NET 4.5.
The OAuth templates work for both v4.0 and v4.5 so you can publish them onto a server today itself :)
I'm currently working on an application that will likely be deployed amongst various organizations within my current workplace. I need to develop a testable and properly designed authentication framework so that for each implementation folks can choose to use either Windows Authentication, Forms Authentication, a home-grown Single-SignOn system OR OpenID.
So given ASP.NET MVC (and in particular I'm using the S#arp Architecture framework) how should I go about doing this?
Ideally it would be nice if folks can simply make changes to the web.config file in each case.
Thanks
ASP .NET MVC supports ASP .NET membership provider, making it easier for you to handle Windows/Forms Authentication without any hassle. As long as you specify the required information on the web.config. The default site comes with an example.
For other options of implementation, Kigg has an OpenID implementation which also includes the unit testing code.
I guess that after learning how those work you'll find a way to include your "home-grown Single-SignOn" authentication framework :P
Update:
In order to use the membership provider using your own users table, you must implement a custom provider. The configuration through the web.config will be available anyways, but you'll need to create a class which implements the MembershipProvider abstract class.
Here's a link to a video and some source code explaining how to achieve this.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx