I will address options for authentication in my comments in respect to SOAP services. Authorization is implemented within the server application and mostly irrelevant to the authentication type selected.
There are three (3) classifications of web services:
-Private
-Community
-Public
It sounds like the web service you are providing is a community service because it is only available to trusted partners. I know this because you explained that an IP Address restriction was configured in IIS. Including an IP Address restriction is one of many good measures for implementing secure web services. Security is not a single thing. It is an accumulation of many defenses. IP Address restriction is a good start.
Web Services are stateless by nature. Therefore, it is typical that the credentials (username and password) must be included with every request when calling a web service. So, it is not a problem or concern.
HTTP Basic Authentication is not a bad choice. It is supported by all client and server applications and easy to implement. I like to think of HTTP Basic Authentication as the lowest common denominator. I would not rule it out. HTTP Basic Authentication includes the credentials in the http header in plain text so it’s always recommended to include SSL (HTTPS) to encrypt the transport channel.
WS-Security is a very common authorization standard for Web Services. It is an industry standard for Web Services and the specification is published by the Organization for the Advancement of Structured Information Standards (OASIS) organization. WS-Security includes a UsernameToken profile for including username/password. The WS-Security block is added to the header of the SOAP message. In comparison, HTTP Basic Authentication is added to the HTTP header. HTTP Basic Authentication is attached to the transport protocol. In comparison, WS-Security is attached to the SOAP message. WS-Security UsernameToken is in plain text so it’s always recommended to include SSL (HTTPS).
Another option is client certificate authentication. This option uses a digital certificate as the authentication token in lieu of a username/password. This method works well but requires that the web services team members and client application team members both be familiar with SSL digital certificates as a prerequisite. The learning curve for this method is higher than the others.
The custom solution you described is not necessary, because so many industry standards exist to implement and solve the solution you seek. For example, if you implement WS-Security in your web service, you do not have to provide the client app team with documentation and explain how to implement it in their client application. WS-Security is an industry standard that is well documented and supported by most modern SOAP servers and SOAP clients today. The same applies to HTTP Basic Authentication.
I hope this helps. Cheers, DCova