IBM Tivoli Access Manager/WebSEAL + Fiddler

[tpu...@gmail.com]

Hello all,

I currently have a problem with a session timeout on IBM TAM that miraculously does not occur when using Fiddler to analyze traffic. Perhaps is there anyone here who could explain me how is this possible?

I will try to explain it in details below.

I have a C# rich client application used on a Terminal machine that calls HTTPS Webservices using PKI certificates read from user smartcards. The calls first pass through an authentication/authorization phase on this IBM Tivoli Access Manager where a session is created. The authentication is based on the certificates attached to each webservice call. Everything works fine, except there is no logout nor end session command (actually there is but not for my Webseal configuration). After a defined time interval, this session expires. It seems like my application tries to reuse this session (although I do not have control of this) so the only way to make it work is to restart it. As nobody was able to explain me how this Webseal session is closed when application shuts down, I started analyzing HTTPS request using Fiddler. And then the strange thing occurred. When using Fiddler, application does not fail anymore calling webservices after timeout so somehow using it enforces creation of a new session. This works only when HTTPS decryption is active and Fiddler acts as a proxy server. Even stranger, without closing my application but trying with/without Fiddler started, it works/fails accordingly. 

By analyzing headers I noticed nothing strange, there is no session id or something similar.

I am putting below a snippet of the Webseal logout documentation

https://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1134-01/en_US/HTML/amweb41_admin08.htm

pkmslogout

Clients can use the pkmslogout command to log out from the current session when they use an authentication method that does not supply authentication data with each request. For example, pkmslogout does not work for clients using Basic Authentication, certificates, or IP address authentication. In this case, you must close the browser to log out.

It seems that even the official documentation says the user has to close the browser (in my case the .EXE application) to log out.

So, do you have any idea how is this working with Fiddler?

I hope the description of the problem is not too incoherent. Feel free to ask me for more details if necessary.

With kind regards,

Theodor P

[EricLaw]

I can provide some information, but I don't know if it will be helpful:

"nobody was able to explain me how this Webseal session is closed when application shuts down"

Server applications can maintain a "session" with the client in a number of ways-- by sending the client a cookie (which the client re-presents on each request), by having the client send an authentication header in each request (e.g. the WWW-Authorization: BASIC <base64data>), by connection reuse (e.g. the client authenticates using a client certificate when establishing a HTTPS connection and all subsequent requests are authenticated as they are on the same connection).

It's probably not strictly true that you have to restart a browser to clear such a session; in IE, you'd click the Tools > Internet Options > Content tab > Clear SSL State button, for instance, but it's often simpler to just restart the application.

Now, as to why Fiddler "fixes" this, that's a great question.

Did you configure Fiddler to provide the HTTPS Client Certificate to the server? If so, how specifically did you do so? If you did not configure Fiddler itself to provide the client certificate and if you did enable HTTPS decryption in Fiddler, this would mean that your application is no longer sending a client certificate to the server and thus it must be using a different authentication mechanism when Fiddler is running.

[tpu...@gmail.com]

Hello Eric,

Thank you for your answer.

Indeed, the Authentication/Authorization WebSeal server is sending to the client 2 cookies which I programmatically re-present on every further request (WCF doesn't do it automatically like the browser does it) until a new user logs in and I get new cookies. However, this does not solve the problem. 

Regarding configuration to decrypt HTTPS, when using Fiddler for first time I am prompted to save the client certificate to a file named ClientCertificate.cer (see image attached) and the call fails. As soon as I export the certificate from my test smartcard to the specified location, HTTPS decryption works and also, the timeout does not occur anymore.

How is Fiddler using this certificate? In my code I also attach the certificate to every call using some code like this

// create binding

((WSHttpBinding)myBinding).Security.Mode = SecurityMode.Transport;

((WSHttpBinding)myBinding).Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;

[...]

// create proxy service client based on binding and endpoint address

proxyService.ClientCredentials.ClientCertificate.Certificate = myX509Certificate2;

Cheers,

Theodor

[EricLaw]

Fiddler uses the supplied certificate in the AuthenticateAsClient call on the HTTPS stream each time a new connection performs the HTTPS handshake.