Architecture SSO avenages et inconvenants

[bpp]

Mes quand on dit qu’il n’y aucun rapport avec le partage de ressources et les principes du SSO, je saute au plafond, car ça dépend de la définition des ressources. Je m’explique bien entendu avec les erreurs possibles d’interprétation que j’ai de ce qu’implique le SSO :
Dans le cadre de la mise en place d’une architecture impliquant le SSO c’est bien pour permettre l’authentification unique dans la cadre d’utilisation de multiples ressources informatiques, ces ressources appartienne à 3 grandes familles généralement : Base de donnée, Application et matériel, le tous partagé ou pas, par réseau.
Le SSO implique que les applicatifs doivent êtres conçu ou adapter au SSO, que je sache un pilote matériel est un applicatif et il se peut que l’on veuille en fonction des utilisateurs autoriser ou non l’utilisation de matériel, certain de ces matériels sont autonome, je m’explique ils contiennent pilote, applicatif et interface (IP) généralement, ils ne sont pas forcement reconnut par les postes informatiques comme périphérique mes come une entité informatique PC : plusieurs exemples : imprimante à gros tirage, stockage de masse, instruments de laboratoire x ou y.
Il ya les applicatifs, les Base de donnée et les 2 liées, les espaces de stockage partagé.
Au delà a part internet je ne vois pas ce que l’on pourrait partager. Tout ça pour dire que le SSO peut s’appliquer à tous ce qui est relié informatiquement.

Pour reprendre le besoin du SSO c’est bien l’authentification unique et généralement elle est mise en place quant le nombre d’utilisateur possible est important + de 30 ou 40 et voir beaucoup plus (voir la société qui produit nos avions de ligne), justement ils doivent permettre à des sociétés partenaires extérieurs de se connectaient à leur base de donnée (en partit) et à certaines de leurs imprimantes depuis les sociétés partenaires donc l’extérieur, toutes en gardant l’assurance de la non porosité.( l’authentification multiple est pas envisageable car elle serait très contraignante pour l’utilisateur). Pour autant ils sont confrontés à de multiple difficulté.
L’exemple du labo+ de la fac + d’un hôpital c’est justement une problématique bien réelle et toujours pas pleinement résolu, car justement les craintes sont là. Ce besoin existe car dans les pays fortement impliqués dans la recherche médical, des laboratoires font le souhait de pouvoir dans certains cas très précis et avec des protocoles qui implique notamment des notions de temporalité le partage des ressources communes avec les structures médicales et les laboratoires de recherches fac.

Ce que veux je dires par l’utilisateur est impliqué : C’est que c’est bien lui qui ce connecte et c’est bien contre des utilisateurs non souhaités qu’on ce prémunie et pas contre une quelconque entité fantomatique (Ghost in the Shell = science fiction) car à l’origine c’est bien un ou plusieurs utilisateurs. Pas d’utilisateur pas de SSO

Merci

[arapaho]

Identification - Authentification - Autorisation - Session.

Généralement, le SSO s'applique à la deuxième phase, la troisième étant toujours du ressort de chaque applicatif/actif/whatever, ou d'une tierce partie, etc ....
L'adaptation de l'application se limite à la façon dont elle gère ou confie l'authentification. Soit elle continue à gérer les autorisations localement, soit elle confie cette tâche à un tiers.
L'authentification peut également se faire en parallèle dans certains cas.

jdh résume bien le principe, je ne vois pas ce qui est incompréhensible. Un bémol tout de même à la mise en commun de plate-forme d'authentification inter-structures: c'est tout à fait possible, réalisable et réalisé. Kerberos le fait parfaitement bien, et de manière fine.

Je ne vois donc pas en quoi le SSO autorise quoi que ce soit. Ca reste un simple contrôle d'accès, pas une autorisation.

PS. un petit truc pour éviter de se faire tirer dessus: http://www.leconjugueur.com/

[jamiroq]

.... je vous lis rapide la.

niveau sécurité c'est l'effet domino le SSO.
tout comme les ldap, ad, od etc ...

LE vieux UNIXIEN obtu va batailler ferme pour ne pas vouloir de ldap ..... le jeunot l'ayant bidouiller à la fac va vouloir $%#&! du sso et touti quanti partout ....

j'ai bien aimé la phrase de jdh : "le sso est un problème pour le service informatique et pas pour les utilisateurs"


A vous de juger ....

[arapaho]

niveau sécurité c'est l'effet domino le SSO.
tout comme les ldap, ad, od etc ...

LE vieux UNIXIEN obtu va batailler ferme pour ne pas vouloir de ldap ..... le jeunot l'ayant bidouiller à la fac va vouloir $%#&! du sso et touti quanti partout ....

Je ne vois pas du tout ce que vient faire le LDAP dans cette phrase ...

[Franck78]

@stirner

Pas entièrement d'accord; Je pense en particulier que c'était le but recherché par Microsoft avec son LiveID

Et bien avant microsoft par novell toujours trop en avance:

http://support.novell.com/techcenter/ar ... 91201.html
Bon d'accord, ils avaient choisi un nom plutôt équivoque: "digitalme"

http://www.novell.com/connectionmagazin ... alk_4.html

Encore @stirner: il y a plus fort que le simple compte+mdp pour s'authentifier.