Architecture SSO avenages et inconvenants

par **bpp** » 22 Juil 2009 10:50

Dans la cadre d'une étude je voudrai pouvoir comparer ou tous du moins avoir un contradictoire sur l'architecture SSO : Single Sign-On, j'ai bien cherché mes je ne trouve que les moyens d'implantation ou les apports de l'implantation de cette architecture. Pour autant je voudrai pouvoir soit argumenter le pour et le contre ou tu du moins voir qu'elles en sont les limites.

Par contre même ci la technologie est importante je voudrai plutôt m’attacher aux limite organisationnelles, et voir les améliorations possible et les contournement de sécurité .

Ajout du 22/07/2009 : je vous remercie pour vos réponses, je voudrai enrichir ma question comme suit : ce qui me gène dans le SSO, c’est justement qu’une fois authentifier on peut ce balader de services en services sans trop de difficultés. Je m’explique je panse que dans pas mal de cas il est très difficile de cloisonner des secteurs sur dans un système d’information qui peut allez d’entités à entités (secteur différant voir entreprise différentes mes liez par un même système) sans contraindre à une ré identification qui ferait sauter les avenages du SSO. Donc je voudrais pouvoir enrichir mon étude d’idées organisationnelles qui permettraient de garder une souplesse suffisante tout en évitant les écuelles technologique. En gros peut êtres l’arlésienne. En fait développer une réflexion.

par **jdh** » 22 Juil 2009 11:57

Face à un mot inconnu désignant un logiciel, un produit, une technologie, je me retourne en général vers Wikipedia pour commencer. C'est un bon début.

M'étonnerait que l'on ne trouve rien : "single sign on sso" sur Google c'est 175 millions de pages ...

A noter cette phrase entendue au RMLL 2009 sur ce sujet : "le sso est un problème pour le service informatique et pas pour les utilisateurs". Je trouve cette phrase assez juste.

Si vous voulez d'autres réponses, il va falloir
- faire des EFFORTS sur l'orthographe,
- poser un problème concret : nous ne somme pas là pour faire un stage ou un job d'été à votre place !

par **bpp** » 22 Juil 2009 15:20

J’ai bien réfléchi avant de répondre, pour l’orthographe ce n’est pas de gaité de cœur, mes je suis très dyslexique et pour combattre ça je suis des cours d’orthophonie.

Pour le reste soit je réponds très sèchement, soit je complète ma requête, bon j’ai 43 ans donc pour les études c’est fini, mon propos et basée sur la nécessité de réfléchir aux bute du SSO, surtout quand des entreprises vous demande de l’implanter (plusieurs cas) et que vous essayer de dimensionner correctement le besoin. Je ne veux justement pas m’exprimer sur un cas particulier, mes sur une réflexion général. Sur le nette ou dans des parutions je n’ai rien trouvé de très pertinents, car on rentre très rapidement dans des explications très techniques.
Je souhaite plus tos parler de dimensionnement critique, d’impossibilité organisationnelle et autre, c’est juste une réflexion mes pas une demande précise et technique.
J’espère que cette explication permettra de construire un dialogue constructif.

par **jdh** » 22 Juil 2009 17:32

(Il n'y a pas d'âge pour faire des efforts d'orthographe : j'ai 46 ans !)

La page de Wikipedia expose déjà des avantages et des inconvénients du sujet SSO.

J'ai cité une phrase qui évoque l'environnement de cette mise en oeuvre : cela ne concerne en rien les utilisateurs. Pas besoin de les mettre dans la boucle. En clair c'est l'informatique qui met en oeuvre.

Le premier point de difficulté : cela ne fonctionne que sur des applis "adaptées pour".

A vous de continuer ..

par **bpp** » 23 Juil 2009 10:25

bein ci l-utilisateur n'est pas dans la boucle ? Pour autant c’est le premier concerné.
Je parl bien d’organisation SI pour mener à bien une politique de sécurité bien adaptée.
Donc à part parler IP, dns, token et co, dans un premier temps ne me parait pas intéressant, car je parle bien des limites organisationnelle qu’engendre l’architectura SSO, a moins que la technologie ne suivent pas, les pistes que je cherche sont biens structurelles et organisationnelles.

Merci d'avence dans ma quette

par **Muzo** » 23 Juil 2009 13:23

Bonjour,

