2013-09-05 27 views
6

Zaimplementowałem sesje przesuwne w mojej aplikacji Relying Party, zgodnie z opisem w Sliding Sessions for WIF 4.5. To działa tak dobrze, jak to możliwe, ale jest jeden problem, który wydaje się nikt nie mówi.Ponowne uwierzytelnianie sesji przesuwnych WIF

Jak wynika z połączonego posta na blogu, po wygaśnięciu tokena RP, przy następnym uruchomieniu żądania, token jest ponownie wystawiany ze STS. Zakładając oczywiście, że czas trwania sesji STS jest dłuższy niż czas życia sesji RP, co prawie na pewno ma miejsce w przypadku sesji przesuwnych.

W każdym razie, to całkowicie pokonuje cały punkt sesji przesuwnych.

Nikt nie mówi o tym, co należy zrobić po wygaśnięciu sesji RP. To, co chcę chce jest, jeśli sesja RP przekroczyła limit czasu (zwykle dlatego, że ktoś odszedł z jego biurka na 10 minut), jest dla mojej aplikacji przekierowanie na stronę logowania STS, gdzie użytkownik może ponownie się uwierzytelnić, a następnie zostanie przekierowany wróciłem do strony, o którą prosiłem; a może na stronę, na której byłem, kiedy złożyłem wniosek.

Jestem prawie pewien, że jest to możliwe, ale absolutnie nie mam pojęcia, jak to się robi.

Oto mój kod z global.asax:

private const int InactivityTimeout = 5; // minutes 

    void SessionAuthenticationModule_SessionSecurityTokenReceived 
     (object sender, SessionSecurityTokenReceivedEventArgs e) 
    { 
     var now = DateTime.UtcNow; 
     var validFrom = e.SessionToken.ValidFrom; 
     var validTo = e.SessionToken.ValidTo; 
     double halfSpan = (validTo - validFrom).TotalMinutes/2; 
     if (validFrom.AddMinutes(halfSpan) < now && now < validTo) 
     { 
      // add more time 
      var sam = sender as SessionAuthenticationModule; 

      e.SessionToken = sam.CreateSessionSecurityToken(
       e.SessionToken.ClaimsPrincipal, 
       e.SessionToken.Context, 
       now, 
       now.AddMinutes(InactivityTimeout), 
       e.SessionToken.IsPersistent); 
      e.ReissueCookie = true; 
     } 
     else 
     { 
      // re-authenticate with STS 
     } 
    } 

Moje pytania:

  1. jest klauzula else właściwym miejscem, aby umieścić logikę ponownego uwierzytelniania?
  2. Jeśli tak, proszę podać przykład, ponieważ nie mam pojęcia.
  3. Jeśli odpowiedź na nr 1 brzmi "nie", to czy istnieje osobne wydarzenie, które muszę zasubskrybować, które powie mi: "Hej, Twój token bezpieczeństwa sesji wygasł!"?

Odpowiedz

2

Zalecam, aby zsynchronizować czasy sesji sesji na STS i RP (s).

Możesz ustawić czas życia sesji na 10 minut na STS i 10 minut na RP i użyć podejścia z sesją przesuwną na RP. Po 10 minutach bezczynności obie sesje wygasną, a użytkownik powinien zostać poproszony o ponowne uwierzytelnienie.

Jeśli masz wiele RP-ów, możesz wdrożyć formę utrzymywania przy życiu od RP do STS - np. ładuj zasób ze STS na każdej stronie na RP. Za każdym razem, gdy strona zostanie załadowana na RP, zasób keep-alive zostanie załadowany ze STS - odświeżając sesję STS. Po 10 minutach bezczynności oba czasy się skończyły, a użytkownik musiałby ponownie się uwierzytelnić.

"Zasób ze STS" może oznaczać stronę internetową (Web Forms/MVC) załadowaną w niewidoczny element iframe. Ważne jest to, że jest to zarządzany program obsługi, więc żądanie jest obsługiwane przez ASP.NET.

Co do pytania, jeśli synchronizować wcieleń sesji więc czas razem:

  1. Nie, nie trzeba dodawać żadnego kodu w klauzuli innego. Jeśli token wygasł, WIF przekieruje do STS.
  2. Wystarczy usunąć klauzulę else.
  3. Pozwól WIF obsługiwać to za Ciebie.

Dla kompletności, jeśli nie możesz zsynchronizować okresów życia sesji, możesz wyzwolić federacyjne wylogowanie po wygaśnięciu sesji RP. Poniższy fragment uruchamia wylogowanie u skonfigurowanego wystawcy (STS). Można umieścić to w klauzuli innego, aby wywołać SignOut na pierwsze żądanie po wygaśnięciu sesji RP:

using System.IdentityModel.Services; //WIF 4.5 

var stsAddress = new Uri(FederatedAuthentication.FederationConfiguration.WsFederationConfiguration.Issuer); 
WSFederationAuthenticationModule.FederatedSignOut(stsAddress, null); //Optional replyUrl set to null 

nadzieję, że pomoże!

+0

Dzięki za odpowiedź. Nie chcę zsynchronizować czasu życia sesji, ponieważ zmusiłoby to użytkownika do ponownego uwierzytelnienia co 10 minut. Wyobraź sobie, że musisz to zrobić podczas pracy w Visual Studio. Chcę, aby działał jak mój komputer z Windows: moja sesja pozostaje ważna tak długo, jak długo korzystam z komputera. Ale jeśli jestem bezczynny przez 5 minut, blokuje moją stację roboczą i muszę ponownie uwierzytelnić. Skojarzone wylogowanie może działać, o ile mogę wrócić do strony, na której skończyłem. Spróbuję. –

+0

Nie widzę sposobu, w jaki użytkownik musiałby ponownie uwierzytelniać się co 10 minut, gdy zaimplementowano sesje przesuwne na RP. – klings

+1

Jeśli ustawię czas życia sesji na 10 minut w STS zgodnie z zaleceniami, token STS wygaśnie po 10 minutach. RP nie może wydłużyć czasu życia tokena na dłużej niż pozwala token STS. Chyba że źle zrozumiałem coś, co napisałeś? –