Nous avons une application basée sur le navigateur où nous souhaitons rendre l'utilisateur récidivant lorsqu'il est entré. Donc, lorsqu'ils accèdent à cette URL, nous voulons qu'ils soient présentés avec l'invite de la broche afin de pouvoir récidiviser. Y a-t-il une façon raisonnable de faire ça?
Informations ajoutées: Ceci est pour une carte CAC et les postes de travail ont une activité et une timbale sur eux. De plus, je pourrais ajouter un service aux postes de travail si nécessaire. Les navigateurs sont tous IE7. Le serveur Web est IIS 6 et les pages sont écrites dans ASP.NET (principalement).
3 Réponses :
Il y a quelques pièces de logiciel différentes impliquées ici.
première est la carte elle-même. Pour effectuer une signature numérique, le CAC doit être dans un état "vérifié", ce qui signifie qu'une broche a été entrée après inséré de la carte. Au-delà de cela, chaque clé de la carte a un drapeau indiquant si la broche doit être entrée à chaque fois que la clé est utilisée. Je n'ai pas vérifié, mais je pense que cela est défini pour la liste des touches "Email" sur un CAC. Ainsi, vous auriez besoin de trouver quelles clés ont cet ensemble de drapeau «toujours vérifiez» et configurez le validateur de chemin sur le service pour accepter uniquement ces clés. Vous pourrez peut-être avoir besoin d'une OID particulière dans l'utilisation de la clé étendue ou d'exclure certains des certificats intermédiaires DOD du bâtiment de chemin (signalez-le comme révoqué, peut-être).
Le middleware sur la machine parle à la carte pourrait également cacher la goupille et la fournir à la carte chaque fois que la carte indique qu'elle nécessite une broche avant de terminer une opération. Je pense que cet activclient faisait cela avec sa fonctionnalité de mise en cache des broches via la version 6, mais dans la version 7, cette option semble avoir disparu. Je n'ai rien trouvé de tel dans le soutien de PIV intégré dans Windows. Cette "fonctionnalité" pourrait compromettre la sécurité, de sorte que je suppose que c'était délibérément supprimé et qu'il n'y aurait pas de piratage de registre ni de restaurer le comportement. C'est quelque chose que vous n'auriez pas le contrôle, sauf si vous gérez les machines des utilisateurs; Il n'y a pas d'option HTTP en-tête ou TLS que vous pouvez utiliser pour appliquer l'entrée PIN. Mais, avec de nouveaux systèmes, cela ne devrait pas être un problème.
sur le côté serveur, une poignée de main complète doit se produire pour que le client effectue une authentification. L'authentification du client ne se produira pas s'il y a une session TLS valide. Donc, vous auriez besoin de trouver un moyen d'invalider la session TLS (pas de la session d'application, qui est probablement liée à un cookie HTTP) avant de demander l'authentification ou de diriger la demande d'authentification à une autre interface qui ne dispose pas de sessions activées. < / p>
Merci Sylvarking, je pense que je comprends ce que vous dites. J'ai beaucoup de contrôle sur les serveurs et les postes de travail (quelques centaines d'entre eux) alors peut-être que je pourrais peut-être faire quelque chose dans le navigateur qui entraînerait une broche de la carte à puce?
C'est exact. Si vous administrez les postes de travail, vous pourrez peut-être configurer tout le logiciel de lecteur de carte pour demander à la broche plus souvent. Par exemple, j'ai utilisé ActivClient comme logiciel de lecteur de carte. C'est ce qui apparaît réellement la boîte de dialogue pour demander le code PIN, et il y a un paramètre pour contrôler la fréquence à laquelle un utilisateur doit l'entrer.
Je me sens chanceux d'avoir trouvé quelqu'un avec une expérience de vigueur. Votre réponse m'a incité à regarder le service de mise en cache des PIN, que je n'avais pas vu auparavant. Je peux voir 12 propriétés et l'une d'entre elles s'appelle "Activer la mise en cache des broches". Je vais essayer de tourner ça.
Le service de mise en cache des broches est une propriété dans le gestionnaire de configuration ActivClient.
Pour ne pas gâcher avec des termes - c'est le "logiciel de carte" non "Logiciel de lecteur de carte" en modifiant les paramètres de cache de code PIN, vous ne pouvez pas battre la façon dont SSL fonctionne dans le navigateur. Si vous avez besoin de flux d'authentification personnalisés, consultez peut-être OpenID et TrustBeerer.com OpenID Service. Si je me souviens bien, ils implémentent une authentification basée sur le plugin où il existe un plugin personnalisé qui parle à la carte. Cela déclenche probablement une boîte de dialogue PIN (comme il utilise une opération de signe implicite? Je ne connais pas les détails ..) Pour chaque transaction.
Merci encore à nouveau Martin, je soupçonne que j'utilise le mauvais vocabulaire dans de nombreux endroits, ce qui rend difficile la compréhension de mon objectif. J'apprécie que tu es tellement patient.
Il existe deux façons de faire une authentification client SmartCard sur le Web: TLS standard / SSL ou plug-ins personnalisés pour le navigateur. Je suppose que vous parlez de navigateurs Web standard (c.-à-d. / FF / SAFARI) et authentification SSL.
Il y a deux choses qui comptent pour les invites de la broche:
À la fin, du point de vue de la sécurité, il s'agit de la carte qui sait quand "demander" une broche - certaines cartes et clés nécessitent une goupille pour chaque opération avec la clé, certaines cartes sont ok pour obtenir une broche une fois et Laissez les touches à l'état authentifié jusqu'à ce qu'elle soit retirée du lecteur ou réinitialisée par une application.
Si la session dans le cache du navigateur ne peut pas être réutilisée ou lorsque la connexion est établie, le middleware de la carte à puce (PKCS n ° 11 sur Linux, le module Cryptoapi / BASECSP sous Windows ou Tokend sur OSX) doit parler aux clés de la carte. Si l'état d'authentification sur la carte nécessite une broche à saisir, un rappel est généralement déclenché par le navigateur. Ou si le middleware sait qu'il aura besoin de la broche, il le demandera avant de parler à la carte.
Il n'y a pas de relation 1: 1 entre la saisie d'une goupille et rééditer ré-authentifier les droits d'accès à la clé privée et ré-authentifier la session SSL.
Avec SSL standard, vous dépendez de la manière dont SSL est implémentée dans les navigateurs et ne peut pas avoir de "ré-authentifier en entrant en entrant" sur le côté du client.
Si vous utilisez Linux, alors avec OpenSC (qui, afaik peut utiliser des cartes CAC), vous pouvez définir "transaction_reset" dans opensc.conf sur true, ce qui donne la réinitialisation de la carte après chaque transaction (chaque négociation de session SSL) Et de cette façon, vous pouvez être sûr que chaque fois que vous ouvrez une nouvelle session SSL, l'utilisateur doit entrer dans la broche à nouveau. Ceci est une configuration latérale du client cependant, pas une fonctionnalité initiée par le serveur.
Merci Martin pour l'excellent commentaire. Je vois que j'aurais dû fournir plus d'informations mais je suis toujours très ignorant de ce qui est significatif dans cette situation. Les postes de travail ont le middleware appelé Activity ou ActivClient. Le processus s'appelle accoca.exe. Ils fonctionnent également de Tumbleweed.
En outre, je reçois de votre commentaire que mon défi consiste à convaincre la carte qu'il doit poser une nouvelle demande à une épingle. Je n'ai pas encore compris comment le middleware fonctionne encore mais il serait raisonnable de dire que lorsque l'utilisateur accède à une URL, je pourrais mettre quelque chose sur la page Web qui ferait décider que le CAC décide qu'il doit demander une épingle? Peut-être que je pourrais tuer la session SSL? (Désolé si c'est une idée stupide, je suis un peu confus).
Lorsque je désactive l'état SSL (à l'aide de IE7-Tools-Options-Internet Options-Content-Effacer State SSL, il m'inquitte du cert mais pas de la broche. Si je choisis le certificat correct, cela fonctionne, si je choisis le mauvais cert, il échoue . Alors, pourquoi cela me demanderait-il à nouveau pour le cert, s'il ne va pas pour le pivot? Je ne comprends pas!
Navigateur SSL Cache Supprime la session. Donc, probablement, le middleware ne met pas en œuvre aucune tours de broche spéciale et fonctionne exactement la manière dont je décris - une fois que la carte est en état authentifié, la clé peut être utilisée tant que l'application n'est pas redémarrée ou la carte est supprimée. Il demande au certificat de savoir quelle clé privée que vous souhaitez utiliser et si vous choisissez votre carte à puce, elle peut l'utiliser pour établir une nouvelle session car la touche de la carte est déjà dans l'état authentifié.
Ah, je vois. Il demande le certificat parce que vous pourriez faire différentes choses avec différentes clés en même temps. J'aurais dû penser à cela! Vous auriez peut-être vu mon autre question où j'ai découvert que la sortie de IE7 provoquera toujours une invite de code PIN La prochaine fois que IE7 commence. Cela me conduit à croire que IE7 fait quelque chose à la sortie qui "réinitialise" l'état de la carte. Si je pouvais trouver ce que je serais plus proche de ce dont j'ai besoin (je pense).
Oui, acquérir un contexte crypto de Cryptoapi et le libérant (c'est ce qui se passe lorsque vous commencez / fermer une application) réinitialiser la carte. Ce n'est pas "quelque chose" qui doit être cru, car il s'agit d'une simple paire ScardConnect () ScardDisconnect () requise pour accéder aux cartes à puce. Vous ne pouvez pas demander une réinitialisation de la carte de la couche SSL. C'est comme savoir que tourner la clé commence ou arrête une carte, vous pouvez le faire arrêter si vous atteignez 100 km / h en piratant des fils sur le compteur de vitesse, mais ce n'est pas la façon dont une voiture (ou un limiteur de vitesse, comme c'est ce que vous avez vraiment vouloir) est censé fonctionner.
Je pense que je l'obtiens maintenant. Merci de m'aider à comprendre. La goupille ne quitte pas la carte à puce et l'heure de la broche est complètement indépendante de la session SSL du navigateur. J'ai mis l'idée d'utiliser un hack pour forcer une nouvelle invite de la broche associée à la compensation de cache SSL dans mon dossier "Pas si bonne idée". Je repousse que l'exigence a changé. Merci encore.
Vous pouvez utiliser une fonction JavaScript pour créer le navigateur d'oublier le cache SSL existant sur quelques navigateurs:
function logout() {
// clear browser authentication cache
// IE specific
try
{
document.execCommand("ClearAuthenticationCache", "false");
}
catch(e)
{
// do nothing
}
// clear for firefox or any browser that supports window.crypto API
if (window.crypto && typeof window.crypto.logout === "function") {
window.crypto.logout();
}
}
S'il vous plaît partager comment ce problème a été résolu. :)
@Kevin I a repoussé l'exigence en expliquant au client que le délai d'attente de la broche sur la carte CAC est totalement indépendant du navigateur. D'un point de vue de la sécurité, il n'est pas une bonne idée d'essayer d'interférer avec le fonctionnement normal. Leur personne de sécurité a convenu qu'il n'était pas nécessaire de retirer le client à chaque fois; Une meilleure approche est de ne pas retentir si elle a expiré.