Hi Christian,
When a bad session ID is received, Integration Server fails the request with “401-Invalid or expired session identifier” and Integration Server also returns the WWW authenticate header to instruct the browser to throw away that invalid session ID. Then client is expected to resubmit the request with credentials but without any SessionID (i.e. just like the first request).
If the client does not want to or cannot handle 401 flow, configure Integration Server to not force reauthentication on session expiry (i.e. watt.security.session.forceReauthOnExpiration=false). And, request the client to include the credentials on each request because they cannot know which sessionID they are sending in is invalid.
When watt.security.session.forceReauthOnExpiration=false, Integration Server uses a valid session as it would normally and ignores the invalid session and let the request through if the given credentials are good. If those credentials are bad, an invalid credentials error would be returned. On the other hand, the credentials are good but the user doesn’t have permissions then 403-Access Denied error would be returned. If the client does not send any credentials, Integration Server would assume an anonymous user (i.e. Default user) and try to execute the request and if that fails then 403 Access Denied error is returned.
Hope this helps,
-Senthil
#webMethods#B2B-Integration#webMethods-io-B2B