authenticate to SDL KC 12

I tried connecting to an SDL Knowledge Center 12 instance with the command:

$ishSession = New-IshSession -IshPassword $password -IshUserName $username -WsBaseUrl $url

I got this error:

New-IshSession : WSTrust endpoint not configured: '/InfoShareSTS/issue/wstrust/mixed/username/'

A Fiddler capture of logging in through the web interface shows a POST to /InfoShareSTS/account/signin with the request body:


Is this an abnormal authentication setup or can ISHRemote's New-IshSession command replicate this?

  • Hi Tintinno

    ISHRemote can handle username/password authentication towards the built-in InfoShareSTS/ISHSTS.

    As you rightfully hide the urls (like $url) I can only tell you what the code is looking for. The error is thrown on line 834 on

    My generic guess would be that the web services url you enter for a client tool like Publication Manager, should be passed in your $url. That should be enough. Make sure it holds an s near httpS://.

  • Hi Dave!

    I verified the protocol was https and the endpoint '/InfoShareWS/' matched the service URL in Publication Manager. I'm attaching another attempt with the -Verbose and -Debug flags (with domains changed to '' etc.). Please let me know if anything stands out. Thanks!


    New-IshSession -IshUserName $username -IshPassword $password -WsBaseUrl '' -Verbose -Debug

    DEBUG: NewIshSession 20180926.101644.761 BeginProcessing
    VERBOSE: NewIshSession Connecting to WsBaseUrl[] IshUserName[Username] IshPassword[**********************]
    DEBUG: NewIshSession 20180926.101649.022 Connecting to WsBaseUrl[] IshUserName[Username] IshPassword[**********************] Timeout[00:00:20] Time
    outIssue[10675199.02:48:05.4775807] TimeoutService[10675199.02:48:05.4775807] IgnoreSslPolicyErrors[False]
    DEBUG: NewIshSession 20180926.101649.023 Enabling Tls, Tls11 and Tls12 security protocols
    DEBUG: NewIshSession 20180926.101649.032 Incomming infoShareWSBaseUri[]
    DEBUG: NewIshSession 20180926.101649.035 LoadConnectionConfiguration uri[] timeout[00:00:20]
    DEBUG: NewIshSession 20180926.101649.273 InitializeInfoShareWSBaseUri uri[]
    DEBUG: NewIshSession 20180926.101649.274 Normalized infoShareWSBaseUri[]
    DEBUG: NewIshSession 20180926.101649.275 Resolving endpoints
    DEBUG: NewIshSession 20180926.101649.277 GetWsdlImporter wsdlUri[]
    DEBUG: NewIshSession 20180926.101650.030 ApplyQuotas on serviceEndpoint[]
    DEBUG: NewIshSession 20180926.101650.037 Resolved endpoints
    DEBUG: NewIshSession 20180926.101650.038 CreateConnection _serverVersion GetApplication25Channel
    DEBUG: NewIshSession 20180926.101650.040 Issue Token
    DEBUG: NewIshSession 20180926.101650.041 FindIssuerEndpoint
    DEBUG: NewIshSession 20180926.101650.042 FindIssuerEndpoint issuerMetadataAddress[] issuerAddress[]
    DEBUG: NewIshSession 20180926.101650.043 GetWsdlImporter wsdlUri[]
    DEBUG: NewIshSession 20180926.101650.115 GetWsdlImporter wsdlUri[]
    VERBOSE: NewIshSession Connecting to IssuerWSTrustUrl[]
    DEBUG: NewIshSession 20180926.101650.194 InitializeIssuerWSTrustEndpointUri uri[]
    DEBUG: NewIshSession 20180926.101650.196 FindIssuerEndpoint issuerWSTrustEndpointAbsolutePath[/InfoShareSTS/issue/wstrust/mixed/username/]
    New-IshSession : WSTrust endpoint not configured: '/InfoShareSTS/issue/wstrust/mixed/username/'.
    At line:1 char:1
    + New-IshSession -IshUserName 'Username' -IshPassword '************ ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [New-IshSession], InvalidOperationException
    + FullyQualifiedErrorId : NewIshSession,Trisoft.ISHRemote.Cmdlets.Session.NewIshSession
  • I compared this to another debug log, and I noticed that in a few places a final slash is present in this log but missing in the log of the system I can connect to.

    1. GetWsdlImporter wsdlUri[]
    2. GetWsdlImporter wsdlUri[]
    3. VERBOSE: NewIshSession Connecting to IssuerWSTrustUrl[]

    I can retrieve both connectionconfiguration.xml files and see that the URL ends with "username" in the 2014 instance and "username/" in the 2016 instance. So perhaps the problem is only with "mex/" and "wstrust?wsdl/". GET requests to the 2016 instance return the XML <wsdl:definitions> etc only if wstrust?wsdl is missing the final slash. 

    Since I can't fix this server-side, is it possible to update the ISHRemote client to trim the final slash if it exists? I'm not that familiar with C#, and I don't have a system setup for testing these changes, but perhaps something like this:

     950 private WsdlImporter GetWsdlImporter(Uri wsdlUri)
    951 {
    952 if ( wsdlUri.EndsWith("/") )
    953 {
    954 wsdlUri = wsdlUri.TrimEnd("/");
    955 _logger.WriteDebug($"Trimming final slash from wsdlUri");
    956 }
    957 _logger.WriteDebug($"GetWsdlImporter wsdlUri[{wsdlUri}]");

    Then the final slash won't be on the /mex ending either, so the issuerMetadataAddress.Uri.AbsoluteUri.Replace("/mex", "?wsdl") statement on line 823 won't leave behind a trailing slash.

  • Ah! I just realized that New-IshSession has the options -WsTrustIssuerMexUrl and -WsTrustIssuerUrl. By setting these to the "mex" and "username" URLs without the final slash, I'm able to authenticate. Thanks for your help, Dave!