We Keep Coding

Handle external WCF Service calling internal WCF Service (auth - session)

i need to build this architecture and i need some orientation on "how should i build". I've read many docs and examples but i can't find and figure how to do trying to be efficient and secure:
External app (android app, ios app) where users, after a login, can access to their personal info and manage the account (updating personal data, showing personal documents related to their account and much more). The username / pwd input must be done only 1 time.
A public wcf service will receive their actions and will call to a another internal wcf service. It will work like a 'bridge'.
The internal wcf service will get the request and do the operations needed (logical and db operations). This will return data to the external wcf service and this one to the client (obvious).
UserName/PWD are stored in a database.
WCF services can only be accessed with the correct credentials and are IIS hosted.
So i find many problems/questions:
I don't know HOW and WHERE should I build the AUTH (internal, external, both?). How can i manage a session between wcf services and app clients to avoid sending credentials every time?
The client app needs to send credentials every time? This means every service requires to SELECT the database for checking the username?
SOAP? Rest Services? It doesn't care? (on internal wcf, external wcf, both?).
I need work with asp.NET sessions or i really don't need? I don't see how services that needs username/pwd that are called frequently and repeatedly are efficient without old asp.net sessions.
Thanks for your help and orientation.
Regards!

If someone interested... seems Routing Service seems to fit for my design and can solve my problem after some tests i have done.

Role-based authentification for the WCF REST service

I am trying to implement role-based authentification to the REST WCF service . I read a lot of information on this theme but didn't got a clear understanding of what I have to do.
I understand how to restrict an access to the service using the [PrincipalPermission] attribute but don't know how to check whether the user belong to the certain role or not.
Therefore I will be very grateful if somebody can direct me to the right way (e.g. make a roadmap what should I do to achive this goal).
Let me describe this situation. I have a remote services which hosted on the server A and ASP.Net MVC client hosted on the server B.
All of these rest services has an access to the database where I can read an information whether the user has access to the service or not.

