If you are using ASP.NET to create a response / request Service you have only 3 options
- ASMX
- WCF
- Normal .NET pages (or handlers) to process requests
as you specify Services, you can choose between ASMX and WCF then (you can read the difference between ASMX and WCF in my answer here)
keep in mind this
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
This days, there is a common pattern when we need to secure Services, and that's using a session key.
The Service normally has a Method for Login where it gets a User and some kind of Password (normally hashed, salted, etc) and that returns a "ticket" that has a limit of time (slided or not - means per each call to a method the period get's reseted or not), and all calls need to have that ticket included in the message body.
Services API like Magento and others uses this.
Or having a pre generated key that is given to the user / application to be used with every call
Services API like Campaign Monitor and MailChimp and others uses this.
The other normal way is to have the user and other credential in the message header all the time.
Services API like SuperOffice CRM and others uses this.
None of this services uses SSL, as I would only use if I really needed to protected the data in the "wire" keeping in mind that SSL expands the response time on every call made.
I hope this helps