Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to Logoff with client certificate logon

Former Member
0 Kudos

Hi All,

We have configured the portal to logon with the client certificate. But now it seems we can't logoff normally. After logoff from the portal, it will automatically logon again on the same page. We have configured the ume.logoff.redirect.url and ume.logoff.silent, but these are no use. So is there any helpful idea to configure the logoff url?

Thanks a lot

7 REPLIES 7

Former Member
0 Kudos

Which redirect URL have you configured?

Cheers,

Julius

0 Kudos

Hi Julius,

We configured http://www.google.com for testing.

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

>

> Hi All,

>

> We have configured the portal to logon with the client certificate. But now it seems we can't logoff normally. After logoff from the portal, it will automatically logon again on the same page. We have configured the ume.logoff.redirect.url and ume.logoff.silent, but these are no use. So is there any helpful idea to configure the logoff url?

>

>

> Thanks a lot

Well, you've described it correctly: "it seems we can't logoff".

Actually, you do logoff (technically speaking) - but since you still posess a valid X.509 client certificate and the corresponding private key at the client side, you can use that credential to logon again (creating a new session).

From the user's perspective this looks like as if you have never logged-off.

Yes, that's true - but out of control of the server: the server cannot influence the client regarding the availability of credentials which are under the client's sole control. That effects X.509 client certificates as well as Basic Authentication credentials and "Windows Integrated Authentication" (SPNEGO).

Basic Authentication credentials will not survive the termination of the browser (OS) process.

But for "Windows Integrated Authentication" and also for X.509 client certificates (if stored in the keystore provided / controlled by the OS) you have to logoff on the operating system (OS) level in order to get rid of those credentials which allow to perform an automated logon.

Well, some consider it as "true single sing-on" (logon at the OS level).

Automated Authentication does exactly what it is designed for ...

Regards, Wolfgang

0 Kudos

Hi Wolfgang,

Good explanation! So you mean there is no chance to close the web by click on the logoff? The simplest way to close the web is to close the browser?

Thanks

0 Kudos

>

> Hi Wolfgang,

>

> Good explanation! So you mean there is no chance to close the web by click on the logoff? The simplest way to close the web is to close the browser?

>

>

> Thanks

Well, you should do both: submit the logoff (to inform the server which can then release all resources, including enqueue locks, etc.) and close the browser (to destroy the client-sided credentials). If you have configured your browser to delete also all temporary files when terminating the browser, you are fine - otherwise temporary files might still remain on your local harddisk ...

Don't take me wrong - I'm not in favor of proprietary fat clients.

But the browser is not optimally suited as general purpose frontend (especially for dynamic content).

That's more a general criticism on http and it's usage beyond the initial intend (as "hyper-text transport protocol", so that's about static documents).

Cheers,

Wolfgang

0 Kudos

You can also use training of the users here to close the browser.

Microsoft IE now uses *Registerkarten" (tabs) to open new "links" in the browser, so I guess that this is not an encouraged (intuitive) mainstream practice. I haven't bothered much with their code, just install patches all the time..

Strange as this sounds, the server can protect the client...

SAML is a nice example of this.

Cheers,

Julius

0 Kudos

>

> Strange as this sounds, the server can protect the client...

> SAML is a nice example of this.

Well, SAML 2.0 does not only provide support for SSO but also for SLO (Single Logoff) - across different systems (even across different entities / corporations). But if you choose to authenticate via X.509 client certificates (at the SAML Identity Provider) you'll face the very same "problems" regarding logoff: yes, you actually logoff (technically speaking) - but since the X.509 client certificate is still present at the browser you'll be able to create a new session w/o being prompted for authentication (automated authentication).

SAML 2.0 also covers account linkage / federation support (aka "user mapping") - under the control of the user (who decides which accounts (of the SAML Service Provider and the SAML Identity Provider) shall be linked).