Control ISHRemote usage in your organization by extra UserRoles `AutomationISHRemoteReadAccess` and `AutomationISHRemoteWriteAccess`

[ddemeyer]

Problem Statement… One feedback I got from several excited automation customers on SDL Connect 2019 is that they don’t “trust” all of their users (tech writers, localization, pub mgrs.,…) … the customer’s IT team is scared that some user deletes a lot of stuff, or re-publishes way more publications (generating load) than that they would do using the UI.

Limitations… Client Tools use exactly the same API as ISHRemote. We are not trying to solve that anybody with C# skills can write an API program anyway. The Docs CMS only knows about UserGroups and UserRoles, all our permissions are implicit in the code and not configurable.

Solution... A Server-Side Solution would be the perceived best solution, something that we will keep in mind when we revisit the AuthN/AuthZ flow, so the generation after current WS-Trust/WS-Fed. This does however not solve existing CMS 11/12/13/14 setups.

So let's try to handle it in ISHRemote code base as that is where most of the fear comes from :-) Upon New-ISHSession, ISHRemote could check if the UserRole AutomationISHRemoteReadAccess and AutomationISHRemoteWriteAccess exist.

• If they do not exist, full access. Current behavior.
• If they do exist, then check if the passed user credentials result in a User Profile holding these UserRoles.
  • On every read cmdlet, do a precheck on AutomationISHRemoteReadAccess
  • On every write cmdlet, do a precheck on AutomationISHRemoteWriteAccess

To be clear the check would be done per cmdlet, and not in the WCF proxies offered on the IShSession object.

• [ ] Implement IShSession UserRole initialization with a Write-Verbose message. Limit testing to New-IShSession only, no extra tests on all cmdlets.
• [ ] Document in release notes how to create the 2 user roles with their role description. Perhaps also add a routine how to assign the roles that currently have Administrator assigned already.
• [ ] Add a BeginProcessing check on all read cmdlets like Get-* and Find-* that access the web services.
• [ ] Add a BeginProcessing check on all write cmdlets like Add-*, Remove-*, Set-*, Publish-*, Stop-* and Move-* that access the web services.
• [ ] Document on readme.md on best practices for development.

Any other ideas? We at least expect some up-votes on this :-)