Comment faire de la croix-authentification de domaine en toute sécurité?

. J'ai de domaine A.com, dont l'authentification de l'utilisateur est effectuée au domaine B.com. Actuellement, j'ai mis de telle sorte que le formulaire de connexion est affiché à B.com qui (si réussie) définit le cookie de session et les feux de rediriger vers A.com/loggedin. Cependant, comme le formulaire est posté à l'B.com et le cookie est défini à ce domaine, quand je fais JSON demande de A.com le cookie de session n'est pas disponible un je n'ai aucune idée si elles connecté ou non. La question devient alors: comment résoudre le problème?

J'ai été ressassant une solution dans laquelle je voudrais ajouter un token pour le redirect uri, qui pourraient ensuite être utilisés pour un temps de session authentifiée création avec A.com (le navigateur peut utiliser ce jeton d'authentification de la session avec B.com, de sorte que le témoin devrait être fixé à A.com et seront disponibles sur JSON demandes. Après que le jeton serait invalidé bce).

Cependant, je ne suis pas sûr de savoir comment sécuriser cette solution serait? Ou est-il une autre solution plus sécurisée?

comment sur la solution d'authentification unique. A.com besoin d'authentification, puis de rediriger le serveur d'authentification unique(S.com), S.com de retour à l'utilisateur un longin forme, poste à S.com. S.com reçu et de générer un jeton,et rediriger vers A.com avec le jeton, A.com récupérer le Jeton, appel S.com pour aller chercher de l'logined userinfo.
et certains également, openid solution

