[.NET] Client certificaat sessie uitloggen

[keesdewit]

Beste Mensen,

Na lang zoeken heb ik nog niets gevonden om gebruikers uit te loggen die met een client certificaat (X.509) zijn ingelogd. Heeft er iemand een idee hoe ik dit in C# of VB kan oplossen? Ik heb oplossingen vanuit de client (javascript) gezien, maar dat werkt alleen bij IE. Er moet toch een manier zijn om de sessie vanaf de server te beeindigen?

[leuk_he]

Niet gehinderd door details van jouw omgeving kan ik zoiets makkelijk roepen:

quote: http://www.w3schools.com/ASP/asp_sessions.asp

Use the Abandon method to end a session immediately:
<%
Session.Abandon
%>

En in een sessie variable bijhouden dat de sessie wel of niet geintialiseerd is ofzo.....

[keesdewit]

De omgeving is: .NET 3.5 IIS7

@leuk_he: De session.abondon() verbreekt inderdaad de sessie, maar niet de client certificaat sessie.

[lier]

keesdewit schreef op maandag 13 december 2010 @ 11:43:
De omgeving is: .NET 3.5 IIS7

@leuk_he: De session.abondon() verbreekt inderdaad de sessie, maar niet de client certificaat sessie.

Zou je eens kunnen vertellen wat je met "client certificaat sessie" bedoeld?
Zou je verder eens uit willen leggen wat de bedoeling is en welke problemen/symptomen momenteel op treden?

Verder is een sessie best wel server side...

[Woy]

Je zult denk ik toch wat meer over de opzet van de authenticatie moeten vermelden.

In asp.net is het inderdaad zo dat de Authentication los staat van de Session. Bij standaard FormsAuthentication werkt dat met een (persistent) cookie. Die kun je dan dus ook gewoon weg gooien, en dan ben je uitgelogd.

Hoe werkt het Login gebeuren bij jouw applicatie? Als er standaard een client-certificaat meegestuurd word, dan kun je een gebruiker wel uitloggen, maar het volgende request word dat certificaat weer meegestuurd, en dus is de gebruiker weer ingelogd.

Geef dus inderdaad eens aan hoe je opzet met Client Certificaten nu is geconfigureerd/geimplementeerd op zowel de server als de client, en geef exact aan wat je wil.

[ Voor 13% gewijzigd door Woy op 13-12-2010 12:54 ]

[Janoz]

Afaik spreek je bij een client certificaat niet over in en uitloggen. Met het certificaat kan worden bewezen dat degene die de pagina opvraagt ook degene is die in het bezit is van het certificaat. Deze authenticatie is request gebaseerd. Er is dus helemaal geen spraken van het beginnen van een sessie, dus ook niet van het eindigen van een sessie.

[keesdewit]

Wij hebben een active directory met een certificate service draaien om gebruikers te herkennen. Als men het juiste certificaat in de browser selecteerd zal IIS het certificaat met een AD gebruiker matchen en heeft als uitkomst een ingestelde Page.User.Identity of een 403 error

Nu kan het voorkomen dat één klant meerdere portals moet kunnen benaderen, maar daarvoor heeft hij wel een ander certificaat nodig. Het probleem is dat als je éénmaal een certificaat hebt gekozen je er niet mee kunt uitloggen (althans dat is de vraag). Het certificaat komt immers wel door de IIS controle, maar in specifieke portal applicatie wordt de gebruiker uit het certitifcaat niet in de sql database gevonden. Nu zou het mooi zijn als men kon uitloggen in plaats van de knop binnen IE: "Clear SSL State" of alle windows dicht en opnieuw proberen.

Het inloggen zelf verloopt via ons identity portal, alwaar de Page.User.Identity in saml claims naar de uiteindelijke applicatie (portal) wordt gepost. Het identity platform zitten meerdere authenticatiemiddelen aan vast gekoppeld, waaronder dus X509. Als men dus uitlogt (via een federated logout) wordt de client naar het identity gedeelte geredirect met een signout parameter en is hij uitgelogt. Nu is een submap van dit portal met X509 afgeschermd en deze logt dus niet uit. Men komt nu netjes terug op het authenticatiemiddel keuze scherm, maar als er vervolgens op X509 wordt geklikt, is de oude keuze nog actief.

[Janoz]

Het lijkt mij heel voor de hand liggend dat jij als server zijnde geen enkele invloed hebt op de SSL state van de client en dat daar dus een expliciete handeling van de gebruikers voor nodig is.