Merci d'avance d'écrire correctement en français, sinon je verrouille le sujet.
Vous êtes sur un forum, par sur votre téléphone portable.

Cordialement,

/Muzo

par **jdh** » 23 Juil 2009 13:58

(Merci Muzo de ce rappel supplémentaire)

Pour commencer, il faudrait que vous lisiez le document de Wikipedia. Il explique déjà pas mal d'enjeux.

Je (re)note que cela ne fonctionne que pour des applications prévues pour.

par **bpp** » 24 Juil 2009 10:22

ok
bon pour l'orthographe j'ai de gros problèmes de dyslexies, et je n’ai pas de secrétaire à disposition. Ça ne me fait pas plaisir de ne pouvoir avoir une écriture fluide et correcte.
Pour wikipédia bof pas très poussé, et j’espérai engager une conversation et pas des renvoi à un document tous cuit.
Qu’elles sont vos expériences, vos opinions sur le sujet. Si vous ne trouver qu’a me critiquer je suis plus tos surpris.

par **jdh** » 24 Juil 2009 10:52

Je réécris puisque je ne suis pas vraiment compris.

- Wikipedia fournit une page de référence qui décrit les éléments caractéristiques des enjeux du SSO. (Elle est très loin d'être "bof", me semble-t-il, ou alors, si vous comprenez déjà tout ça, écrivez vous même plus ...)
- vous ne vous positionner pas sur une problématique précise, donc n'importe qui ne peut que vous répondre des généralités.

Pour avoir écouté une partie de session sur le sujet au RMLL 2009, je reporte ce que j'ai entendu et qui me semble juste : un, cela fonctionne pour des applications prévues pour, deux, ce sont des applications web (http), trois, cela concerne à peine les utilisateurs, quatre, si vous avez 40 applis à modifier pour, cela prend du temps.

Bref un beau sujet mais très "fil du rasoir". Je dis souvent "cela ne rapporte rien mais il faut le faire".

(Si ce fil reste aussi vague, je vais lâcher car je ne vois jusqu'ici qu'incompréhension, vaguitude, ... Moi je ne veux pas discuter dans le vide ...)

NB : l'évocation de l'authentification qui permet de se balader de service en service est une grande banalité (et est mentionné dans Wikipedia). Il est totalement évident qu'il ne suffit pas de s'authentifier, il faut gérer des autorisations applis par applis : et avec une authentification unique, le nom de l'utilisateur est unique ce qui simplifie déjà ce point.

par **bpp** » 24 Juil 2009 14:16

Hé bein voila la discussion à démarré, par contre je continue à dire que l’utilisateur et organisationnellement au cœur du processus. C’est ces prérogatives qui déterminent ses droits.
Je vais prendre un exemple plus concret.
Imaginons une situation simple ou le SSO est courant :
2 Entreprises on mit des ressources d’édition en commun (réduction de cout) : imprimante à gros tirage, serveur de sauvegarde en raid, accès internet. On imagine que la partie stockage n’est pas gérer comme l’accès internet, on peut admettre que cet accès vers l’extérieur est full open alors que le serveur différentie les sociétés et l’administrateur qui peut êtres commun.
Ci ces sociétés travail sur les mêmes projets, on peut imaginer que suivant les projets et les utilisateurs il faudra prévoir une plus grande complexité : partage de fichier sur le serveur, applications communes.
Et encor mieux ci ces sociétés sont : un laboratoire pharmaceutique, un hôpital publique et une faculté de médecine qui travail en recherche médical dans ce cas la, comment mètres en commun des ressources très sensibles, sans éventuellement craindre des fuites tout en préservant la fluidité nécessaire. Que je sache ces biens la politique très définie qui va déterminer le plan SSO.
Donc c’est bien organisationnel et là je voudrai lancer la discussion sur les limites généralement rencontré pour maitre en place ce genre de politiques.

Je précise, je n’ai ni étude ni de tel projet à maitre en place, je veux juste me poser les bonnes questions.

Cordialement

par **jdh** » 24 Juil 2009 14:32

Ah bon, le SSO serait courant pour partager une imprimante à gros tirage, un serveur de sauvegarde en raid, un accès internet (en "full open") ?

Sans rire, vous croyez vraiment qu'un laboratoire pharmaceutique, un hôpital publique et une faculté de médecine mettraient des ressources en commun via un SSO ?

Visiblement je ne comprends rien à ce que vous mettez derrière le mot SSO.

<mode découragé>De mon point de vue SSO c'est l'inverse de ce que vous pensez. La suite c'est sans moi.</mode>

par **ccnet** » 24 Juil 2009 16:16

bpp a écrit:Je précise, je n’ai ni étude ni de tel projet à maitre en place, je veux juste me poser les bonnes questions.
Cordialement

Vos questions relèvent de la pure fiction. La seule chose qui semble réelle est que vous n'avez rien compris au SSO. Et que l'utilisateur n'a aucune prérogative en la matière.
Il n'y a aucun rapport entre le partage de ressources informatiques entre plusieurs entreprises et l'utilisation du SSO.

par **Stirner** » 24 Juil 2009 16:46

Il n'y a aucun rapport entre le partage de ressources informatiques entre plusieurs entreprises et l'utilisation du SSO.

Pas entièrement d'accord; Je pense en particulier que c'était le but recherché par Microsoft avec son LiveID : fournir à différent prestataires une base d'authentification commune, simplifiant par la même la vie de l'internaute qui n'aurait eu qu'a retenir un seul mot de passe. Si sur le papier ce principe peu sembler intéressant il n'y a pas besoin s de sortir de la cuisse de Jupiter pour distinguer rapidement les limites du système. A la moindre bourde de paramétrage un utilisateur lambda peu ce retrouver avec un accès total à énormément de ressources et bonjour l'administration des droits et permissions derrière.

Un des arguments de base des pro SSO et que la multiplication des MDP conduit à une simplification de ces derniers et représente une faille de sécurité. Argument directement opposable : le piratage d'un seul mot de passe permet à un intrus d'accéder à l'ensemble des ressources autorisé pour l'utilisateur piraté.

Je reste partisan d'une politique de MDP forte imposé aux utilisateurs quitte à devoir assumer un support plus important pour la gestion des MDP.

@+

par **jdh** » 24 Juil 2009 17:02

On peut imaginer un SSO au sein de la même société.

Il est bien évident que l'on ne basera pas le SSO sur une référence externe (comme Microsoft, Yahoo, ...)
Il faudra adapter chaque appli (web) interne pour utiliser cette authentification.

On peut imaginer partager une application et ses données avec des intervenants extérieurs. (Cela s'appelle un extranet en général !).

Cette application utilisera une authentification interne à l'application mais sûrement pas une référence externe. C'est absolument indispensable car on peut supposer que l'individu utilisateur doit être parfaitement identifié.

On voit bien que les références externes ne peuvent intéresser que des "services librement publics". Cela revient à faire le choix de s'acoquiner avec la référence de son choix (et il n'existe pas de référence ... de référence : aucune interopérabilité à attendre).

Dans ce dernier cas, il n'y a aucune confiance à accorder à l'identité annoncée par celui qui s'enregistre. C'est dire l'importance des données !

Je me situe dans une vision entreprise et donc de viser un SSO interne. Je note que quelque soit le cas, l'utilisateur n'a pas son mot à dire ...

...

par **ccnet** » 24 Juil 2009 17:36

Stirner a écrit:
Il n'y a aucun rapport entre le partage de ressources informatiques entre plusieurs entreprises et l'utilisation du SSO.

Pas entièrement d'accord; Je pense en particulier que c'était le but recherché par Microsoft avec son LiveID : fournir à différent prestataires une base d'authentification commune, simplifiant par la même la vie de l'internaute qui n'aurait eu qu'a retenir un seul mot de passe. Si sur le papier ce principe peu sembler intéressant il n'y a pas besoin s de sortir de la cuisse de Jupiter pour distinguer rapidement les limites du système. A la moindre bourde de paramétrage un utilisateur lambda peu ce retrouver avec un accès total à énormément de ressources et bonjour l'administration des droits et permissions derrière.
Nous sommes d'accord sur l'essentiel, c'est à dire les limites pratiques de la chose. Ce qui me conduit à un avis "un peu" tranché.

Je reste partisan d'une politique de MDP forte imposé aux utilisateurs quitte à devoir assumer un support plus important pour la gestion des MDP.

@+

Oui je le pense aussi.

Architecture SSO avenages et inconvenants

Architecture SSO avenages et inconvenants

Qui est en ligne ?