Interfaçage de mon application avec les systèmes d'authentification existants

Question

J'écris une application Web qui aura son propre mécanisme d'autorisation/d'authentification (cookie traditionnel/utilisateur/passe basé sur la session). Cependant, en fonction de l'organisation qui octroie les licences du logiciel, je souhaite qu'ils puissent brancher leur propre système d'authentification interne existant pour remplacer le mien. Idéalement, ils devraient utiliser le moins de code possible de leur côté; J'essaye d'en faire un service principalement hébergé. Je suis au courant de l'existence d'OAuth, mais je ne comprends pas très bien comment je ferais pour implémenter le système à un niveau supérieur. Des conseils seraient appréciés.

Answer 1

Pour quelle plate-forme développez-vous? PHP, Java, .NET ou autre?

Vous devriez regarder dans SAML et OpenID en plus de OAuth. Ces protocoles sont utilisés pour l'authentification de site Web à site Web, plus souvent que OAuth, qui est principalement utilisé pour les applications client sur le bureau/mobile. Il peut être utilisé, mais c'est ce que les gens ont tendance à utiliser pour.

En général, vous êtes considéré comme le fournisseur de services. Les autres organisations sont des fournisseurs d'identité. Dans SAML, vous redirigiez un utilisateur vers le fournisseur d'identité qui authentifierait (et éventuellement autoriserait) un utilisateur. Ils seraient redirigés vers le fournisseur de services qui serait alors en mesure de les connecter.

Voir les liens de another post pour les liens vers la documentation de protocole. Google Apps a également un good diagram de connexion unique avec SAML en action.

Answer 2

Votre question englobe les éléments mêmes (authn/authz, c'est-à-dire, la stratégie et l'application) que vous souhaitez démêler. La réponse que vous cherchez nécessite de séparer ces préoccupations. La réponse "standard" consiste à séparer la politique authn/authz, en utilisant généralement un PEP (point d'application de politique) pour appliquer les décisions prises par un PDP (point de décision politique). SAML fournit des normes pour la communication entre les deux.

Vous vous retrouvez avec votre application (et généralement beaucoup d'autres) gardée par le PEP. Cela peut être intégré à l'intérieur de l'application (par exemple en tant qu'intercepteur Tomcat), mais mieux, s'exécuter dans un conteneur séparé en tant que proxy. La seule chose accessible de l'extérieur est le PEP. Celui-ci examine chaque requête, s'assure que l'utilisateur est authentifié et (pour SSO) s'assure que chaque requête contient un jeton de sécurité. Si ce n'est pas le cas, le PEP transmet la demande au PDP pour authentification (écran de connexion). Le PDP attache un jeton de sécurité et transmet la demande au PEP. Puisque la requête a maintenant un jeton valide, le PEP le transmet à l'application derrière le pare-feu.