OriginalL'auteur crappish | 2013-11-07

  1. 7

    Votre solution actuelle me semble bon et peut être utilisé dans ce scénario. Mais pour vos préoccupations en matière de sécurité, au lieu de fournir un simple jeton que vous pouvez vouloir chiffrer avec de la bonne méthode de chiffrement et sur cette base vous pouvez configurer vos serveurs pour chiffrer et déchiffrer les authentication token avant de l'utiliser. La seule chose est que vous devez choisir le meilleur algorithme pour votre cas.

    Autre que cette solution, vous pouvez donner un pense à la session d'outils de gestion. Session Migration, Session Replication et de Partage de Session sont les options que je peux penser.

    Ici est Lien pour une solution fournie par Oracle pour le partage de session, ce qui je pense peut aider dans votre cas.

    Je ne vois pas comment chiffrer un jeton de l'augmentation de la sécurité? Le serveur doit fournir le jeton de l'utilisateur avant de rediriger lui/elle. Même si le jeton est crypté, il est toujours exposé à la personne "regarder", par exemple dans MitM-Attaques. Le hacker a toujours accès à l'information de la session, étant donné que le serveur serait décrypter le bon jeton crypté... Vous auriez besoin d'un très compliquée algorithme similaire à SSH juste de protéger et de vérifier l'intégrité de la marque. C'est tout simplement paranoïaque, si vous me le demandez... Toutefois, +1 pour la Session de Partage de l'indice.
    Comme Derija dit, le jeton de chiffrement ne résout rien, c'est encore transmis en clair. Mais +1 pour la session de partage de trucs. Merci!
    Cryptage electrique ne fonctionne pas avec les navigateurs web, mais avec une autre application (peut-être un swing app) lorsque le chiffrement est mis en œuvre chez les clients aussi, cela aidera.

    OriginalL'auteur me_digvijay

  2. 3

    Security Assertion Markup Language (SAML, prononcé "sam-el"[1]) est un basé sur XML ouvrir format de données standard pour l'échange d'authentification et d'autorisation des données entre les parties, en particulier, entre un fournisseur d'identité et un fournisseur de service. SAML est un produit de l'OASIS de Services de Sécurité, du Comité Technique. SAML date de 2001; la plus récente mise à jour de SAML est à partir de 2005.

    La plus importante exigence que SAML adresses du navigateur web single sign-on (SSO). L'authentification unique de solutions, qui sont communs à l'intranet de niveau (en utilisant des cookies, par exemple), mais l'extension de ces solutions au-delà de l'intranet a été difficile et a conduit à la prolifération de non-interopérables technologies propriétaires. (Une autre plus récente d'aborder le navigateur d'authentification unique problème est le protocole OpenID.)
    Le SAML spécification définit trois rôles: le principal (en général, un utilisateur), le fournisseur d'identité (IdP), et le fournisseur de service (SP). Dans le cas d'utilisation adressée par SAML, la principale demande un service du fournisseur de services. Le fournisseur de services demande et obtient une assertion d'identité du fournisseur d'identité. Sur la base de cette affirmation, le fournisseur de services peut rendre une décision de contrôle d'accès – en d'autres termes, il peut décider d'exécuter certains services pour le connecté principal.

    Avant la livraison de l'affirmation identitaire de la SP, les Pdi peuvent demander des informations à partir de la principale comme un nom d'utilisateur et mot de passe pour s'authentifier sur le capital. SAML spécifie les assertions entre les trois parties: en particulier, les messages qui affirment l'identité qui sont passés à partir de l'IdP de la SP. SAML, un fournisseur d'identité peut fournir des assertions SAML pour de nombreux fournisseurs de services. À l'inverse, le PS peut compter sur la confiance des affirmations de nombreux indépendants, les personnes déplacées.
    SAML ne précise pas la méthode d'authentification à l'identité du fournisseur; il peut utiliser un nom d'utilisateur et le mot de passe, ou de toute autre forme d'authentification, y compris l'authentification multi-facteurs. Un service d'annuaire, qui permet aux utilisateurs de se connecter avec un nom d'utilisateur et le mot de passe, est une source typique de jetons d'authentification (par exemple, les mots de passe) à un fournisseur d'identité. Le populaire common internet de réseautage social ont également pour mission d'identité de services qui, en théorie, pourrait être utilisé à l'appui de SAML échanges.

    http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

    OriginalL'auteur Tashdid Khan

  3. 2

    Oui, il ya plus d'options.

    Pour la connexion Unique, il est un standard ouvert, appelé OpenID/connect (construite sur le toit de oAuth2.0)
    Pour le partage des ressources, l'autorisation et l'authentification n'est oAuth.

    Choses à garder à l'esprit.

    1. Toutes ces solutions sont un peu plus de contrôlée de fuites de sécurité - utilisation attentivement.
    2. Toutes ces solutions vous laisser vulnverable de XSS, de l'homme du milieu et de détourner /rejeu.
    3. Parce que des points 1 et 2, attention à la mise en œuvre est essentielle.

    Tirer parti des travaux déjà réalisés par la communauté.

    oAuth 1.0 a (encore largement acceptée comme la plus sûre des modèles à ce jour) - http://tools.ietf.org/html/rfc5849
    oAuth 2 - http://oauth.net/2/ (en utilisant openID pour l'autorisation construit sur le haut de oAuth2)

    oAuth 2 n'est PAS un remplacement pour oAuth 1a - c'est tout à fait nouveau (moins sûr) idée fortement dépendant de l'SSL - oAuth1a est encore le plus sûr - mais seulement aussi bon que votre mise en œuvre et la compréhension des faiblesses potentielles.

    Vous êtes probablement à la recherche pour openID connect idées - mais oAuth info est également utile...

    SOI - point de départ de quelques différences

    openID connect (couches sur le protocole oAuth 2)

    oAuth concepts

    SOI - intéressant à lire

    Je ne suis pas du tout convaincu de la accepté de répondre ici. Chiffrer le jeton n'est pas suffisant. Sans signatures et des vérifications d'identité ce n'est certainement grande ouverte à des attaques?
    OAuth 1.0 devrait absolument pas doit plus être utilisé car il est rendu obsolète par le protocole OAuth 2.0 tel que spécifié dans la RFC: tools.ietf.org/pdf/rfc6749.pdf

    OriginalL'auteur LFN

  4. 1

    À l'aide d'un jeton d'authentification devrait fonctionner très bien, mais tenir compte de ces points:

    • Utiliser un GÉNÉRATEUR pour générer le jeton, et de générer une longue jeton pour éviter bruteforcing
    • Assurez-vous utilisé un jeton sera automatiquement invalidé pour éviter replay-attaques

    Ces deux points sont très critiques à mon avis, pour prévenir le détournement de l'jeton d'authentification d'une réutilisation. Également limiter le temps de le jeton est valide (30 secondes doit être fine) afin de prévenir l'abus des vieux ou inutilisés jetons.

    Qu'en signant le jeton? Sinon comment auraient-B.com connaître le jeton a été délivré par A.com?

    OriginalL'auteur thebod