OK, Tequila, IMO what you really want, based on your description, is a normal, REST WCF service with a Login(ID as string, PWD as string) method that (perhaps) returns a SessionID. This Login() or SessionID() check method would then preceed access to all of your other methods. And since it's a webHTTPBinding -- effectively a stateless web service -- you'll need to check the SessionID or ID/Password before each request is processed.
So the workflow would be something like this:
1) client sends Login() request to host
2) host checks ID/Password against DB, creates SessionID in DB that times out after x hours, forcing new Login(). SessionID is returned in response to client,.
3) In all subsequent requests, client must provide that SessionID. That SessionID would be checked on the DB, returning stored information about the client (Role, name, ID, address ... whatever is useful) before the remainder of the request is processed.
There are methods for authenticating users BEFORE the request gets to your working code (like client authentication using Forms or client certificates (see http://msdn.microsoft.com/en-us/library/ff405740.aspx)). This shifts the Login() / SessionID check to a method executed BEFORE the request hits your main program, but the steps are basically the same.
And since passing ID/Pwd in clear text over the web is a no-no, you'd want to implement SSL on your web service (see http://msdn.microsoft.com/en-us/library/ff650785.aspx)
Everything I've describe is basically platform independent, so if you'll have iOS or Android clients, there's nothing in what I've described that would prohibit those OSs from successfully interacting with your web service.
Good luck.

Secure Webservice best practices

I’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny

I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.

Web Service or web API for connecting a windows application to MVC 4?

After searching the entire day about what I should use, I'm not sure what option would be best for my needs so I hope someone with more experience could help me out.
I have a winforms application (c#) and a ASP.NET MVC 4 web application (c#).
I wish to connect these, the goal is to send and receive data from the database which I use in the MVC 4 project, but from within the windows forms application. The data I send from the windows forms application to the database, is then used by the MVC 4 web application.
I am entirely new to web services / Web Api's so I can't really decide what option would be best. Any help would be much appreciated..

If you already created MVC4 project then you can add actions to any controller
and return JSON data like below :
public JsonResult GetCategoryList()
{
var list = //return list
return Json(list, JsonRequestBehavior.AllowGet);
}
or you can create new project of MVC4 and select WEBAPI template . It will create webapi project for you .It will create with example .so it will easy for to create webapi.In webapi it return data automatically convert to xml and json as per request
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web AP -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
Other Links

If you have an MVC 4 App already, it would be better to use Web API (RESTful service)
I assume you have some knowledge in building REST API (understanding of POST, PUT, UPDATE stuff)
It is simple in configuration and usage. All what you need actually is to create a new controller like:
class MyApiController: ApiController {
public Post(SomeClass item) {
....connect to db and do whatever you need with the data
}
}
You'll also should configure routing for Api.
And then in your winForms app you can simply use HttpClient class to perform api call.
HttpClient aClient = new HttpClient();
// Uri is where we are posting to:
Uri theUri = new Uri("https://mysite.com/api/MyApi");
// use the Http client to POST some content ( ‘theContent’ not yet defined).
aClient.PostAsync(theUri, new SomeClass());
Take a look at some implementation details right here:
Web Api Getting Started
Get started with WCF is not so easy as with Web API.

Given the tags you've used, my guess is that you're deciding between SOAP Web Services and WCF. Given these two, I say to go WCF. SOAP web services (as implemented in Visual Studio) are the older technology; still serviceable, but WCF can do everything an older SOAP service can do (including look exactly like a SOAP service) and more.
If you have a web service that connects your web server to your database server (these two things should be on different machines; your web server is exposed to the world by necessity, while your DB server should be locked down like Fort Knox), I see no reason why you shouldn't use that same service as-is for an internal WinForms application (using a LAN/VPN to access the service layer on the DB server). For a WinForms application that must access the data over the Internet, I would recommend reimplementing the service as a WCF service supporting secure encrypted data transfer. You can also set up the service endpoint to only accept HTTPS connections, and thus simply run your existing service through SSL/TLS.
What you choose will primarily depend on how much time-resources you can commit to resolving the problem; moving to HTTPS is a fast fix requiring little if any code changes, while reimplementing in WCF will take more time but will allow additional security measures beyond a simple secure tunnel.

Or something lightweight like Nancy: http://nancyfx.org/

We had some issues with MVC4 WebApi stuff and ended up using ServiceStack on the server side JavaScript/AJAX for web clients and RestSharp for thick clients.
One of our specific issues was the inability to auto generate documentation, significant performance differences, and better support for unit/integration testing.

Rather than advocate specifically WCF, I'd recommend WCF Data Services or OData, with the stipulation that you'll need to secure it. If you go for pure WCF, you'll see that you'll end up creating a lot of code to handle retrieving the info from a database, and then sending that information right back out to your clients. It doesn't sound that bad, at first, but after about 30 entities in a database, you'll quickly grow tired of a pure WCF solution.
OData is great, it uses Entity Framework, and it quickly opens data manipulation for an existing database or one you are going to make. It will save you a ton of development time, if you can make your service secure. The format of the data response is flexible. There are plenty of client libraries ported for other programming languages as well.
The steps for securing a service are pretty simple. Always deploy to https. Any login or registration methods , need to be post methods, that return a token (Encrypted value), or a unique secret that can be encrypted and sent back for any subsequent requests. It's better to use the token, and have an expiration on the token.. because otherwise both your service and your app whether mobile or desktop, need to have a shared encryption / decryption method.

Secure connection using SOAP

I need to call a .NET SOAP webservice in a secure way. It must be secure in such a way that others can't call the WebService methods, and also it should not be possible for "the middle man" to understand the content of the messages.
The caller will also be a .NET webapplication installed on another IIS.
I can design the webservice methods as I want, so no restrictions there.
I have been researching HTTPS/SSL with certificates, but I don't know if it actually solves my problems in a good way? For example, it would be anoying if the certificates has an expiration date, although it's not a showstopper in any way.
So how would I go about this in a good way..?
Thanks for any help.

As #BrokenGlass said, SSL only encrypts the traffic between points. It doesn't handle securing individual functions from usage without authorization. Here is a good article on just such a topic using SOAP headers:
How to: Perform Custom Authentication Using SOAP Headers
This can be mixed with any form of authentication except Windows Integrated. To use Windows authentication, you'll need to have a separate library which accesses the Active Directory through the DirectoryServices namespace.

Assuming you control the infrastructure then keeping the server that is providing the web services behind a firewall so it's accessible only from the web servers and implementing IPSec should provide the necessary security.
From the software point of view, this article contains all you need to know about protecting the service interactions.

HTTPS/SSL works fine. Just make sure to renew your certificate in time to avoid warnings and messages for your client.

I need to call a .NET SOAP webservice in
a secure way. It must be secure in
such a way that others can't call the
WebService methods, and also it should
not be possible for "the middle man"
to understand the content of the
messages.
HTTPS/SSL only solves the "middle man" part of what you want to achieve. You would still need proper authentication in place on your web service. You could do this i.e by using the built in Forms authentication and providing a Login method that returns your authentication ticket.