2013-02-07 1 views
2

Nous travaillons actuellement sur un projet SSO qui utilise ADFS 2.0. en tant que fiducie IDP/CP. L'une des exigences de base de la conception de l'application est de ré-authentifier l'utilisateur après une période d'inactivité (peut être n'importe quoi). Après une recherche approfondie, je n'ai trouvé que quelques implémentations (en dehors des exemples SharePoint) qui parlent des paramètres WebSSOlifetime and TokenLifeTime dans le serveur ADFS. Je comprends WebSSOLifeTime est un paramètre serveur (valeur par défaut: 480) et TokenLifeTime est un paramètre de niveau RP (valeur par défaut 0 - 10 heures) pour l'expiration de jeton. Pour tester les paramètres au hasard, j'ai changé la valeur WebSSOlifetime à 5 minutes et TokenLifeTime à 3 minutes pour mon application RP. Mais il n'a pas déclenché la ré-authentification après une période d'inactivité de 5 minutes (définie dans WebSSOlifetime). Les applications RP que j'ai testées incluent - Applications Google - SSO intégré ADFS et une application d'une seule page pour tester les valeurs de réclamation. Ce sera génial si quelqu'un peut poster des pointeurs pertinents sur les fonctionnalités de maintenance de session ADFS 2.0.Session TimeOut ADFS 2.0 dans un scénario SSO

Répondre

2

J'ai trouvé la solution après un peu de transpiration. This poste dans le Stackoverflow m'a fourni un point de départ (Merci beaucoup pour ça!). Le paramètre clé qui contrôle l'invite de connexion pour IP/STS est la valeur de fraîcheur (qui est un paramètre facultatif comme mentionné dans le Oasis documentation). Ce paramètre (défini comme freshness = "0") lorsqu'il est inclus dans la section federatedAuthentication de votre fichier web.config demandera à l'IDP de vérifier la valeur de fraîcheur du jeton en fonction de l'heure actuelle dans le paramètre WCT. Après cela, j'ai trouvé (après beaucoup de tests) que le TokenLifeTime set à travers le script shell entrer en image. Ce (TokenLifeTime) contrôle le temps que l'utilisateur peut être actif avant de le rediriger vers l'écran de connexion.

Comme vous pouvez le voir dans l'URL de la requête: https://XXX/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fXXX%2fXXX&wfresh=0&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fXXX%252fDefault.aspx&wct=2013-02-14T01%3a36%3a17Z

Le wfresh et wctx valeur est passée à l'IDP pour la vérification. Je ne sais toujours pas comment tout se synchronise dans les coulisses (fraîcheur, TokenLifetime et WebSSOLifetime). Une bonne explication sur l'arrière-plan serait très utile (et of course will add some more reputation :)).