You're right to be concerned with creating a new user account just for this task. A much easier approach is to use an application key inserted into the request header. Since you're using self-signed certificates, this leads me to believe that this is a one-off solution and won't be scaled to hundreds of clients. Here are the steps to make this happen.
UPDATE: this alternative solution will have no impact on the IIS hosted application since URL Rewrite will process the request before the application. To immediately drop failed attempts, update the action section of the URL Rewrite rule to the following. Note that this will cause failed requests to not appear in IIS logs.
<action type="AbortRequest" />
Install URL Rewrite on IIS
This is a Microsoft module that isn't installed by default and provides functionality similar to mod_rewrite.
https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads
Create URL Rewrite Rule
Add the following rule to the web.config for your application. It will look for a request header of AppAuthKey (which you can change/personalize) and a value of joshua (not case sensitive and should be something more complex). If either is not present, the 401.4 will be returned.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
</conditions>
<action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Edit curl command
Update your curl command to include the request header as follows:
curl -H "AppAuthKey: joshua"
No Need for a Client Certificate
Using this method doesn't require a client certificate. Normal SSL (should be TLS1.2) will suffice as long are you're using strong ciphers. More information about this can be found at the following OWASP page:
https://www.owasp.org/index.php/Hardening_IIS#Ensure_TLS_cipher_suites_are_correctly_ordered
UPDATE #2
@AlphaD brings up good points regarding various policy settings one can use to further limit accounts. I would recommend against this since it goes against configuration management. Taking that approach introduces configuration requirements for the system hosting the web application that may or may not impact other services. The preferred method is to architect the web app for portability so little of the hosting system is required. Suppose it makes sense to highlight some key points as to why it’s preferred to use an application key in this instance rather than a local or domain user account on IIS.
Local User
If the user is local to just the web server hosting IIS, then that account will be able to authenticate to any other website and/or service hosted by that server. Make sure permissions on all other resources are reviewed because by default the account will be a member of the local "Users" group which has a surprisingly wide breadth. Additionally this account has Read access on the file system (NTFS). If another website is misconfigured, this user could be used to authenticate and read its contents. Authentication via this account will most likely use Basic Authentication which means the credentials are Base64 encoded (not encrypted) and placed into every request header. (Just like my recommendation of adding a custom request header for authentication.) Lastly, using local user accounts makes system management difficult. When migrating the website to a new server, a new account must be created with permissions updated and properly scoped. That logon information then needs to be updated in the consuming curl script(s). It doesn’t make your application portable.
Domain User
Same as local user, now the scope of where this user can authenticate has expanded to the entire domain. This includes Read access to much of active directory and other services advertised in the environment. Authenticating with this user will be a bit more secure since NTLM or Kerberos can be used as long as AD is accessible and your Linux host is configured for AD auth. Otherwise Basic Auth will probably be used. Account management becomes a bit easier since it will fall into the realm of domain account management instead of system account management and often (not always) there are well established procedures for domain account management.
Application Key
Preferred method since no user account is required and limits the scope to just this application. Making the weak point the communication channel (secured via TLS and strong ciphers) and the content directory which should have limited access anyway.