Zoals ik eerder al aangaf. Een certificaat is puur een bewijs van 'dit ben ik'. Dit bewijs wordt bij elk request gedaan. Er is dus geen sprake van een sessie dus ook niet van inloggen. De enige manier om uit te loggen is het certificaat weghalen, en dat is niet iets wat je vanaf de server zou moeten kunnen doen.

Ik vermoed dat je je oplossing in de verkeerde richting aan het zoeken bent. Het probleem is beter aan de andere kant op te lossen. Jullie weten immers welke klant bij welke portals mag komen. Middels het certificaat weten jullie welke klant het daadwerkelijk is. Zorg er dan voor dat dat certificaat voor alle portals werkt waar die gebruiker bij mag komen.

[keesdewit]

@Janoz: Wij hebben er ook al over nagedacht om het certificaat gelijk te trekken bij alle portals, maar dat is om een bepaalde reden niet goed mogelijk, vandaar dat ik richting deze oplossing aan het zoeken was.

Is er geen javascript methode die iets kan doen? Ik heb daar al iets op gevonden, maar dat werkt alleen op IE:

JavaScript:

document.execCommand("ClearAuthenticationCache");

[RobIII]

Ik roep even wat geks; werkt het wijzigen van de Realm niet? Als die bij beide portals hetzelfde is (nu) en je wijzigt in 1 van de portals de Realm, wat gebeurt er dan?

[ Voor 47% gewijzigd door RobIII op 14-12-2010 14:09 ]

[keesdewit]

@RobIII: De Realm of ook wel wtrealm parameter genoemd bepaald de locatie waar de STS (Security token service) de SAML token naar toe POST. Wij werken met 1 IDp (Identity provider) en meerdere saas applicaties. De Realm zal afhankelijk zijn van de applicatie die men probeerde te bereiken.

Het ziet er als volgt uit:

- De smart client gaat naar applicatie A
- Applicatie A staat heeft een passive trust met de IDp en zal deze volgens de instellingen redirecten naar de IDp: http://www.idp.nl/?wa=wsi...f%2fwww.applicatieA.nl%2f ....
- De gebruiker krijgt een keuze scherm met authenticatiemiddelen en kiest voor X509
- Binnen www.idp.nl/x509/ wordt het certificaat gevraagd en gevalideerd (deze submap staat op client cert required)
- Als de X509 klopt dan zal de www.idp.nl een token genereren om deze vervolgens door de browser naar de Realm (www.applicatieA.nl) te POSTEN
- Als de aspecten kloppen van het token zal er een sessie worden opgezet.

Nu gaat het mij om www.idp.nl/x509/ waar de cert keuze actief blijft. Als de klant naar www.applicatieB.nl gaat zal dit ook via dezelfde IDp verlopen, echter is nu de keuze van het certificaat van de vorige login nog actief, waardoor hij niet weer met het keuze scherm komt, maar op basus van de oude keuze door gaat. (nu is de identiteit uit het vorige certificaat niet geldig in applicatieB)

[Woy]

Mja, feitenlijk gaat het hier dus eigenlijk niet om .NET maar om een client-side probleem. Je zult immers de client op een of andere manier zijn certificaat moeten doen "vergeten".

Hooguit zou je iets kunnen doen dat op HTTP nivo een melding terug gegeven word, waardoor de browser besluit het certificaat niet meer te gebruiken. Verder heb ik geen flauw idee hoe de verschillende browsers met dit soort zaken om gaan.

[RobIII]

En als je een 401 forceert als men van ApplicatieA/B naar IDP gaat? Met een .../?wa=wsignin1.0&wtrealm=https%3a%2f%2fwww.applicatieX.nl%2f&force401=true achtig iets? Gewoon keihard een 401 sturen waarna je vervolgens doorgaat as usual... Ik ben niet héél erg thuis in deze materie dus ik roep ook maar wat.

Of misschien heb je hier iets aan?

(En ik doelde op de "Basic realm" die een standaard 401 bevat; geen idee of dat overeenkomt met een "wtrealm")

[ Voor 32% gewijzigd door RobIII op 14-12-2010 15:57 ]

[Alex)]

Ik heb hier niet zo heel veel verstand van, maar ik zie "wa=wsignin1.0" en dat komt van Windows Live af. Jullie federaten met Live ID zo te zien? Microsoft Federation Gateway?