Comment définir le délai d'attente correctement lorsque la fédération avec l'ADFS 2.0

Je suis avec ADFS 2.0 pour un certain temps et je comprends comment les choses fonctionnent. J'ai fait des dizaine de coutume RPs, personnalisé STSes ainsi que l'aide de l'ADF comme s'appuyant STS.

Cependant, j'ai une simple exigence qui je n'arrive toujours pas à réaliser.

Je veux que mes utilisateurs d'être forcé de reconnecter après un certain temps fixe. Disons 1 minute, à des fins de test.

D'abord, j'ai fait quelques corrections sur les RPs côté. Il semble que, pour une raison inconnue, le RP conserve la session, même si le jeton est validTo points dans le temps. Cela contredit ce que Vittorio Bertocci dit dans son livre (page 123), où il montre comment effectuer coulissantes expiration - il dit que "Le SessionAuthenticationModule prendra en charge la session expirée juste après". Eh bien, pour moi, il n'est pas, cependant j'ai trouvé un truc ici http://blogs.planbsoftware.co.nz/?p=521 prendre un coup d'oeil à la "si" clause:

        sam.SessionSecurityTokenReceived +=
            ( s, e ) =>
            {
                SessionAuthenticationModule _sam = s as SessionAuthenticationModule;

                DateTime now = DateTime.UtcNow;

                DateTime validFrom = e.SessionToken.ValidFrom;
                DateTime validTo   = e.SessionToken.ValidTo;

                try
                {
                    double halfSpan = ( validTo - validFrom ).TotalSeconds / 2;
                    if ( validTo < now )
                    {
                        _sam.DeleteSessionTokenCookie();
                        e.Cancel = true;
                    }
                }
                catch ( Exception ex )
                {
                    int v = 0;
                }
            };

Cette astuce résout le problème à la RPs côté. Lorsque le jeton est invalide, l'application efface et redirige vers la page de connexion.

Maintenant vient le problème. Ma page de connexion utilise le FederatedPassiveSignIn de contrôle. Lorsque l'utilisateur clique dessus, il redirige le navigateur vers le ADFS.

Mais ADFS heureusement crée un nouvelle session sans aucune invite de l'utilisateur.

J'ai mis le jeton de la durée de vie pour ce RP à 1:

Set-ADFSRelyingPartyTrust -Targetname "myrpname" -TokenLifetime 1

et à l'aide de Get-ADFSRelyingPartyTrust je peux voir qu'il est mis à 1 (j'ai même l'impression que le jeton validTo sur ma page pour confirmer que c'est réglé correctement).

Puis j'ai mis ADFS propriétés avec ADFS-SetProperties:

ADFS-SetProperties -SsoLifetime 1
ADFS-SetProperties -ReplyCacheExpirationInterval 1
ADFS-SetProperties -SamlMessageDeliveryWindow 1

mais toujours pas de chance. Je suis coincé maintenant.

Le scénario fonctionne correctement avec mon custom STS lorsque la validité de la STS session est basée sur des Formes de cookie si j'ai mis le STS formes cookie délai d'attente à 1, après 1 minute d'inactivité au sein de ma demande de RP, je suis redirigé vers la page de connexion de mon RP qui redirige ensuite vers les STS qui présente sa page de connexion.

Cependant, ce n'est pas le cas avec ADFS 2.0. Après une minute d'inactivité, je suis redirigé vers la page de connexion de mon RP qui redirige vers ADFS la page de connexion qui à son tour renvoie heureusement tout comme la session serait toujours actif au sein de ADFS.

Je voudrais quelqu'un pour:

(1) jetez un oeil à le hack décrit en haut et d'expliquer pourquoi l'expiration d'un jeton n'est pas automatiquement rejeté et ces moche hack est nécessaire

(2) expliquer comment bien timeout de la session à l'ADFS 2.0 côté pour une demande de renouvellement du jeton est surveillé avec une page de connexion.

Merci d'avance.

modifier

Je peux confirmer que le réglage de tous les paramètres ci-dessus à 1 minute fait la ADFS session invalide après 5 minutes (ou plus). C'est strage et il semble que je fais une erreur fondamentale ou 5 minutes, c'est le minimum acceptable.

Ma (2) ci-dessus est maintenant, alors juste pour confirmer et expliquer mon observation.

OriginalL'auteur Wiktor Zychla | 2012-02-03