please help. Half of the kingdom for a correct answer!!!
Is it possible to use WCF Windows authentication with the anonymous access option? My WCF service deployed in the AD domain, and there are some clients outside of the domain. Can I use windows authentication to get client credentials for users that are in the AD and the same time allow access to the users they are not in the domain? Thanks.
P.S. Sorry for poor English.
To do this you need to create a service configuration that exposes two different endpoints. One endpoint would use your current config. The new endpoint would be for the non-AD clients and you would configure it using the options listed here. For anonymous access, you could pick an unsecured client configuration. If your service host is IIS, you may need to have two different sites/applications because I believe enabling Windows authentication will disable anonymous access.
Related
I need to find out what's the best way of securing a WCF web service I'm writing. The service will be hosted internally and will perform checks against Active Directory and a third party database.
The service will be called by a public-facing webpage on a different server (a sign up page) and nothing else will be able to access it (due to firewall rules). The web page will NOT require credentials to access it.
The service will take a username and another field and check to see if they're an existing AD user. If they are, it will check to see if they have a personal (non-work) email address in the third-party database. If not, it will ask them to specify one.
Website <-> Service <-> AD/Database.
If these firewall rules are in place, do I need to go about securing the service?
These codeplex application scenarios might help you configure what you're trying to achieve:
Internet – Web to Remote WCF Using Transport Security (Trusted Subsystem)
Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
This guide is well put together defiantly something to look into it covers all situations including yours.
http://wcfsecurityguide.codeplex.com/releases/view/15892
I am working on an Asp.Net application which will interact with WCF services that will be hosted on local machines on IIS.
In order to make these wcf services be hosted, what rights does user have to have when they log in? Do they have to have Admin rights on the machine?
P.S.: I know that WCF services should not be hosted on individual local machines so please do not start the discussion on that. All i want to know is what rights logged in user needs to have in order to make WCF services available to the application.
It really depends on how you set up the service. You can configure the website to allow anonymous access and set up your WCF binding to basicHttp binding with a security mode of None. That should allow any logged in user to run the site. This would NOT restrict users to only the one(s) logged in to the local machine, if that is what you are looking for.
You are dealing with two levels of security here. You will define your access in IIS to allow users to use the site. Then you will set up WCF service to allow the IIS site to access it. If you are using pass through authentication then you will need to authorize the individual users, perhaps with a local group?? Otherwise you need to authorize the identity that IIS is running the site under. So users do not need to be administrators, unless you specifically demand that role in IIS or WCF.
I've been reading about WCF security for a whole day and can't say I'm comfortable with it.
I've developed some WCF services and deployed them to a test server and can call from a client. Both sides C# / VS 2010. The services are hosted under IIS 6. No option to go more recent at the moment.
So - I've read that I can only use HTTP with IIS 6 - which I believe restricts me to basicHttpBinding or wsHttpBinding as the binding.
I've also read that the XML sent over the wire using wsHttpBinding is encrypted, whereas basicHttpBinding is not.
So it looks like I want to go with wsHttpBinding as I will want some sort of authentication and I suppose user name / password will be passed along with the incoming messages.
First question is - if I use wsHttpBinding do clients have to call using https? And then do I need to worry about certificates etc. on the server?
Second question is - what security options are available to me? Do the callers have to be Windows users on the server, or can I make up my own user name / password and have that part of the service and the service do the validation and have nothing to do with Windows users? If I have to go with Windows users I suppose it's common to set up one user account on the server and have all callers use that?
The basic idea is I need to open this service to selected callers, but don't want just anyone to be able to discover the service and call it. I need to control somehow who calls the service. Is user name / password the standard way of doing this? Could I define a GUID for example which all callers would have to pass?
In answer to your first question. wsHttpBinding does not require HTTPS. You can use HTTP if you set the SecurityMode to Message or None. However, since you are proposing to send a username and password with the service calls you definately shouldn't do that. If you do then anyone will be able to look at the message in transit and read the username and password and your security is totally compromised. I'm afraid you will have to get a certificate and use HTTPS. It's not so bad though and there are lots of resources on the web to help you.
By the way, you can do HTTPS with basicHttpBinding aswell as wsHttpBinding. Also, you should consider using REST for simplicity. WCF has good support for it (webHttpBinding) and better support coming with the Web API.
In answer to your second questions, you do not need the callers to be Windows users on your server and you can use a username and password. This is called Basic Authentication. Again, there is lots about it on the web. Start here.
If you do this you will obviously have to have a database to store usernames and password so you can validate then and grant or denay access to your service. The simplest way to achieve this with WCF is to use one of the default membership providers.
I have multiple NET.TCP services that provide access to my apps bussiness logic layer. I want to authenticate clients with username & password, within all the services, from one dedicated authentication service.
I have thinked that I can generate a custom authentication ticket when the authentication service logons the user and send it to other services. However when talking about security I prefer to use builtin implementations that have been already tested.
Is there a more WCF way to do this? Should I ever try this, or share the authentication logic and authenticate every service?
Thanks in advance
Yes, the (new) WCF way to do this is to use a (or implement your own) security token service based on the windows identity foundation framework.
We are developing an app that consists of a web server that hosts a web service (amongst other things) and a client that will be communicating with that web service. Both the client app and the server are expected to be used within a corporate firewall. This application will be packaged up and deployed to organizations across the world—so it needs to be flexible enough to work in multiple types of environments.
My question revolves around web service authentication and what is appropriate for real world scenarios. I know some companies have proxy servers that require a separate authentication. How often is this a requirement across organizations? When does the proxy server force the user to authenticate (can you access internal sites without authenticating.. is the authentication for only external sites)?
Reason I ask these questions, is I’m not sure what kind of capability we should build into our client application for authentication to the web service. By default, we are taking the current user credentials and passing that up to the server. Do you think this is sufficient? In a case where a company will require some form of alternate authentication for internal access, this will not work. My question revolves around this last case—how often does it happen? Why would a company force alternate credentials for internal access?
Thanks!
Why not make it configurable? Further, use WCF and you have the ability to configure just about anything you might need, in most cases without changing your code.
If Internet Explorer can reach a site through the proxy server without prompting the user, your call to the web service should "just work". If the user is prompted by IE, you'll need to put together a way to fill in the proxy server authentication information.
I've run into quite a few problems getting web services rock solid, but never had a proxy server authentication issue.