You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recover and Refresh IShSession Access Token to avoid FaultException ‘An unsecured or incorrectly secured fault was received from the other party.’
#201
Open
1 of 3 tasks
ddemeyer opened this issue
Sep 26, 2024
· 0 comments
Every usage of a cmdlet will refresh the security tokens. However, when not using ISHRemote cmdlets or the implicit $ISHRemoteSessionStateIshSession or explicit $ishSession object, the session expires by default after around 57 minutes when using ISHID.
This issue is about investigating and potentially implementing if there a possibility to even recover after total security token expiration. There are two scenarios…
After a New-IShSession with parameters -ClientId 'abc' -ClientSecret ‘xyz’, so OpenIDConnect Client Credentials flow. Do you expect that an almost expired Access Token (function IsTokenAlmostExpired) results in implicitly creating a new tokens? Yes
After a New-IShSession without parameters, so the interactive browser flow, so OpenIDConnect Authorization Code Flow with PKCE flow. Do you expect a new browser window to automatically pop up after first usage again? Yes
Actions…
Revisit the if clause in all Get__Channel functions like public Folder25ServiceReference.Folder GetFolder25Channel() to incorporate IsTokenAlmostExpired for InfoShareWcfSoapWithOpenIdConnectConnection.cs Extend the if-clause that checks _annotationClient == null with an || IsTokenAlmostExpired() and do it for both platforms.
Verify and document the error on what happens if the provided ClientId/ClientSecret combination expires. Make sure it does not become an infinite loop.
Verify and document the error on what happens if the interactive browser-based re-authentication cycle fails.
Analysis…
ISHRemote v8.1 and v8.0, a negative advice of IsTokenAlmostExpired function does not result in creating new Soap channels with new Access/Bearer Tokens.
The implementation of IsTokenAlmostExpired is actually DateTime.Now.Add(RefreshBeforeExpiration) > _connectionParameters.Tokens.AccessTokenExpiration which in practice typically means after 57 minutes. In turn resulting in error An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
Regarding OpenAPI (REST), every GetOpenApiISH30Client() function call will set a potentially refreshed Bearer Token on the HttpClient using GetAccessToken function in In InfoShareOpenApiWithOpenIdConnectConnection.cs. Both WcfSoap connections however are setup differently.
Regarding WcfSoapWithOpenIdConnectConnection, the advise is to alter the code base, see above Actions.
Regarding WcfSoapWithWsTrust, the IsTokenAlmostExpired function is called but does not force a refresh in Get__Channel functions of InfoShareWcfSoapWithWsTrustConnection.cs. The simple fix would be to extend the if-clause that checks _annotationClient == null with an || IsTokenAlmostExpired(). After verification, this code is unchanged since ISHRemote v0.7 until v8.1 and since Tridion Docs 15.0.0 the WcfSoapWithWsTrust is marked deprecated. Decided to not change anything.
The error was caught by doing a simple Get-IshFolder -FolderPath "General" after 1 hour which resulted in the following stack trace
InnerException = {"An error occurred when verifying security for the message."}
…
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.<RequestAsync>d__7.MoveNext()
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.<RequestAsyncInternal>d__8.MoveNext()
at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(MethodCall methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(MethodInfo targetMethod, Object[] args)
at generatedProxy_12.GetMetadata(BaseFolder , String[] , String )
at Trisoft.ISHRemote.Cmdlets.TrisoftCmdlet.BaseFolderEnumToLabel(IshSession ishSession, BaseFolder baseFolder) in C:\GITHUB\ISHRemote\Source\ISHRemote\Trisoft.ISHRemote\Cmdlets\TrisoftCmdlet.cs:line 245
at Trisoft.ISHRemote.Cmdlets.TrisoftCmdlet.BaseFolderLabelToEnum(IshSession ishSession, String baseFolderLabel) in C:\GITHUB\ISHRemote\Source\ISHRemote\Trisoft.ISHRemote\Cmdlets\TrisoftCmdlet.cs:line 219
at Trisoft.ISHRemote.Cmdlets.Folder.GetIshFolder.EndProcessing() in C:\GITHUB\ISHRemote\Source\ISHRemote\Trisoft.ISHRemote\Cmdlets\Folder\GetIshFolder.cs:line 318
The text was updated successfully, but these errors were encountered:
ddemeyer
changed the title
Actively recover IShSession Access Token to avoid FaultException ‘An unsecured or incorrectly secured fault was received from the other party.’
Recover and Refresh IShSession Access Token to avoid FaultException ‘An unsecured or incorrectly secured fault was received from the other party.’
Sep 26, 2024
Summary…
Every usage of a cmdlet will refresh the security tokens. However, when not using ISHRemote cmdlets or the implicit
$ISHRemoteSessionStateIshSession
or explicit$ishSession
object, the session expires by default after around 57 minutes when using ISHID.This issue is about investigating and potentially implementing if there a possibility to even recover after total security token expiration. There are two scenarios…
New-IShSession
with parameters -ClientId 'abc' -ClientSecret ‘xyz’, so OpenIDConnect Client Credentials flow. Do you expect that an almost expired Access Token (function IsTokenAlmostExpired) results in implicitly creating a new tokens? YesNew-IShSession
without parameters, so the interactive browser flow, so OpenIDConnect Authorization Code Flow with PKCE flow. Do you expect a new browser window to automatically pop up after first usage again? YesActions…
_annotationClient == null
with an|| IsTokenAlmostExpired()
and do it for both platforms.Analysis…
ISHRemote v8.1 and v8.0, a negative advice of IsTokenAlmostExpired function does not result in creating new Soap channels with new Access/Bearer Tokens.
The implementation of
IsTokenAlmostExpired
is actuallyDateTime.Now.Add(RefreshBeforeExpiration) > _connectionParameters.Tokens.AccessTokenExpiration
which in practice typically means after 57 minutes. In turn resulting in errorAn unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
IsTokenAlmostExpired
function is called but does not force a refresh in Get__Channel functions of InfoShareWcfSoapWithWsTrustConnection.cs. The simple fix would be to extend the if-clause that checks_annotationClient == null
with an|| IsTokenAlmostExpired()
. After verification, this code is unchanged since ISHRemote v0.7 until v8.1 and since Tridion Docs 15.0.0 the WcfSoapWithWsTrust is marked deprecated. Decided to not change anything.The error was caught by doing a simple
Get-IshFolder -FolderPath "General"
after 1 hour which resulted in the following stack traceThe text was updated successfully, but these errors were encountered: