Partage du système de connexion entre ASP classique et ASP.Net

Un client utilise ASP classique pour se connecter à son backoffice Web.Partage du système de connexion entre ASP classique et ASP.Net

J'ai écrit une nouvelle application ASP.Net à inclure dans le backoffice, et j'ai besoin d'utiliser le système de connexion déjà existant, de sorte que lorsqu'ils sont connectés, ils n'ont pas besoin de se reconnecter dans la nouvelle application ASP.Net Les noms d'utilisateur et les mots de passe sont stockés en tant que texte clair dans une base de données SQL Server, accessible depuis mon application ASP.Net.

Quel serait un moyen efficace d'intégrer ces systèmes?

Ma meilleure idée actuelle est: Dans le lien vers mon application ASP.Net, je créer un lien vers une connexion page « passerelle » avec leur code d'utilisateur et un mot de passe secret commun + haché dans le querystring. Je compare ensuite cela au mot de passe de l'utilisateur dans la base de données ... Mais le problème est, que si cette chaîne de requête est interceptée, elle peut être utilisée pour accéder au site asp.net, sans connaître le nom d'utilisateur et le mot de passe ...

Je suis susceptible d'oublier quelque chose de simple.

Source

2009-05-28 Kjensen

Si vous mettez des hachages dans la chaîne de requête, ils doivent être expirés, c'est-à-dire que vous ajoutez également la date et l'heure à laquelle elle expire, et envoyez-les également. Bien sûr, ils pourraient toujours utiliser cela, mais au moins, il expire. – PQW

Je pense que votre idée est sur la bonne voie.

Comme vous le savez probablement déjà, asp classic et asp.net ne peuvent pas partager le même état de session, vous avez donc besoin d'un mécanisme pour vous connecter de l'un à l'autre.

Ce que je ferais est: quand quelqu'un se connecte, créez un GUID unique que vous enregistrez dans la base de données pour cet utilisateur. Lorsque vous passez d'un site à l'autre, passez ce GUID dans la chaîne de requête. Lorsque vous essayez de les enregistrer automatiquement dans l'autre site, recherchez ce GUID et voir s'il est attaché à n'importe qui. Si c'est le cas, connectez-les.

De cette façon, vous ne transmettez rien que l'utilisateur pourrait deviner ou déchiffrer.

Source

2009-05-28 15:43:31 AaronS

Si vous souhaitez enregistrer une valeur dans la base de données dans ASP et comparer cette valeur dans le code ASP.NET, pourquoi ne pas enregistrer un indicateur booléen indiquant l'état connecté, à la place? – Cerebrus

Parce que le point est de les connecter automatiquement d'un environnement à l'autre. Si vous vous connectez sur le côté asp.net, puis allez sur le côté ASP. il n'y a aucun moyen de savoir qui est cette personne automatiquement. Définir un drapeau sur la base de données ne vous aide pas du tout dans ce cas. En enregistrant le GUID, vous pouvez rechercher quelle personne appartient au GUID, puis les enregistrer automatiquement dans l'un ou l'autre des environnements. – AaronS

Downvote ?! Wtf ?! – Kjensen

Comment le système ASP classique maintient-il l'état de connexion? "Piggy-backing" off ce serait votre meilleur pari, de loin.

Tous les systèmes ASP classiques sur lesquels j'ai travaillé utilisent des cookies pour le suivi des informations d'authentification. Il vous suffit donc de les lire et de les comparer à la base de données à laquelle vous avez accès.

Comme les informations sont stockées dans une session ASP classique, pourriez-vous ajouter une « page redirect » sur le côté ASP classique des choses qui est l ' « entrée » au nouveau module et provoquer ce pour écrire le des données utiles en tant que cookies, ou déclencher un POST à votre page de démarrage? En utilisant des cookies ou une requête POST, vous minimisez votre souci d'avoir l'url "piraté" permettant à quelqu'un d'entrer dans le site ASP.net sans nom d'utilisateur/mot de passe.

Source

2009-05-28 15:41:54 Rob

Ils utilisent la session - et qui ne peut pas être partagée entre ASP et ASP.Net (pour autant que je sache). En regardant les cookies, quand je suis connecté à leur système d'administration, je reçois un cookie pour la session appelée "ASPSESSIONxxxxxxxxxxx" qui contient une chaîne de non-sens "DBHPNPCDKCJHOMHDPFOHEDPA". Donc le ferroutage sur les cookies semble hors de question. – Kjensen

Je suis d'accord avec Rob, un schéma de redirection est probablement ce que vous finirez avec .NET ne peut pas vérifier l'état de la session du site ASP directement. Cette méthode aura également l'avantage de fonctionner sur différents domaines, mais il n'est pas simple de la sécuriser. Si vous vous souciez de la sécurité, vous devez faire très attention à la manière dont vous validez/invalidez les données transmises entre les sites. Vous ne voulez pas vous retrouver avec un système où vous pouvez vous connecter en devinant ou en rejouant une URL. Par exemple, la redirection SAML utilise des certificats de chaque côté de la redirection pour sécuriser les données transmises. – JohannesH

Partage de l'état de la session entre ASP et ASP.NET: http://msdn.microsoft.com/fr-fr/library/aa479313.aspx –

Impossible de le soumettre via Form et pas via Querystring? Cela éliminerait la possibilité d'être intercepté dans l'url.

Source

2009-05-28 15:42:03 TheTXI

L'interception/l'abus de publication n'est que légèrement plus difficile que l'obtention, n'est-ce pas? – Kjensen

Si l'interception est un problème grave, vous devez exécuter le site via HTTPS. Sinon, l'utilisation de UserID + Nonce qui est ensuite hachée par le mot de passe est raisonnablement forte. Vous pouvez également obtenir l'application ASP pour ajouter un cookie de session GUID une fois la connexion terminée et stocker ce GUID dans une table DB. Votre ASP.NET peut rechercher le GUID du cookie pour voir si la connexion a été effectuée. Si vous incluez la valeur de cookie de session ASP dans la table, vous pouvez être raisonnablement certain que la session ASP en cours correspond à la même session que celle utilisée lors de la création du GUID.

Source

2009-05-28 16:26:38 AnthonyWJones

Vous êtes à juste titre préoccupé par une attaque de type MITM, peut-être par empoisonnement du cache DNS ou similaire. Selon vos circonstances, il peut suffire d'atténuer les effets potentiels en ajoutant une contrainte de temps au jeton de connexion transmis à travers les limites de l'application. L'approche 'GUID dans la base de données' est déjà utilisée avec succès dans le passé, aussi bien pour passer des utilisateurs entre deux applications partageant la même base de données d'authentification, que pour des scénarios de type 'réinitialisation du mot de passe'. Vous pouvez "expirer" ceci en ayant une colonne supplémentaire sur l'enregistrement spécifiant la date à laquelle le GUID a été ajouté, et en modifiant votre code d'application pour seulement connecter les authentiques GUID qui ont moins de x minutes/heures/jours.

Une alternative pourrait être d'éviter des champs supplémentaires dans la base de données par concaténer quelque chose comme:

UserId + [Value representing current time to nearest x minute/hour /day] + Salt

.. hachant, puis dupliquer alors votre algorithme sur l'autre application et en comparant les deux valeurs générées.

En général, je pense que votre solution proposée est appropriée au problème. Ce n'est certainement pas trop compliqué.

Source

2009-06-04 12:38:04 Jamie

Partage du système de connexion entre ASP classique et ASP.Net

Répondre

Questions connexes