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
Related
We are using WCF services. Right now, we are using Windows Auth but this is not for long. Some services will sit outside the firewall and use username/password verified in the database.
My tech lead is "scared" at how easy any user can "Add Reference" to the services we have and just party on. He wants to "guard" the services by adding another identity - the application. He wants the service to accept requests from certain applications so the certain users cannot just use the service - add reference to it and call. It’s the notion of the application having an identity + credentials that is the operative principle here, as services on the network may need to authenticate those credentials prior to fulfilling a request, in order to prevent rogue code inside the network (i.e., NOT the application) from accessing services using “Joe User” end-user credentials.
Does this make any sense?
Then he believes the Juval Lowy's book has, in an Appendix that discusses sending more than one identity during a WCF call (Security Interceptor). There is no specific suggestion that all of those have to be end-user identities and if that is the case, one of those could be the identity of the application making the request.
How can this be done?
Thanks,
Sam
The problem with sending an application identity is that the secret used to confirm that identity has to be stored somewhere. If it is visible to one application on a machine then generally it will be visible to other applications running under the same identity.
Would your manager be happy with "it came from an authorised machine"? If that's the case you could simply use Client Certs
Its also worth taking a step back: if the user is authenticated and is authorized to perform the functionality they have requested, why do you care which application they came from - if they are who they say they are and they are allowed to do what they are requesting then why couldn't they use, say, fiddler to make the request - isn't that the point of a service (rather than a closely coupled client server app)?
You might want to look through Common Security Scenarios in the MSDN documentation to see if any of those options fit your needs.
The options that pops to my eye are Transport Security with Certificate Authentication and Message Security with Mutual Certificates. Both rely on X.509 certificates. The latter option is on the message level, so you can handle certificate delivery and security negotiation however you want.
To make it a lot harder for someone to add a reference to your service you could just remove the mex endpoint. This way it would be very difficult for a stranger to create a valid request message.
You can then distribute the WSDL manually, only to people you trust.
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.
After some theoretical help on the best approach for allowing a SaaS product to authenticate users against a tenant's internal Active Directory (or other LDAP) server.
The application is hosted, but a requirement exists that tenants can delegate authentication to their existing user management provider such as AD or OpenLDAP etc. Tools such as Microsoft Online's hosted exchange support corporate AD sync.
Assuming the client doesn't want to forward port 389 to their domain controller, what is the best approach for this?
After doing some research and talking to a few system admins who would be managing this, we've settled on an two options, which should satisfy most people. I'll describe them here for those who were also interested in the outcome.
Authentication Service installed in the origanisation's DMZ
If users wish to utilise authentication with an on-premises active directory server they will be required to install an agent in their DMZ and open port 443 to it. Our service will be configured to hit this service to perform authentication.
This service will sit in the DMZ and receive authentication requests from the SaaS application. The service will attempt to bind to active directory with these credentials and return a status to indicate success or failure.
In this instance the application's forms based authentication will not change, and the user will not be aware of the authentication behind the scenes.
OpenId
Similar to the first approach, a service will be installed in the client's DMZ, and port 443 will be opened. This will be an OpenId provider.
The SaaS application will be an OpenId consumer (already is for Facebook, Twitter, Google etc login).
When a user wishes to log in, the OpenId provider will be presented, asking them to enter their user name and password. This login screen would be served from the client's DMZ. The user would never enter their username or password into the SaaS application.
In this instance, the existing forms based authentication is replaced with the OpenId authentication from the service in the client's DNZ.
A third option that we're investigating is Active Directory Federated Services, but this is proprietary to Active Directory. The other two solutions support any LDAP based authentication across the internet.
Perhaps this might help…
This vendor, Stormpath, offers a service providing: user authentication, user account management, with hookups to your customers’ on-premise directories.
What about an LDAPS connection to the customer's user directory? They can firewall this off so that only your servers have access if they're concerned about it being public. Since it's SSL it's secure end to end. All you need from them is the certificate from their issuing CA (if it's not a public one). I struggled to get this working for an internal web project in the DMZ and there's a real lack of any guides online. So I wrote one up when I'd got it working:
http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/
Your best bet is to implement a SAML authentication for your SaaS application, and then sign up with identity providers like Okta or OneLogin. Once that's done then you can also connect it with ADFS to provide Single Sign On for your web application through Active Directory.
I'm just doing this research myself and this is what I've came across of, will have more updates once implementation is done. Hope this gives you enough keywords to do another google search
My understanding is that there are three possible solutions:
Installing something on the domain controller to capture all user changes (additions, deletions, password changes) and send updates to the remote server. Unfortunately there's no way for the website to know the initial user passwords - only new ones once they are changed.
Provide access for the web server to connect to your domain controller via LDAP/WIF/ADFS. This would probably mean opening incoming ports in the company's firewall to allow a specific IP.
Otherwise, bypass usernames/passwords and use email-based authentication instead. Users would just have to authenticate via email once every 3-6 months for each device.
I have to begin implementing this for an upcoming project and I'm seriously leaning towards option #3 for simplicity.
Please suggest me the best authentication way to implement in the scenario mentioned below:
The requirement is I have to deploy a WCF web service in multiple countries across the world.
NOTE : All the machines on which the service is deployed are on the same domain.
1.The clients that access this service should fall in the same domain else the authentication should fail.
Currently I am using Message Security mode using "Windows"
I am curous why you would want the domain to be the same if it needs to be deployed in different countries around the world. Unless you are talking about hosting the service on an internal network that is not publicly exposed, enforcing the same domain name might be difficult. Different countries have different domain standards. America has a much richer set of domain roots to choose from. Other countries often have a country specific root, possibly with a regional subroot.
I would not couple your service to the domain that hosts it, nor would I recommend using the domain as a factor in authentication. If your service needs to be publicly exposed on the internet in each of these countries, I would recommend using something other than Windows security. A Claims-based security mechanism might work best. Internally inside the service implementation, claims can be checked, and if necessary, the windows identity can be authenticated separately from WCF authentication. Claims also allow you to utilize more than just a username/password or certificate to fully authenticate and authorize a client request. You can request the callers domain, country, region, and other evidence be included in the claim, allowing you to verify that calls are being made from the appropriate location and by the appropriate clients with much more flexibility than with Windows authentication (and if you publicly expose your service, Windows authentication will likely not be available anyway.)
Since you are running on an intranet and assuming that your Windows application will connect directly to the service, I would go with Transport Security using Windows authentication.
For some guidance consult patterns & practices Improving Web Services Security Guide.
I still question whether or not you need authorization. If you go with Windows authentication without any authorization it will simplify your service but will allow any domain user to access your service whether or not they are using the Windows application. Granted, they would have to have knowledge of the endpoint and the message structure but it would still be possible for them to do.
If Windows authentication is really all that is required, I would still raise the authorization issue and document it (and get sign off if applicable). On the one hand this covers you but also makes people explicitly aware of the decision and the possible risks.
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.