I'm using Asp.net c# language programming.
What is the best way for authenticating web methods in a web service?
Is it right having authentication for every web method and verify user name and password for each web method?
Is there a way to authenticate just once not for every web method? something like using sessions and etc?
You might want to look into this one:
http://weblogs.asp.net/cibrax/archive/2006/03/14/implementing-a-secure-token-service-with-wcf.aspx
Edit
If you are bound to only use asmx for some reason, then I would also suggest looking into WSE from MSFT.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=018A09FD-3A74-43C5-8EC1-8D789091255D
You can pass around a token from your client into the web method. The token is encrypted with public/private keys.
For more info here:
http://msdn.microsoft.com/en-us/library/ms996931.aspx
First of all, you should be using WCF for web service development unless you're stuck at .NET 2.0.
Secondly, you can use Windows authentication or Basic authentication over https, but those restrict you to users who are Windows users. If you have a separate set of users, then you will need to do your own authentication.
You can use SOAP Headers so that you don't need a username and password in every web method.
Related
I'm very new to the identity management world, so please spare me. :)
What I would like to do, is to have multiple client (MVC) applications that talk to a single Web API application to authenticate their users against. In that Web API application, I would like to use ASP.NET Identity to talk to a database with users.
That way, I could use SSO for the client applications (I guess).
Does that make sense? Could someone help me on my way to implement this (links are also welcome of course)?
I don't know if IdentityServer could help me with what I want?
And as a side question: when I could implement this the way I would like to, how do I deal with the same-origin policy?
Thank you for all the help. :)
I did some research myself during the last few months and I learnt a lot about the identity management stuff. Many of that also thanks to the guys from IdentityServer (and their other projects).
What I finally did was the following (very briefly):
IdentityServer is used as a provider for all client applications. The cookie and OIDC middleware are used.
I used the ASP.NET Identity user service to store the users in an SQL Server database. (The IdentityServer configuration is by the way also stored in a database.)
I set up a Web API service that uses the ASP.NET Identity user manager for user configuration (change password, create new users, ...). It uses bearer authentication with the application with IdentityServer as provider.
As a side note, IdentityManager is used as an internal admin tool to manage all the users.
If anyone is looking for some help setting up his / her identity management system (and thinks I can help): please ask. ;)
Many articles on active profile e.g. Federated Security: How to setup and call a WCF service secured by ADFS 2.0. But that article assumes you want to use AD?
I'm guessing you want to use ASP.NET Identity for the provisioning?
IdentityServer OOTB supports a SQL DB and has basic user provisioning built in. It allows users to authenticate against the DB and supports WIF.
This scenario is also close to what you need, take a look at the answers:
How to implement an OWIN Authentication server with a MVC Web Api content server and an Android end-user apk
I also recommend reading this article:
Decouple OWIN Authorization Server from Resource Server
Development Environment: Windows 7 Enterprise with
.NET 4.0 with Visual Studio 2010
Production Environment: Windows 2008 Server with IIS 7.0
I'm trying to figure out the best way to authenticate and authorize against a WCF service running on a separate machine in a separate security zone from the ASP .NET web application.
Users log in with a username and password against credentials we have stored in a database. We did not implement Membership Provider, but when the user's credentials pass mustard, we manually create a Forms Auth ticket with the user id.
I did roll my own Role Provider that implements RoleProvider. As a result, we have "standard" ASP .NET roles along with a forms auth ticket working on our ASP .NET web application.
What I need to do is somehow pass these credentials along to the WCF service that's sitting on another machine. Originally, I thought I might use the Windows Identity Foundation and create a custom Security Token Service (STS). Basically, if the user authenticates, then create a token and add in the claims based authorization along with user identity into the token and pass that along to the WCF service.
We are currently using a .NET Remoting service (.NET 1.1 timeframe) that does not authenticate or authorize at all.
That seems like it might be a bit of overkill as there might be a way to simply pass along the information I currently have with the user as when you create the Forms Auth ticket, I know the current IPrinciple is set with the IIdentity set with a "name" property set to the user id on the Thread.CurrentIdentity.
I'm pretty sure IsInRole("WhateverRole") would work correctly at this point too, but all of this is on the Web application side. Nothing gets passed to the .NET Remoting service.
Looking at these two classes:
AuthenticationService Class
ServiceAuthorization Class
I don't think they are what I want. Likewise, I've read through Michele Bustamante's Learning WCF, but I don't really see this particular scenario covered. When I read about Windows Authentication, I keep thinking that needs to be tied into some internal NTLM or Kerberos associated with the internal Windows security situation. None of our users are internal users. They're strictly external.
Now, I know that if the user gets a Forms Auth ticket, they essentially get a valid IPrinciple and the roles should be set, right?
If so, is there a way to pass this along to a WCF service setting on another machine? If I set the WCF clientCredentialType to windows and set the serviceAuthorization principlePermissionMode to "UseAspNetRoles", will these be passed along in the security context from the web application to the WCF service when I make the service call?
Nothing I can find is clear on how this might happen. Thanks.
I think what you want is this:
http://thoughtorientedarchitecture.blogspot.com/2009/10/flowing-aspnet-forms-authentication.html
This isn't super secure, since you're effectively creating your own man-in-the-middle attack, but it's probably secure enough for most needs.
Essentially this boils down to this:
Configure both servers with the same MachineKey
Grab the FormsAuthentication cookie from the user request
Attach the cookie to the outgoing WCF service call
???
Profit
I'm calling a WCF service from an ASP.NET application. From this, I am accessing a WCF service using WSHTTPBinding. I can get the current user from HttpContext.Current.User.Identity.Name. I want to be able to pass this to WCF (not using a custome header - surely there is a proper way to do this.) It must be the identity in HttpContext.Current.User.Identity.Name and not WindowsIdentity.GetCurrent().Name, as this service may be consumed from ASP.nET applications that use Forms or Windows authentication. From what I understand, it should appear in ServiceSecurityContext.Current.PrimaryIdentity.Name. I have search for ages to try to find the answer to this but have not yet found it.
Have a look at Username Authentication :)
http://codebetter.com/petervanooijen/2010/03/22/a-simple-wcf-service-with-username-password-authentication-the-things-they-don-t-tell-you/
I have an ASP.NET web service that I can access via a windows program but now I want to secure the web service. I can secure the web service using forms authentication. How do you access the secured web service from a windows forms application?
Although this is not the right approach, tt is theoretically possible to use forms authentication in the manner you describe. This could be accomplished by either:
Using a WebRequest to send your requests in raw form to the web service. This will involve inspecting the response, extracting the relevant forms-authentication fields, and sending a response back which logs the user in. This will generate a cookie which you must send along with each subsequent response to the service
Generate the FormsAuhentication authentication cookie yourself. This is complex as it involves synchronising the machine key on the calling application, and artificially manipulating the headers being sent to the machine hosting the service.
Display the forms-authentication form for the user to log in to at the beginning of a session requiring interaction with the web-service. You can then harvest the generated cookie and present it to the service in HTTP headers as in option (2).
As you can see, these methods are highly complex, and are fundamentally a hack to use forms-authentication where it was never intended.
Microsoft intended us to use either Windows authentication, or SSL certs to secure access to ASP.NET web services. See HTTP Security and ASP.NET Web Services on MSDN.
If you are able to use WCF, then a few more options present themselves, including the ability to build a custom authentication mechanism into the SOAP, with some support from WCF.
For the most part, securing web services is one of the trickiest parts of the job. Many live solutions which I have seen are compromises such as the ones above.
It seems the answer is no. Forms authentication is a cookie-based mechanism, and your WinForms app won't be able to hold and relay the cookies (without some serious workarounds, if at all).
A potential workaround that I wrote up when researching your question attempted to use a NetworkCredential object, but that didn't work. Also tried was the ClientCredentials in .NET 4.0.
var ss = new MySecureWebService.MyServiceSoapClient();
ss.ClientCredentials.UserName.UserName = "abc";
ss.ClientCredentials.UserName.Password = "123";
string asmxReturn = ss.HelloWorld(); //exception returned here
The console app was still presented with the login html page when calling the webmethod.
Other Suggestions
If you have the source to your web service, extract its logic out into an assembly of its own. Reference that assembly in your WinForms app, and it's just as if you're calling the web service.
I understand that your goal is to reuse the app that's deployed, but the next best thing would be to use the same logic/implementation via .dll reference.
This might help: http://dotnetslackers.com/articles/aspnet/Securing-ASP-Net-Web-Services-with-Forms-Authentication.aspx.
We can successfully consume a .NET 2.0 web service from a Flex/AS3 application. Aside from SSL, how else can we make the security more robust (i.e., authentication)?
You can leverage ASP.Net's built in session management by decorating your webmethods with
<EnableSession()>
Then, inside your method, you can check that the user still has a valid session.
If you're talking about securing the information going over the wire, you can use Web Service Extensions (WSE) to encrypt the body of the soap message so that you don't have to secure the channel. This way the message can get passed around from more than one endpoint (ie. it can get forwarded) and you don't need multiple https certs.
If you're talking abut autentication then you could do forms auth with either a password in the body or in the soap headers (once again either encrypt the body or the channel). Or one of the easiest ways to secure a webservice (if it's an internal set of services) is have IIS do it, turn on NTLM and do authentication there. You can do authorization later on in the pipeline with an HTTPModule that checks peoples credential against the code they're trying to call.
Consider using WebOrb to communicate with your service. Here is some information on WebOrb's authentication mecahnism. There is also an article on Adobe's developer site on using WebOrb and .Net for authentication.
You should be able to use asp.net's authentication (such as forms authentication) without much extra effort. Securing an asmx file is just like securing an aspx file. There's a ton of information on forms authentication out there, just search for 'asp.net forms authentication'
If you are using Microsoft technologies you could build a little Asp.Net/C# application that would ask for credentials before redirecting to the correct swf.
That way you could restrict the access and have different swf file depending on the user.