Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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
Assignees
Milestone

Comments

@ddemeyer
Copy link
Contributor

ddemeyer commented 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…

  1. 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
  2. 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
@ddemeyer ddemeyer added this to the v8.2 milestone Sep 26, 2024
@ddemeyer 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
@ddemeyer ddemeyer self-assigned this Sep 26, 2024
ddemeyer pushed a commit that referenced this issue Sep 30, 2024
…nt/secret for ..WithOpenIdConnect protocols by explicitly setting tokens to null first
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant