[JIRA] (IDP-1927) Make Jetty run under its own credentials for windows installs

[Rod Widdowson (Jira)]

Rod Widdowson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=59fb32bbc24efb3c4ed3c977 ) *commented* on IDP-1927 ( https://shibboleth.atlassian.net/browse/IDP-1927?atlOrigin=eyJpIjoiNWYwNjgwNTU0YjI2NDFhODhjOTY5MzRiM2RhNDA0ZjAiLCJwIjoiaiJ9 )

Re: Make Jetty run under its own credentials for windows installs ( https://shibboleth.atlassian.net/browse/IDP-1927?atlOrigin=eyJpIjoiNWYwNjgwNTU0YjI2NDFhODhjOTY5MzRiM2RhNDA0ZjAiLCJwIjoiaiJ9 )

After making the changes described in the above document, if you install a next version, the permissions on everything is reverted except

* IdP/logs
* IdP/jetty-base/logs
* HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\shibd_idp

We can argue the toss about this, but the critical thing is that the service account is reset (the rest can be fixed easily in the installer) I suspect that this is because we use afterInstallInitialize rather than afterInstallExecute for the <MajorUpgrade/> ( https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html ). This means that the service is removed and then re-installed (with what the installer says which is to say no account). If we ‘just' change the installer to run as an account (and this is critical) in order to keep things working, every upgrade requires the password.

The options are

* Require Service Accounts. I don’t like this because I don’t believe that we are expert in that domain and I’m pretty sure that there isn’t a “one size fits all” answer. For this reason - spoiler alert - I (think I) will be pushing for the account to be created outwith the installation - providing hooks for federations that want to automate the issue.
* try afterInstallExecute. This is always a bit white knuckle because it require adherence requires to the component rules. The only things that carry versions are the procrun executables. Specifically the jars do not carry version information (in the Windows sense) and hence the component rules will rely on date. This is a super flaky thing to do: Consider important-jar.3.1.2.jar which needs to be replaced by important-jat-3.2.0.jar but somewhere in the handling (including area outside our control like maven central) the dates get mangled and the 3.1.2 jar appears more modern than the 3.20 one. We end up short of luck.
The mitigation to this would be to bring forward the installation technique I want to do for 5.0 which is to say that the install (at least of the IdP bits) is to somewhere else and we devolved the entire “IdP installation” thing to the IdP installer (in practical terms to use the install target rather than the install-nocopy one).
* Force the person installing to put in the password every time (ugh)
* Pin the service component with the password that is entered initially. The down side is that the service will continue to exist (and will just fail to start) after an uninstall.
* Force the person installing to change the password in the services control panel thingy after an upgrade.

I hate (3) & (5). I really don’t like (1), I’m not keen on (4) and (2) scares me more than somewhat. Guess it sucks to be me.

( https://shibboleth.atlassian.net/browse/IDP-1927#add-comment?atlOrigin=eyJpIjoiNWYwNjgwNTU0YjI2NDFhODhjOTY5MzRiM2RhNDA0ZjAiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/IDP-1927#add-comment?atlOrigin=eyJpIjoiNWYwNjgwNTU0YjI2NDFhODhjOTY5MzRiM2RhNDA0ZjAiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100208- sha1:38b2e23 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20221011/731e4379/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-47a56176-4ef1-4975-896d-6d0d922deacc
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221011/731e4379/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-6e69dc7e-5c14-40df-a624-7ca963a2275b
Type: image/png
Size: 457 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221011/731e4379/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-51d1be18-4dae-4434-8219-06c5ec709155
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20221011/731e4379/attachment-0005.png>