Tridion Core service PowerShell settings for SSO-enabled CMS
In a Single-Sign-On (SSO) configuration, it's necessary to use Basic Authentication for web requests to the Tridion Content Manager from the browser. This is probably the oldest way of authenticating a web request, and involves sending the password in plain over the wire. This allows the SSO system to make use of the password, which would be impossible if you used, for example, Windows Authentication. The down side of this is that you'd be sending the password in plain over the wire... can't have that, so we encrypt the connection with HTTPS.
What I'm describing here is the relatively simple use case of using the powershell module to log in to an SSO-enabled site using a domain account. Do please note that this won't work if you're expecting to authenticate using SSO. Then you'll need to mess around with federated security tokens and such things. My use case is a little simpler as I have a domain account I can log in with. As the site is set up to support most of the users coming in via SSO, these are the settings I needed, and hence this "note to self" post. If anyone has gone the extra mile to get SSO working, I'd be interested to hear about it.
So this is how it ends up looking:
Import-Module Tridion-CoreService Set-TridionCoreServiceSettings -HostName 'contentmanager.company.com' Set-TridionCoreServiceSettings -Version 'Web-8.5' Set-TridionCoreServiceSettings -CredentialType 'Basic' Set-TridionCoreServiceSettings -ConnectionType 'Basic-SSL' $ServiceAccountPassword = ConvertTo-SecureString 'secret' -AsPlainText -Force $ServiceAccountCredential = New-Object System.Management.Automation.PSCredential ('DOMAIN\login', $ServiceAccountPassword) Set-TridionCoreServiceSettings -Credential $ServiceAccountCredential $core = Get-TridionCoreServiceClient $core.GetApiVersion() # The simplest test
This is just an example, so I've stored my password in the script. The password is 'secret'. It's a secret. Don't tell anyone. Still - even though I'm a bit lacking in security rigour, the PowerShell isn't. It only wants to work with secure strings and so should you. In fact, it's not much more fuss to work with Convert-ToSecureString and friends to keep everything ship shape and Bristol fashion.