isnet 76 - serveur campus des écoles hes genevoises

Transcription

Informatique de gestion
HEG – Genève
Laboratoire de Technologies Objet
Campus de Battelle – Bâtiment F
Route de Drize 7
CH-1227 Genève
Tél : +41 22 388 17 00
Fax : +41 22 388 17 01
www.hesge.ch/heg
IDENTITÉ DIGITALE FÉDÉRÉE
RAPPORT DÉTAILLÉ
Projet déposé dans le cadre du programme de la réserve stratégique de la HES-SO
Novembre 2006
Sous la direction de Peter DAEHNE, professeur HES
http://campus.hesge.ch/Daehne/ISNet76
ISNET 76
TABLE DES MATIÈRES
1 Le problème.............................................................................................................. 5
1.1 Les enjeux pour l'entreprise ................................................................................ 5
1.2 La sécurité .......................................................................................................... 6
1.3 Les failles............................................................................................................ 7
1.4 Le Single Sign-On ............................................................................................... 8
1.5 Le cas d'Internet ............................................................................................... 11
1.5.1 Intranet ................................................................................................... 11
1.5.2 Extranet .................................................................................................. 14
1.5.3 Au-delà de l'entreprise ............................................................................ 15
2 Spécifications de Liberty Alliance ............................................................................. 16
2.1 Le concept d'identité ........................................................................................ 16
2.2 Les objectifs...................................................................................................... 17
2.3 Identité réseau fédérée ..................................................................................... 18
2.4 Cercle de confiance .......................................................................................... 18
2.5 L'architecture ................................................................................................... 21
2.5.1 Le module ID-FF ...................................................................................... 22
2.5.2 Autres modules ....................................................................................... 22
3 Conformité des implantations ................................................................................. 24
3.1 Liberty Interoperable™ ..................................................................................... 24
3.2 Tests de conformité .......................................................................................... 24
3.3 Produits inter opérables .................................................................................... 24
4 Mise en œuvre........................................................................................................ 26
4.1 Concepts.......................................................................................................... 26
4.1.1 Le fournisseur de service.......................................................................... 26
4.1.2 Le fournisseur d'identité .......................................................................... 27
4.1.3 Le client .................................................................................................. 27
4.2 Composants matériels et logiciels nécessaires.................................................... 28
4.2.1 Logiciel ................................................................................................... 28
4.2.2 Matériel .................................................................................................. 28
4.3 Implantation..................................................................................................... 29
4.3.1 La cible ................................................................................................... 30
4.3.2 Architecture du système .......................................................................... 31
4.3.3 Accès aux services ................................................................................... 31
2
ISNET 76
4.3.4 Authentification ...................................................................................... 32
4.3.5 Logiciel ................................................................................................... 32
4.3.6 Systèmes Microsoft Windows™............................................................... 33
4.3.7 Procédure ............................................................................................... 33
5 Modèle business ..................................................................................................... 35
5.1 Cadre ............................................................................................................... 35
5.2 Type d'échange ................................................................................................ 36
5.3 Innovation produit ............................................................................................ 36
5.4 Gestion de l'infrastructure ................................................................................ 37
5.5 Relation client................................................................................................... 38
5.6 Aspects financiers ............................................................................................. 39
6 Prototypes .............................................................................................................. 41
7 Conclusion.............................................................................................................. 42
8 Bibliographie........................................................................................................... 44
3
ISNET 76
TABLE DES FIGURES
Fig. 1.1 : Le dilemme entre accessibilité de l'information et exigences de sécurité.......... 6
Fig. 1.2 : Les multiples identifications d'un utilisateur.................................................... 7
Fig. 1.3 : Identification d'un utilisateur sur différents systèmes interconnectés............... 9
Fig. 1.4 : Single Sign-On d'un utilisateur sur un ensemble de systèmes interconnectés 10
Fig. 1.5 : Succession des opérations dans un contexte single sign-on / intranet............ 12
Fig. 2.1 : Les attributs définissant l'identité d'un utilisateur ......................................... 16
Fig. 2.2 : Première connexion d'un utilisateur dans un environnement fédéré.............. 19
Fig. 2.3 : Première connexion auprès d'un partenaire du même cercle de confiance .... 20
Fig. 2.4 : Architecture modulaire générale .................................................................. 21
Fig. 3.1 : Logo certifiant la conformité du produit aux spécifications ........................... 25
Fig. 4.1 : Les acteurs de la fédération d'identité .......................................................... 26
Fig. 4.2 : L'architecture du système informatique des entreprises considérées.............. 30
Fig. 4.3 : La nouvelle architecture du système ............................................................. 31
Fig. 4.4 : Étapes de la mise en conformité du système avec la fédération d'identités.... 34
Fig. 5.1 : Les piliers des modèles business ................................................................... 35
4
ISNET 76
1 LE PROBLÈME
Aujourd'hui, l'Internet est devenu le principal moyen de communication et
d'échange d'informations de notre société. Tout individu équipé d'un ordinateur et
d'une ligne de communication1 peut accéder aux nombreux services proposés par ce
média. Son ubiquité a naturellement séduit les entreprises et les administrations qui
se sont appuyées sur ce formidable moyen de communication pour développer
toutes sortes de services en ligne.
Certains de ces services sont destinés au grand public. Le tout premier d'entre eux
est bien sûr la messagerie2 ; mais l'usager peut également employer l'Internet pour
administrer son compte bancaire, gérer son portefeuille d'actions et ses
investissements, payer ses factures, opérer des transactions immobilières, effectuer
des achats de vêtements, de films, de musique, etc.
D'autres sont à usage interne de l'entreprise qui les utilise pour accomplir sa mission.
Parmi ceux-ci, on peut citer l'interconnexion des divers départements et succursales
dans un contexte d'architecture distribuée, le télétravail des employés, le contact
avec les collaborateurs mobiles ainsi que les relations commerciales avec les
fournisseurs et/ou les clients ou encore la gestion de la connaissance3.
Notons encore que l'Internet est un vecteur fondamental pour toutes les entreprises,
4
qu'elles soient des SSCI ou non, qui confient la réalisation de leurs développements
informatiques à des tiers5 ; ces derniers sont en effet souvent localisés à l'autre bout
du monde.
Remarquons enfin que, ces dernières années, la fonction de l'Internet a évolué de
l'interconnexion d'ordinateurs vers l'interconnexion d'applications et de services. Le
nombre de clients ainsi que le nombre de dispositifs et points d'accès à ces
applications et services ont également explosé.
1.1 Les enjeux pour l'entreprise
Parallèlement à l'essor de l'Internet et des systèmes de communication, les
plateformes logicielles et matérielles des entreprises se sont multipliées. Pour faire
face à la demande croissante de services en ligne, tant de la part des usagers que des
collaborateurs et partenaires de l'entreprise, de nouveaux systèmes ont dû être
développés.
Les entreprises se sont donc retrouvées confrontées au problème de la gestion
efficace de nombreux systèmes devant être déployés, maintenus et intégrés à un
nombre croissant de réseaux et de plateformes différents.
1
Cette ligne de communication peut être la ligne fixe du téléphone, une connexion via un réseau coaxial ou hertzien, un réseau
d'entreprise ou encore une connexion mobile.
2
Historiquement s'entend, mais ces services se sont également développés en direction de la messagerie instantanée ou encore
de la vidéoconférence.
3
Cette liste est bien sûr loin d'être exhaustive. Régulièrement de nouvelles applications de l'Internet ayant pour objectif
d'améliorer la productivité, la performance et la visibilité de l'entreprise voient le jour.
4
SSCI : Société de Services et de Conseils en Informatique.
5
Outsourcing.
5
ISNET 76
Simultanément à ce défi de gestion, elles ont dû affronter, de la part d'usagers et de
partenaires commerciaux de plus en plus dynamiques, des exigences toujours
croissantes en matière de quantité, qualité, actualité et disponibilité d'information.
Les départements informatiques furent soumis à une forte pression de la part de leur
management pour qu'ils augmentent et améliorent l'accès à l'information tant pour
6
7
les collaborateurs que pour les partenaires et clients de l'entreprise . Ces exigences
les ont conduits à réévaluer tant l'architecture du système d'information que la
sécurisation de l'accès à ce système. En effet, les parties en présence sont très
hétéroclites, jouissent de droits d'accès aux informations très variés et désirent par
ailleurs communiquer de manière dynamique et transparente.
Le dilemme8 qui se présente alors est le suivant : comment concilier à la fois une
diffusion à grande échelle de l'information avec les exigences de sécurité et de
confidentialité nécessaires à la préservation des secrets de l'entreprise et à la bonne
marche des affaires.
Accessibilité
Disponibilité
Utilisabilité
Expérience
Transparence
Contrôle
Consistance
Risque
Responsabilité
Coût
Fig. 1.1 : Le dilemme entre accessibilité de l'information et exigences de sécurité [Nor02].
L'enjeu majeur de cette situation pour l'entreprise est la maîtrise des coûts engendrés
par la mise en place d'une architecture ayant les caractéristiques requises pour
satisfaire à ces spécifications. La figure 1.1 illustre cette situation.
1.2 La sécurité
La sécurisation de l'accès aux informations vitales de l'entreprise, nous l'avons vu, est
une des composantes principales des défis que doit relever l'entreprise dont le
6
Intranet.
7
Extranet.
8
Désigné dans [Nor02] par le terme : the IT dilemma.
6
ISNET 76
système d'information s'appuie sur des réseaux ouverts au public, en particulier
Internet.
Pour les services accessibles à travers le réseau, la principale mesure de sécurité
généralement mise en place est l'authentification de l'identité de l'utilisateur. Nous
ne discuterons pas ici des autres mesures qui doivent impérativement être prises,
parmi lesquelles on peut citer non exhaustivement : la sécurisation physique de
l'accès aux locaux hébergeant le matériel lui-même, le cryptage des informations
confidentielles transmises ainsi que la mise en place de pare-feux protégeant le
réseau de l'entreprise contre les intrusions malveillantes et les virus.
Le fournisseur du service doit s'assurer qu'un client9 qui a recours à ce service est un
utilisateur autorisé et non pas un imposteur. C'est dans ce contexte qu'interviennent
les concepts de nom d'utilisateur et de mot de passe ; en fournissant au service un
couple nom d'utilisateur/mot de passe valide, le client fait état de son identité et
prouve ainsi qu'il dispose des autorisations et des droits d'accès requis pour
bénéficier des fonctionnalités offertes par le service.
1.3 Les failles
Dans le contexte actuel, un utilisateur standard d'un réseau d'entreprise peut
posséder des dizaines d'identifications (voir : figure 1.2 ci-dessous) qu'il utilise pour
accéder aux divers sites, portails, applications et services qu'il emploie, tant pour
gérer ses affaires privées que pour accomplir les tâches de son cahier des charges
d'employé d'une entreprise.
Fig. 1.2 : Les multiples identifications d'un utilisateur.
9
Le client en question peut être un soit utilisateur physique soit un utilisateur virtuel, à savoir une application qui requiert des
informations de façon automatique en invoquant le service.
7
ISNET 76
Pour chacune des applications avec lesquelles il interagit, il doit non seulement
définir un couple nom d'utilisateur/mot de passe, mais encore s'en souvenir. Il doit
de plus composer avec le fait que les règles imposées par les différents points d'accès
pour la définition de ces informations varient grandement. Ces variations peuvent
porter sur le nombre minimal de caractères nécessaires ou encore sur les
combinaisons de caractères alphabétiques et numériques ainsi que les changements
de casse imposées.
L'existence de ces différentes règles fait qu'il est dès lors pratiquement impossible,
pour des raisons de convenance et de facilité de mémorisation, de définir à chaque
fois le même couple nom d'utilisateur/mot de passe. La tentation est alors grande
pour l'utilisateur de noter ces informations d'identification, soit sous forme
manuscrite, soit sous forme électronique10, soit encore de les faire mémoriser par le
navigateur Internet de son poste de travail. Si de plus l'utilisateur est amené à
changer souvent de poste de travail, cette dernière solution aura pour effet de laisser
les traces de ces informations d'identification sur chacun des postes employés.
Ces comportements fautifs et inconsidérés des utilisateurs sont induits par la jungle
d'informations d'identification avec lesquels ils doivent composer tous les jours. Ils
créent ainsi des failles dans le système de sécurité, justement en raison du fait que la
plupart des applications auxquelles ils sont confrontés quotidiennement sont
sécurisées. Il devient dès lors clair que trop de sécurité tue la sécurité.
Si la multiplication des procédures d'identification que l'utilisateur doit subir tout au
long de la journée est éventuellement supportable pour un usager privé, elle est
contraire aux règles élémentaires de l'ergonomie, et, lorsque cet utilisateur est un
employé d'une entreprise, elle a tendance à le lasser et finit par le rendre nettement
moins productif.
1.4 Le Single Sign-On
Comme nous l'avons vu, l'interconnexion des systèmes dans les entreprises
complique singulièrement la tâche d'un utilisateur qui doit s'identifier auprès de
chaque application qu'il emploie pour effectuer sa tâche.
Lorsque l'application en cours d'utilisation en référence une autre dont elle requiert
un service ou des informations11, l'utilisateur doit également s'identifier auprès de
12
cette dernière . À chaque fois, il sera soumis à une procédure interactive
d'identification au cours de laquelle il va être amené à fournir des couples
nom d'utilisateur/mot de passe éventuellement différents.
L'administrateur du système devra quant à lui gérer des comptes ainsi que les droits
qui y sont associés pour chacune des applications employées dans l'accomplissement
de la mission de l'entreprise. Ces comptes devront être gérés de manière
coordonnée, de telle sorte que l'intégrité globale du système de sécurité soit
garantie. Le scénario que nous venons de décrire est illustré par la figure 1.3.
10
Ces informations peuvent aussi bien être mémorisées dans un simple fichier texte du poste de travail que sur un post-it
électronique déposé sur le bureau ou encore dans un PDA ou un téléphone portable.
11
Cette situation est illustrée sur la figure 1.3 où l'application du domaine 1 invoque un service de l'application du domaine 2.
12
Cette seconde identification peut être requise longtemps après le démarrage de la première application. Le système la
demandera au moment où l'application principale invoquera effectivement le service auprès de la seconde.
8
ISNET 76
Une telle architecture est en général la conséquence de l'histoire de l'entreprise13 et
de l'informatisation progressive de ses diverses missions. Les divers composants du
système global ont été peu a peu assemblés et leur intégration s'est effectuée par
14
juxtaposition des différentes applications existantes ou nouvellement développées .
Domaine 1
Identification
Domaine 1
Informations
des comptes du
domaine 1
Application
Domaine 1
Domaine k
Utilisateur
Administrateur
du système
Domaine 3
Identification
Domaine k
Identification
Domaine 3
Identification
Application
Domaine
2
Domaine k
Application
Domaine 3
Application
Domaine 2
Informations
des comptes du
domaine 2
Domaine 2
Fig. 1.3 : Identification d'un utilisateur sur différents systèmes interconnectés.
La croissance de tels systèmes hétéroclites, la dégradation de l'ergonomie générale
pour l'utilisateur et la baisse du niveau de sécurité engendrée par la multiplication
des procédures d'identification ont favorisé le développement de nouveaux services
dont l'objectif est de favoriser la coordination et l'intégration des fonctions
d'identification et d'administration des comptes à travers l'ensemble des domaines
de gestion de l'entreprise. Un tel service est susceptible de rentabiliser réellement les
coûts d'exploitation en :
diminuant le temps passé par les utilisateurs à s'identifier auprès des différents
domaines et en réduisant les possibilités que cette opération échoue ;
améliorant considérablement la sécurité du système par le fait qu'un utilisateur
ne doit plus se rappeler de nombreux couples nom d'utilisateur/mot de passe ;
réduisant le temps que les administrateurs du système doivent consacrer à la
création et à la suppression des différents comptes ainsi qu'à la gestion des
droits qui y sont associés ;
augmentant l'intégrité du système de sécurité par le fait que les
administrateurs gèrent les comptes utilisateurs de façon globale en leur
attribuant de manière consistante les droits d'accès à l'ensemble des
ressources qui leur sont nécessaires.
13
Existence d'unLegacy System, c'est-à-dire d'un assemblage hétérogène d'applications développées progressivement durant
l'existence de l'entreprise et héritées du passé.
14
Nous pouvons même nous trouver face à des applications fonctionnant sur des plateformes matérielles différentes, mues par
des systèmes d'exploitation différents.
9
ISNET 76
Ce service a été baptisé Single Sign-On en référence à la perception de l'impact
qu'en ont les utilisateurs finaux ; remarquons toutefois que l'aspect gestion des
comptes est tout aussi important que celui du confort de l'utilisateur. La figure 1.4
illustre le principe de fonctionnement de cette approche.
Identification
Domaine 1
Utilisateur
Informations
des comptes du
domaine 1
Application
Domaine 1
Domaine k
Domaine 3
Identification
Domaine k
Identification
Domaine 3
Identification
Application
Domaine
2
Domaine k
Application
Domaine 3
Application
Domaine 2
Informations
des comptes du
domaine 2
Système de gestion des comptes
Domaine 1
Administrateur
du système
Domaine 2
Fig. 1.4 : Single Sign-On d'un utilisateur sur un ensemble de systèmes interconnectés.
Dans ce contexte, l'utilisateur s'identifie une seule fois auprès du domaine sous le
contrôle duquel s'exécute l'application principale qu'il emploie. À cette occasion, il
peut être amené à fournir des informations supplémentaires qui prouveront qu'il
possède également les droits d'accès aux domaines secondaires auxquels son
application fera référence pour accomplir sa tâche. Ces informations sont transmises
au service de gestion du Single Sign-On qui se charge ensuite de l'authentification
automatique de l'utilisateur auprès de tous les domaines auprès desquels celui-ci
jouit de droits d'accès. Une relation de confiance a ainsi été établie entre le domaine
d'identification de l'utilisateur et ceux auxquels il accède par la suite.
Ce modèle simplifie grandement la tâche des administrateurs du système lors de la
gestion des comptes des utilisateurs. Ils ne sont en effet confrontés plus qu'à un seul
15
logiciel d'administration au moyen duquel les identifications pour l'ensemble des
domaines du système d'information de l'entreprise peuvent être gérées de façon
coordonnée et synchronisée.
D'un point de vue technique, les informations d'identification échangées entre le
domaine principal d'identification et les domaines secondaires en raison de la
relation de confiance devront être protégées d'une éventuelle interception,
particulièrement si ces informations transitent par des réseaux publics. Celles-ci
peuvent en effet être employés par des tiers malveillants pour s'introduire de façon
non autorisée dans le système d'information de l'entreprise.
15
Dans les versions les plus modernes de ce service, le logiciel d'administration des comptes utilisateurs s'appuie sur un service
d'annuaire qui, entre autres, répertorie et se charge de la gestion des informations concernant les utilisateurs.
10
ISNET 76
À partir du moment où un tel service est déployé pour gérer l'ensemble des
identifications nécessaires aux applications de l'entreprise, l'employé peut être muni
d'un unique badge qui lui permettra non seulement de s'identifier auprès du système
d'information au moyen d'un lecteur idoine, mais aussi de commander les portes
d'accès sécurisées aux locaux de l'entreprise. Le danger de la communication
éventuelle, volontaire ou non, d'un mot de passe à un tiers est alors complètement
écarté.
1.5 Le cas d'Internet
L'approche que nous venons de décrire est pertinente tant du point de vue logistique
qu'économique. Elle est relativement facile à mettre en place pour le système
d'information d'une entreprise16 ou pour celui d'un ensemble d'entreprises faisant
17
partie d'un même groupe .
Nous avons vu plus haut que l'Internet prenait une place de plus en plus importante
dans la connexion des systèmes d'entreprises, ceci tant pour l'interaction avec les
collaborateurs que pour celle avec les clients et/ou les fournisseurs. Les applications
du système d'information informatisé d'une entreprise moderne sont également
largement déployées en s'appuyant sur le réseau des réseaux. Le problème de
l'identification se pose alors de manière encore plus accrue. En effet, les utilisateurs
doivent non seulement s'identifier auprès des applications de l'entreprise, mais aussi
auprès de portails, de fournisseurs de services, etc.
1.5.1 Intranet
Dans le cas de l'intranet, la situation est relativement semblable à celle du système
d'information interne à l'entreprise. En effet, l'ensemble des applications et services
ainsi que le service de gestion des comptes sont, en principe, sous le contrôle total
de l'entreprise. Il est donc relativement aisé de définir une architecture du système
adaptée aux besoins de gestion de l'identification des utilisateurs de telle sorte que
ces derniers n'aient besoin de s'identifier qu'une seule fois pour avoir accès aux
18
diverses ressources de l'intranet .
Une architecture possible du système pourrait être conçue en s'appuyant sur le
modèle suivant :
La gestion des accès est contrôlée par un service spécialisé : le gestionnaire
d'accès. Celui-ci est déployé sur un serveur Web ou encore hébergé par le
serveur d'applications. Il est responsable de contrôler de façon centralisée
l'ensemble des accès des utilisateurs aux divers services mis à disposition par
l'intranet. Pour la vérification des autorisations d'accès, celui-ci s'appuie sur un
16
Remarquons toutefois que l'impact économique du cas particulier de l'adaptation d'applications anciennes dont le
mécanisme d'authentification est profondément enterré dans le code peut être non négligeable, voire prohibitif.
17
Ce n'est pas toujours le cas bien sûr. Nous pourrions citer comme exemple certains grands groupes du luxe français qui sont
constitués d'une telle myriade d'entreprises différentes qu'il est pratiquement impossible pour eux d'intégrer les systèmes
d'information spécifiques de chaque enseigne. La grande mobilité du secteur fait par ailleurs que cette intégration n'est pas
toujours un objectif stratégique, bien au contraire.
18
L'adaptation d'une architecture de gestion des droits ad hoc héritée du passé et conçue sans dessein global peut toutefois se
révéler difficile.
11
ISNET 76
système de gestion des comptes semblable à celui que nous avons décrit plus
haut19.
Les différents domaines et applications représentés dans les figures 1.3 et 1.4
sont également déployés sur des serveurs Web. À chaque domaine est associé
un contrôleur d'accès fonctionnant en collaboration avec le gestionnaire
d'accès. Le contrôleur d'accès est responsable de la reconnaissance d'un
utilisateur déjà identifié ainsi que de la vérification des droits d'accès de cet
utilisateur au domaine et/ou à l'application.
Lorsqu'un utilisateur est reconnu par le système, le gestionnaire d'accès lui
ouvre une session20 et ses informations d'identification ainsi que la description
de ses droits d'accès sont représentés par un jeton qui est en général implanté
au moyen d'un cookie.
Il n'est pas nécessaire que les serveurs Web mentionnés soient tous différents
ni qu'ils résident sur des machines différentes. L'architecture décrite peut très
bien résider sur une seule machine physique sous le contrôle d'un seul serveur
Web.
La figure 1.5 illustre la succession des opérations engendrées par une session de
travail d'un utilisateur s'identifiant dans un contexte de single sign-on au sein d'une
telle architecture.
Contrôleur d'accès
Utilisateur
Application 1
Contrôleur d'accès
Gestionnaire d'accès
Application 2
1. Demande d'accès
2. Jeton présent?
3. Redirection page login
4. Authentification et création du jeton
5. Redirection vers la page originale avec jeton
6. Répétition demande 1.
7. Jeton présent?
8. Autorise ou refuse l'accès
9. Autre demande d'accès
10. Jeton présent?
11. Autorise ou refuse l'accès
Fig. 1.5 : Succession des opérations dans un contexte single sign-on / intranet [PaB04]21.
19
Voir chapitre 1.4.
20
La session a en général une durée limitée.
21
Cette architecture est celle qui est mise en place par Java Sun Access Manager qui est le module du serveur d'applications de
Sun Microsystems responsable de la gestion des authentifications d'utilisateurs. Il ne s'agit toutefois pas d'une solution
originale ; la plupart des solutions de single sign-on déployées dans le cadre de solutions intranet et/ou internet fonctionnent en
se basant sur une architecture semblable.
12
ISNET 76
Description du processus de la figure 1.5
1. L'utilisateur demande l'accès à une application de l'intranet auprès de
laquelle il faut s'identifier et pour laquelle il faut disposer de droits d'accès.
2. Le contrôleur d'accès installé sur le serveur Web hébergeant l'application
intercepte la requête de l'utilisateur et vérifie si celui-ci dispose d'un jeton
d'identification valide muni des droits d'accès adéquats.
3. En cas d'absence du jeton, le contrôleur d'accès redirige le navigateur Web
de l'utilisateur vers une page de login à laquelle l'url de la requête originale
est passée comme paramètre.
4. L'utilisateur s'identifie auprès du gestionnaire d'accès22. Celui-ci crée alors
une session pendant la durée de laquelle l'utilisateur est identifié avec tous
ses droits ainsi qu'un jeton mémorisant ces informations.
5. Le gestionnaire d'accès envoie le cookie contenant le jeton au navigateur de
l'utilisateur et redirige ce dernier vers l'url mémorisée et reçue lors des
opérations 3. et 4.
6. Suite à cette redirection, la requête d'accès initiale à l'application est à
nouveau effectuée.
7. Comme lors de l'opération 2., le contrôleur d'accès installé sur le serveur
Web hébergeant l'application intercepte la requête et vérifie que l'utilisateur
possède un jeton valide.
8. Si le jeton de l'utilisateur est muni des droits nécessaires pour accéder à
l'application, la page demandée est retournée à son navigateur, dans le cas
contraire, l'accès lui est refusé.
9. L'utilisateur peut ensuite effectuer des requêtes d'accès à d'autres
applications sous le contrôle du gestionnaire d'accès.
10. L'utilisateur est ici muni d'un jeton valide (obtenu lors de l'opération 4.), il
n'aura donc pas besoin de s'identifier à nouveau.
11. L'accès à l'application est autorisé ou refusé par le contrôleur d'accès en
fonction des droits dont dispose l'utilisateur.
Le processus peut se répéter tant que l'utilisateur est muni d'un jeton valide ; toutes
ses requêtes seront en effet accompagnées du jeton que le gestionnaire d'accès lui a
fourni lors de l'opération 4. Les différents contrôleurs d'accès associés aux
applications accessibles depuis l'intranet autoriseront ou refuseront l'accès en
fonction des droits associés au jeton, sans que l'utilisateur ait besoin de s'identifier à
nouveau.
Le processus se termine lorsque la session expire ou lorsque l'utilisateur effectue
explicitement une procédure de déconnexion.
La circulation du cookie contenant le jeton au travers du réseau est le point critique
du point de vue de la sécurité d'une telle architecture. On peut aisément se protéger
contre un vol du jeton en l'encryptant. Le gestionnaire d'accès peut également
émettre des jetons à usage unique pour chaque ressource dont il gère l'accès.
22
Cette identification peut s'effectuer en fournissant un couple (nom d'utilisateur, mot de passe) valide ou, comme nous l'avons
vu plus haut dans le chapitre 1.4, au moyen d'un badge, d'une smartcard, d'un certificat émis par le navigateur Web ou encore
par des moyens d'identification biométriques.
13
ISNET 76
1.5.2 Extranet
La résolution du problème du single sign-on dans le cas de l'extranet est plus
problématique. Dans ce contexte, les applications auxquelles un utilisateur est
susceptible d'avoir accès pour effectuer sa mission sont en général détenues par des
entreprises différentes.
En effet, le gestionnaire d'un garage peut par exemple avoir accès aux applications
de sa banque pour effectuer et vérifier ses paiements, aux applications de son
entreprise pour émettre et gérer ses factures, à celles de plusieurs fournisseurs de
pièces détachées pour commander les pièces nécessaires à l'entretien des véhicules
dont il représente la marque, à celles des entreprises dont il assure l'entretien de la
flotte, etc.
Techniquement, le problème peut se résoudre en mettant en place une architecture
pratiquement identique à celle que nous avons décrite dans le chapitre 1.5.1
ci-dessus23. Le problème principal réside dans le fait que le gestionnaire d'accès est
l'élément central de cette architecture. Ce dernier doit en effet avoir la connaissance
des informations d'identité des différents utilisateurs employant les applications
contrôlées par les contrôleurs d'accès qui lui sont associés.
Or, les utilisateurs sont répartis dans les différentes entreprises qui mettent à
disposition les applications que nous avons mentionnées dans notre exemple. Ces
entreprises considèrent en général que les informations concernant leurs employés
sont vitales pour leur fonctionnement et, par conséquent, voient leur diffusion à des
tiers d'un assez mauvais œil. De même, elles répugnent assez naturellement à
renoncer au contrôle de la gestion de l'accès à leurs applications ou à déléguer
celui-ci.
Pour mettre en place une telle architecture, il sera nécessaire que les entreprises
partenaires concluent des accords bilatéraux, voire multilatéraux qui spécifieront
explicitement les conditions de mise à disposition des informations concernant les
utilisateurs, la répartition des responsabilités dans les gestion de ces informations
d'identité, les procédures de définition des droits d'accès, etc. S'il est certainement
possible d'envisager une telle solution lorsqu'on se trouve en présence de deux ou
trois entreprises différentes, il devient franchement impossible de le faire lorsque le
nombre de protagonistes augmente. La cause principale de l'impasse sera presque
toujours le problème de la mise à disposition d'informations cruciales pour le métier
de l'entreprise dans le cadre d'une association dont les participants sont souvent
également concurrents.
Remarquons tout de même que si les entreprises appelées à collaborer dans une
architecture de ce type font partie d'un même groupe, les principales objections
relevées ci-dessus ne sont plus pertinentes24.
23
Notons tout de même qu'un système plus sophistiqué que les cookies devra être mis en place pour la transmission et
l'échange des jetons contenant les informations d'identification et les différents droits d'accès. En effet, l'usage d'un cookie est,
de par la définition même du concept de cookie, limité à un seul nom de domaine Internet (DNS).
24
Certains groupes se prêtent bien sûr mieux que d'autres à de telles collaborations entre les différentes entreprises qui les
composent. Toutefois, lorsqu'on est en présence d'un secteur d'activité à forte mobilité, comme par exemple le luxe (LVMH,
Richemond, Prada, PPR, …), il est fort possible que cette collaboration aille à l'encontre de la stratégie générale du groupe,
principalement en raison des liens de dépendance qui sont alors, de facto, créés.
14
ISNET 76
1.5.3 Au-delà de l'entreprise
Nous venons de montrer comment la multiplication des partenaires rendait
problématique la mise en commun d'informations en vue de gérer l'accès aux
différents sites concernés via une procédure de single sign-on. Les systèmes, les
réseaux physiques par lesquels transitent les informations et même parfois les postes
de travail sont différents ; le contrôle de tous ces éléments est réparti entre les
différents acteurs concernés.
De plus, la centralisation de la gestion de l'identification des utilisateurs d'une
application et/ou d'un système en augmente considérablement la vulnérabilité et la
sensibilité aux attaques extérieures. En effet, une telle architecture possède un
unique composant critique du point de vue de la sécurité : la base de données
mémorisant les informations d'authentification des utilisateurs25. Un viol de cette
base de données peut être exploité par des pirates pour effectuer des opérations non
autorisées sur l'ensemble des sites et applications contrôlés par le processus
d'identification26.
Toutes ces raisons mettent en évidence l'importance qu'il y a de concevoir un
nouveau modèle, s'affranchissant des contraintes imposées par une gestion
centralisée du processus d'identification.
25
Cette base de données contient non seulement les informations privées se rapportant aux différents utilisateurs du système,
mais également le ou les mots de passe qui leur sont associés ainsi que la description des droits d'accès aux différents sites et
applications du système dont ceux-ci disposent.
26
Single sign-on = single point of failure.
15
ISNET 76
2 SPÉCIFICATIONS DE LIBERTY ALLIANCE
La Liberty Alliance est un consortium qui a été créé en décembre 2001 par un
groupe d'environ 30 entreprises. Leur objectif commun était de définir un ensemble
de bonne pratiques et de standards ouverts permettant une gestion fédérée de
l'identité et prenant en compte les besoins actuels et futurs des individus et des
entreprises dans un environnement où les applications et les services sont déployés
sur l'Internet27. Cet objectif a été atteint dès 2002, date de la publication des
premières spécifications définissant les fondations de la gestion de l'identité dans un
environnement hétérogène et distribué.
Depuis lors, de nombreuses entreprises, actives dans des domaines aussi divers que
les technologies de l'information, la finance, les télécommunications, les médias,
l'industrie ou encore les organisations gouvernementales, ont rejoint le consortium.
Celui-ci comprend actuellement plus de 150 entreprises.
2.1 Le concept d'identité
L'identité d'un individu n'est pas seulement définie par les nom, prénom et date de
naissance qu'il acquiert à sa venue au monde. Elle évolue au fur et à mesure de
l'interaction de l'individu avec la société qui l'entoure et les organisations
(administrations, entreprises, etc.) auxquelles il a recours. À ces contacts, elle
s'enrichit d'informations nouvelles, pertinentes pour ces interlocuteurs.
Utilisateur
Préférences
Nom: Jean DUPOND
e-mail: [email protected]
Identification
Passeport: 123456
Permis: A, B, F4
Fonction: directeur des RH
Musique: Jazz, Disco
Train: Silence, marche
Fumeur: oui
Langues: français, anglais
...
Fig. 2.1 : Les attributs définissant l'identité d'un utilisateur.
On distingue principalement les caractéristiques d'identification pures de celles qui
définissent des attributs plus informels tels que les goûts ou les préférences d'un
individu [LaA03]. Les caractéristiques d'identification sont définies par des
organismes gouvernementaux28, des entreprises29 et par la biométrie30 de l'individu
27
"The Liberty Vision : To enable a networked world in which individuals and businesses can more easily conduct transactions
while protecting the privacy and security of vital identity information" [LaB03].
28
Parmi celles-ci, on peut noter principalement le numéro de passeport, les différents permis de conduire détenus, le numéro
AVS ou encore le numéro de contribuable.
16
ISNET 76
lui-même. Les préférences sont en général inhérentes à l'individu31, à son
comportement ou encore à son environnement32.
Un désignera par identité (d'un individu) l'ensemble des caractéristiques énoncées
ci-dessus33. Aucune entité, qu'elle soit réelle ou virtuelle, qui est en relation avec
l'individu n'en mémorise toutes les informations constitutives de l'identité. C'est la
nature de la relation que l'individu entretient avec l'entité qui détermine quelles sont
les informations pertinentes susceptibles d'être échangées entre les deux parties en
présence.
Les informations échangées devraient être réduites à un strict sous-ensemble
nécessaire et suffisant pour que la relation entre l'individu et l'entité puisse se
dérouler à la satisfaction des deux parties. Les raisons principales de cette restriction
sont la protection de la sphère privée et des considérations de sécurité.
2.2 Les objectifs
Les objectifs principaux poursuivis par les spécifications éditées par la Liberty Alliance
sont [Was05] :
de permettre aux utilisateurs d'un réseau d'employer une identité digitale en
assurant la protection de leur sphère privée ainsi que la sécurité de leurs
transactions ;
de permettre aux entreprises de gérer et d'administrer les relations qu'elles
entretiennent avec leurs clients sans intervention de tiers ;
de définir un standard ouvert de single sign-on qui permet aussi bien une
authentification décentralisée que l'obtention d'autorisations d'accès auprès
de plusieurs fournisseurs différents ;
de créer une infrastructure de gestion de l'identité en réseau qui prenne en
compte tous les dispositifs d'accès au réseau, actuels et émergents34.
Dans le monde de l'Internet, la protection de la sphère privée et le contrôle de
l'identité sont d'une importance capitale. D'un coté, les entreprises désirent avant
tout assurer la sécurité des transactions effectuées, de l'autre coté, les utilisateurs ont
des exigences ergonomiques telles que la simplicité d'emploi et l'accès rapide aux
informations. Il s'agit donc de définir un modus vivendi qui satisfait à la fois les
exigences des entreprises et celles des utilisateurs.
29
Les informations associées par les entreprises aux individus comprennent notamment le statut de l'employé au sein de
l'entreprise, sa fonction ou encore le nom d'utilisateur qui lui est attribué pour accéder au système d'information de
l'entreprise.
30
Les informations biométriques usuellement répertoriées sont les empreintes digitales et/ou rétiniennes ainsi que l'ADN de
l'individu.
31
Parmi celles-ci, on peut trouver les préférences musicales, celles relatives à la position préférée de l'individu dans un train (sens
de la marche ou non, fumeur ou non fumeur, wagon silence, etc.), l'historique de ses achats auprès d'une entreprise de vente
en ligne, son dossier médical, etc.
32
Numéros de téléphone, adresse, langues comprises et parlées, type de terminal mobile employé, etc.
33
Voir aussi figure 2.1.
34
En particulier, cette gestion ne devrait pas nécessiter des modifications du logiciel d'accès à Internet employé (et devrait donc
être compatible avec les browsers du marché).
17
ISNET 76
La réponse de Liberty Alliance à ces problèmes est la définition du concept
d'identité réseau fédérée35. Ce concept permet principalement de définir une
association entre les différentes identités qu'un utilisateur peut posséder au sein d'un
réseau.
2.3 Identité réseau fédérée
Le concept d'identité fédérée procure aux utilisateurs un processus d'identification
simplifié pour employer les ressources pour lesquelles ils bénéficient de droits
d'accès. Un stockage centralisé des informations personnelles d'identité n'est plus
nécessaire ; la vulnérabilité des systèmes aux attaques malicieuses s'en trouve ainsi
diminuée.
Un utilisateur s'identifie une seule fois et peut contrôler les attributs de son identité36
qui sont mémorisés par les différents fournisseurs de services. Ceux-ci ne stockent
donc que les informations qui sont strictement nécessaires à la fourniture du service
demandé. L'utilisateur bénéfice ainsi d'un confort d'utilisation des systèmes accru
ainsi que d'un contrôle fin des informations qu'il divulgue.
Les fournisseurs de services peuvent aisément personnaliser l'interaction qu'ils
entretiennent avec l'utilisateur en fonction des informations d'identité recueillies.
Quant aux entreprises, elles peuvent mener des transactions commerciales avec des
clients, des partenaires et des employés formellement authentifiés. Ils ont ainsi la
garantie que leurs interlocuteurs sont bien ceux qu'ils prétendent être.
2.4 Cercle de confiance
Le concept de cercle de confiance37 définit un ensemble de fournisseurs de services
qui partagent des identités réseau et qui sont liés par un contrat spécifiant les
conditions sous lesquelles ces identités sont partagées. Les règles principales
régissant ce partage sont [LaA03] :
il existe un contrat clair entre les fournisseurs de services comme mentionné
ci-dessus ;
les utilisateurs sont avertis quelles sont les informations les concernant qui sont
mémorisées par le système et doivent donner un accord formel autorisant leur
stockage ;
la notification à l'utilisateur et son accord sont mémorisés par le système en
vue d'audit.
Un utilisateur qui s'identifie auprès d'un fournisseur de services faisant partie d'un
cercle de confiance sera automatiquement reconnu par les autres membres ayant
adhéré au cercle. De plus, seules les informations strictement nécessaires à la gestion
des droits de l'utilisateur seront mémorisées localement auprès des autres membres
du cercle de confiance.
35
Federated network identity.
36
Voir chapitre 2.1.
37
Il est à noter que ce concept n'a rien de nouveau. En effet, c'est exactement le type d'accord qui liait à l'origine les différents
partenaires de la Lloyd's de Londres.
18
ISNET 76
Une session d'un utilisateur à partir du poste de travail de son entreprise peut alors
donner lieu à différents cas d'utilisation. La figure 2.2 illustre le processus qui se
déroule lors de la première connexion d'un utilisateur dans un environnement
fédéré.
Fig. 2.2 : Première connexion d'un utilisateur dans un environnement fédéré.
Première connexion d'un utilisateur (figure 2.2) :
0. Un contrat régissant les conditions du partage d'identité des utilisateurs est
conclu entre l'entreprise est ses divers partenaires.
1. Un utilisateur se connecte via son browser Internet depuis un poste de travail
de l'entreprise, usuellement en fournissant au système un nom d'utilisateur
et un mot de passe.
2. Le serveur d'authentification vérifie les informations de connexion fournies
par l'utilisateur. S'il est reconnu, il est considéré comme authentifié par le
système.
3. L'entreprise faisant partie d'un cercle de confiance, le serveur d'identité
permet à l'utilisateur de choisir s'il désire recevoir des propositions de
fédération de la part des partenaires lorsqu'il s'identifiera auprès d'eux.
4. Si l'utilisateur accepte de recevoir ces propositions, le fait est signalé aux
autres membres du cercle de confiance.
5. L'utilisateur étant authentifié, il peut travailler normalement en ayant recours
aux services du système de son entreprise.
Les étapes 3. et 4. ci-dessus n'ont lieu que lors de la première connexion d'un
utilisateur et ne se dérouleront plus lors de ses connexions ultérieures.
Une fois que l'utilisateur est authentifié par le système de l'entreprise, il peut être
amené au cours de son travail à s'identifier auprès de l'un ou l'autre des partenaires
19
ISNET 76
faisant partie du même cercle de confiance38. Ce cas d'utilisation est illustré par la
figure 2.3.
Fig. 2.3 : Première connexion auprès d'un partenaire du même cercle de confiance.
Première connexion auprès d'un partenaire du même cercle de confiance (fig 2.3) :
0. L'utilisateur a été authentifié par le système de l'entreprise.
1. L'utilisateur se rend sur le site d'un partenaire, soit explicitement, soit en
suivant un hyperlien.
2. Le partenaire gère lui-même un ensemble d'utilisateurs ayant divers droits
d'accès à son système. Il demande à l'utilisateur de fournir la paire nom / mot
de passe par laquelle il le reconnaît39.
3. Le partenaire vérifie les informations de connexion et authentifie l'utilisateur.
4. Comme cet utilisateur a autorisé les partenaires à lui proposer la fédération
de ses identités, cette proposition est émise par le partenaire. Sa réponse est
enregistrée.
5. L'utilisateur est authentifié normalement et peut recourir aux services offerts
par le système du partenaire (il reste bien sûr authentifié également auprès
du système de l'entreprise). Ces services peuvent être personnalisés en
fonction du profil enregistré auprès du partenaire.
L'utilisateur est maintenant reconnu réciproquement par les systèmes de l'entreprise
et du partenaire. Lors d'une session ultérieure, lorsque l'utilisateur (après s'être
identifié auprès du système de son entreprise) essayera de se connecter au système
38
En se rendant explicitement sur le site du partenaire ou en suivant un hyperlien d'une page Internet.
39
En général, cette paire est différente de celle que l'utilisateur a fourni au système de son entreprise.
20
ISNET 76
du partenaire, celui-ci le reconnaîtra sans autre forme de procès et les étapes 2., 3. et
4. décrites ci-dessus ne seront plus effectuées. L'utilisateur a également la possibilité,
à tout moment, de renoncer à la fédération.
Les systèmes concernés se notifient réciproquement les déconnexions locales de
l'utilisateur et ce dernier a la possibilité d'effectuer une déconnexion globale de tous
40
les systèmes auprès desquels il est identifié .
La sécurité est assurée par le fait qu'à aucun moment, les systèmes de l'entreprise et
du partenaire n'échangent effectivement des informations d'identité41 de l'utilisateur.
Celui-ci est représenté dans la fédération par un pseudonyme qui l'identifie. La
protection de la sphère privée de l'utilisateur est assurée par le fait que chacun des
partenaires ne mémorise que les informations qui concernent strictement
l'interaction de l'utilisateur avec leur système.
2.5 L'architecture
Dès le départ du projet, Liberty Alliance a défini une architecture modulaire générale
des différentes spécifications envisagées dans le but de fixer les grandes lignes
directrices du projet d'une part, dans celui de fournir un cadre cohérent et global
dans lequel les futures versions pourrons s'inscrire. Cette architecture est illustrée par
la figure 2.4.
LIBERTY IDENTITY
FEDERATION
FRAMEWORK
(ID-FF)
LIBERTY IDENTITY SERVICES
INTERFACE SPECIFICATIONS
(ID-SIS)
Instanciation de l'implémentation
technique définie par ID-WSF
Gestion de la fédération
d'identités
LIBERTY IDENTITY WEB
SERVICES FRAMEWORK
(ID-WSF)
Interopérabilité des services à
utilisateur authentifié
STANDARDS EXISTANTS (SAML, SOAP, HTTP, WSS, etc.)
Fig. 2.4 : Architecture modulaire générale [LaA03].
L'ensemble des spécifications s'appuie sur des standards existants ; l'idée étant
d'adopter et d'étendre des standards largement présents sur le marché plutôt que
d'en définir de nouveaux, propriétaires et incompatibles avec l'existant. Le projet
40
Global Logout.
41
Au sens défini dans le chapitre 2.1.
21
ISNET 76
s'appuie donc sur les résultats des travaux de spécification de standards menés par
OASIS42, W3C43 et IETF44.
Le module ID-FF est chargé de la gestion de la fédération d'identités comme décrit
plus haut45. Il peut être déployé sans la présence des autres modules et peut
fonctionner en collaboration avec des systèmes d'authentification existants.
Le module ID-WSF définit un framework permettant de créer, de découvrir et de
consommer des Web services communiquant avec des utilisateurs (ou des services)
authentifiés. Il s'agit de la spécification d'une couche de base ayant recours à l'ID-FF
pour gérer l'authentification et sur laquelle s'appuie ID-SIS.
Le module ID-SIS est un ensemble de spécifications qui définissent comment
construire des services inter opérables se basant sur ID-WSF. La mise à disposition de
services tels qu'un agenda partagé, la géo location ou encore des systèmes d'alertes
est envisageable.
2.5.1 Le module ID-FF
Dans la présente étude, nous nous intéressons principalement aux fonctionnalités
offertes par le module ID-FF. Il s'agit principalement de46 :
Opt-in Account Linking : le mécanisme de fédération.
Simplified Sign-On : identification unique d'un utilisateur faisant partie d'un
cercle de confiance et entre cercles de confiance.
Fundamental Session Management : définition et communication du type
d'authentification d'un utilisateur entre les systèmes d'un cercle de confiance ;
déconnexion globale47.
Affiliations : proposition aux utilisateurs de recevoir les offres de fédération au
cours de la navigation entre systèmes d'un cercle de confiance.
Anonymity : possibilité pour un système d'obtenir des attributs concernant un
utilisateur sans connaître son identité48.
Toutes ces fonctions sont nécessaires pour mettre en œuvre l'ensemble des
mécanismes décrits au chapitre 2.4.
2.5.2 Autres modules
Les modules ID-WSF et ID-SIS définissent des fonctionnalités qui permettront de
développer les capacités de la fédération d'identité, en particulier en y incluant les
42
OASIS : Organization for the Advancement of Structured Information Standards (http://www.oasis-open.org).
43
W3C : World Wide Web Consortium (http://www.w3.org).
44
IETF : Internet Engineering Task Force (http://www.ietf.org).
45
Voir chapitres 2.3 et 2.4.
46
Les termes anglais sont employés dans la liste pour assurer l'univocité de désignation.
47
Global logout.
48
Par exemple, au moment de la connexion d'un utilisateur à un système, celui-ci peut demander au système auprès duquel cet
utilisateur est authentifié si cet utilisateur a accepté de recevoir les offres de fédération.
22
ISNET 76
Web services. Ils n'ont pas besoin d'être déployés pour gérer la fédération d'identités
elle-même. Nous ne les décrirons donc pas ici.
23
ISNET 76
3 CONFORMITÉ DES IMPLANTATIONS
La multiplication des produits offerts sur le marché par de nombreux fournisseurs de
logiciels49 pose la question cruciale de la conformité aux spécifications des
implantations proposées.
3.1 Liberty Interoperable™
Pour résoudre ce problème, les membres du consortium Liberty Alliance ont défini
dès 2003 un programme de certification : Liberty Interoperable™. L'objectif de ce
programme est de mettre à la disposition des fournisseurs de solutions un
environnement dans le cadre duquel la conformité de leur produit aux spécifications
peut être validée.
Les membres des sociétés candidates à la certification doivent passer différents tests
basés sur des scripts et des scénarios publiés sur le site Internet de Liberty Alliance50
et élaborés par un groupe d'experts désignés par le consortium. Ces tests sont
organisés en events regroupant différents constructeurs et sont organisés plusieurs
fois par année.
3.2 Tests de conformité
Les tests de conformité sont organisés par Liberty Alliance et durent en général une
semaine au cours de laquelle les sociétés candidates à la certification doivent
démontrer leur conformité aux spécifications d'une part, l'inter opérabilité de leur
produit d'autre part. Le programme de tests stipule également que les
fonctionnalités de base doivent être accomplies dans divers contextes ressemblant à
de véritables déploiements du produit.
La démonstration de l'inter opérabilité doit être effectuée avec deux autres produits
d'entreprises concurrentes participant au programme de certification. Ces
concurrents sont choisis au hasard. La réussite du test est certifiée de façon croisée
par les paires d'entreprises qui signent un protocole standard attestant du succès ; le
protocole est également validé par le groupe d'experts de Liberty Alliance et
complété par un journal des messages échangés qui constitue la trace du test.
La confidentialité nécessaire à la conduite des affaires est garantie par le fait
qu'aucun observateur autre que les membres de l'équipe de test de l'entreprise
candidate et ceux de l'organisation n'est admis à ces séances.
3.3 Produits inter opérables
Les produits qui ont passé avec succès les tests de conformité peuvent afficher le
logo de la figure 3.1. Une liste des produits ayant obtenu cette certification est
49
Le nombre de fournisseurs de logiciels qui proposent des solutions de fédération d'identité augmente sans cesse ; il approche
bientôt de la centaine.
50
Voir http://www.projectliberty.org/liberty/liberty_interoperable/documents.
24
ISNET 76
disponible sur le site de Liberty Alliance51. À ce jour, tous tests confondus, plus de
soixante-dix produits ont obtenu cette certification.
Fig. 3.1 : Logo certifiant la conformité du produit aux spécifications.
Les clients qui font l'acquisition d'un produit muni de ce logo ont l'assurance que
celui-ci :
est conforme aux spécifications de Liberty Alliance ;
sera maintenu conformément aux standards industriels de qualité ;
est effectivement la version qui a passé les tests de certification.
Si un problème à propos de la qualité ou de la conformité du produit survient dans
les deux ans qui suivent l'obtention du logo, Liberty Alliance se réserve le droit
d'exiger de la société éditrice de remédier au problème dans un délai de soixante
jours, sous peine de retrait de la certification.
Ce programme permet ainsi à un client de choisir un produit en toute connaissance
de cause et d'envisager une stratégie à moyen terme pour son déploiement au sein
de l'entreprise. Il a ainsi la garantie que le choix qu'il a effectué ne sera pas
rapidement obsolète et est assuré que la solution qu'il envisage, ce qui est
fondamental, sera relativement pérenne.
51
Voir http://www.projectliberty.org/liberty/liberty_interoperable/interoperable_products.
25
ISNET 76
4 MISE EN ŒUVRE
Nous examinerons tout d'abord, en toute généralité, les principaux concepts qui sont
mis en jeu lors de la mise en œuvre d'une fédération d'identité, puis nous
recenserons les composants matériels et logiciels nécessaires, enfin, nous définirons
comment, dans le cas particulier d'une petite ou moyenne entreprise52, ces concepts
et ces composants doivent être implantés.
4.1 Concepts
Pour la mise en œuvre de la fédération d'identité, on distingue trois acteurs
principaux : le fournisseur de service, le fournisseur d'identité et le client.
Fournisseur
d'identité
Échange
d'informations
Fournisseur de
service
Client
Redirection
Fig. 4.1 : Les acteurs de la fédération d'identité.
4.1.1 Le fournisseur de service
Le fournisseur de service53 est l'organisation, l'entreprise qui fournit un certain
nombre de services en ligne aux utilisateurs ; l'accès à tout ou partie de ces services
n'est donné qu'à des utilisateurs authentifiés. Le fournisseur de service procède à
cette authentification, soit via son propre service d'authentification s'il est
responsable de la gestion de l'identification principale de l'utilisateur, soit via un
fournisseur d'identité dans le cas contraire.
Dans le cadre d'une fédération, les identités ne sont pas centralisées, chaque
fournisseur de service est libre de les gérer comme il l'entend. La mise en place d'une
fédération nécessite la coopération de différents fournisseurs de service et
notamment, que chacun accorde sa confiance aux autres puisqu'il délègue l'accès à
52
PME.
53
Service Provider (SP) dans la terminologie Liberty Alliance.
26
ISNET 76
son application au serveur d'identité. Ces questions se règlent de manière
contractuelle54.
Si par exemple, le fournisseur de service est une compagnie d'aviation qui propose
une application Internet de vente de ses billets. Cette compagnie peut avoir envie de
s'associer avec des hôtels et des entreprises de location de véhicules de sorte que ses
clients puissent facilement naviguer de l'application de vente de billets vers celles des
entreprises partenaires, sans avoir besoin de s'identifier à nouveau.
La compagnie d'aviation devra conserver les coordonnées de ses clients (nom,
adresse, numéro de carte de crédit, etc.) et les protéger par un login55. Chaque
ensemble d'informations caractérisant un client et identifié par un login est
mémorisé et constitue l'identité au sens de la compagnie d'aviation.
Remarquons que suivant le type de fournisseur de service, l'identité d'un utilisateur
sera constituée d'informations différentes ; en effet, l'entreprise partenaire de
location de véhicules devra connaître le type de permis de conduire dont dispose le
client et d'autres informations encore. L'utilisateur du système a alors deux identités
distinctes, l'objectif de la fédération étant justement de les mettre en relation.
4.1.2 Le fournisseur d'identité
Le fournisseur d'identité56 est le serveur qui fait le lien entre les différentes identités
des fournisseurs de service ayant conclu un accord de partenariat. C'est au
fournisseur d'identité que s'adressent les fournisseurs de service lors de la phase
d'authentification pour déterminer si un utilisateur a déjà été identifié par un autre
partenaire de la fédération57.
Lorsqu'un fournisseur de service veut faire partie d'une fédération, il doit
obligatoirement mettre en place un fournisseur d'identité pour gérer cette
fédération.
4.1.3 Le client
Le client58 des services offerts par les fournisseurs de service d'un cercle de confiance
possède des identités chez chacun d'eux (et donc autant de logins). En fédérant ces
identités, il va pouvoir éviter de s'identifier auprès de chacun de ces fournisseurs de
service. Il lui suffira d'être identifié auprès de l'un d'entre eux pour que les autres
59
arrivent à le reconnaître .
Le client est généralement matérialisé par un browser via lequel il accède aux
informations des fournisseurs de service qui l'intéressent. Les requêtes
d'authentification effectuées par l'application des fournisseurs de service sont
54
Le sujet des dispositions contractuelles n'est pas traité par Liberty Alliance. Elles doivent faire partie du business modèle mis en
place par le fournisseur de service.
55
Couple identification / mot de passe.
56
Identity Provider (IDP) dans la terminologie Liberty Alliance.
57
Pour une description détaillée du fonctionnement, voir chapitre 2.4.
58
Personal dans la terminologie Liberty Alliance.
59
Pour une description détaillée du fonctionnement, voir chapitre 2.4.
27
ISNET 76
redirigées vers le ou les fournisseurs d'identité concernés qui, en réponse,
transmettent les informations d'identification strictement nécessaires.
4.2 Composants matériels et logiciels nécessaires
Le déploiement d'une application Internet au sein d'une fédération d'identité
requiert un certain nombre de ressources matérielles et logicielles. Celles-ci devront
être installés sur les divers sites des membres de la fédération.
4.2.1 Logiciel
Le premier composant nécessaire est bien sûr l'application Internet fournissant le
service en relation avec le métier de l'entreprise et que celle-ci désire intégrer à une
fédération d'identité. Si l'application n'a pas été conçue avec ce dernier objectif, il
faudra en principe la modifier pour que l'identification de l'utilisateur s'effectue via le
fournisseur d'identité.
La mise en place du système de fédération d'identité lui-même s'effectue à travers
l'installation d'un serveur d'identité respectant les spécifications de Liberty Alliance.
Chaque membre de la fédération devra déployer un serveur d'identité respectant ces
spécifications. Il n'est évidemment pas nécessaire que les partenaires de la fédération
mettent en œuvre le même logiciel ; en effet, si les deux logiciels sont certifiés par
Liberty Alliance, alors ils sont par définition compatibles entre eux60.
Le fournisseur de service doit installer un serveur d'identité, ce qui aura pour
conséquence d'installer un certain nombre de Web services que l'application Internet
va employer pour déterminer si l'utilisateur a déjà été authentifié ou si elle doit
présenter une page d'identification. De même, si l'application identifie elle-même
l'utilisateur, elle doit le signaler à son serveur d'identité via les Web services qui ont
été installés.
Le client n'a besoin que d'un simple navigateur Internet par l'intermédiaire duquel il
accède aux services offerts par les membres d'une fédération d'identité. En effet, sur
le poste du client, la mise en œuvre se résume à l'emploi de fonctionnalités
disponibles depuis fort longtemps pour tous les browsers, à savoir la redirection http
et les cookies. De ce fait, le client peut se trouver en n'importe quel lieu muni d'une
connexion Internet.
4.2.2 Matériel
Concernant le matériel, le fournisseur de service utilise en principe une machine
comme serveur d'application pour faire fonctionner ses services propres et les
services qu'elle met à disposition de la fédération, une seconde machine
fonctionnant comme serveur d'identité et enfin un serveur Internet donnant l'accès à
ses services. Ces rôles peuvent bien évidemment être remplis par une seule et unique
machine physique, tout comme ils peuvent être répartis sur deux machines dans
n'importe laquelle des trois combinaisons61 possibles.
60
Voir chapitre 3.3.
61
Si SA : serveur d'application, IDP : serveur d'identité et SI : serveur Internet, on peut combiner (SA+IDP)(SI) ou (SA+SI)(IDP) ou
encore (SA)(IDP+SI).
28
ISNET 76
Cependant, une même machine physique peut jouer plusieurs rôles dans des
contextes différents. En effet, il est tout a fait possible que la machine héberge une
configuration faisant d'elle un serveur d'identité dans un cercle de confiance donné
et en même temps fonctionner comme fournisseur de service dans un autre cercle de
confiance.
Le client enfin n'a besoin que d'un poste de travail sur lequel il peut faire fonctionner
un navigateur Internet.
4.3 Implantation
Des expériences de fédération d'identité ont déjà été mises en œuvre ou sont en
cours de déploiement dans de très grands groupes d'entreprises parmi lesquels on
peut citer, non exhaustivement, France Télécom62 et General Motors63.
France Télécom est principalement un fournisseur d'accès. Dans son cas, la
fédération d'identité est mise en œuvre pour faciliter l'accès de ses clients à des
services fournis par d'autres membres du groupe, principalement ses filiales de
e-commerce. En fédérant les identités de ses abonnés avec celles de ses filiales,
France Télécom espère ainsi encourager ses clients à naviguer – et donc à acheter –
sur les sites de ses filiales plutôt que sur ceux de ses concurrents.
En ce qui concerne General Motors, la fédération d'identité est principalement
déployée dans le cadre du système intranet de l'entreprise ainsi qu'en interaction
avec des services externes que General Motors met à la disposition des ses employés.
Parmi ceux-ci, on peut citer le fournisseur d'accès AOL : les identifications AOL des
employés de General Motors sont fédérées avec celles de l'intranet de la société. Un
employé passe ainsi de façon transparente des activités relevant du domaine de sa
sphère privée – surfer sur le net – au monde de l'entreprise64.
D'autres consortiums ont également envisagé la fédération d'identité comme
solution aux problèmes posés par le fait que leur informatique est composée d'un
grand nombre de systèmes disparates et non compatibles65. C'est par exemple le cas
de l'administration publique de la République Française [Min02]. Dans un tel
environnement, les systèmes sont tout d'abord reliés entre eux par un réseau, puis la
fédération d'identité est employée pour mettre en place, sur chaque système
individuel, des services disponibles sur Internet auxquels ont peut ensuite accéder
66
sans peine depuis n'importe quelle partie du système .
62
Voir [Fra04].
63
Voir http://project-liberty.org/about/enabledproducts.php
64
À ce propos, on pourrait d'ailleurs se poser tout un ensemble de questions relevant de l'éthique ; ces questions dépassent le
cadre de cette étude.
65
Cette situation est beaucoup plus répandue qu'on ne pourrait le croire. Cette multiplication des systèmes est en général liée à
l'historique de la création de l'entreprise et de son développement, sur plusieurs régions et/ou pays, en filiales indépendantes,
collaborant toutes avec la maison mère.
66
On voit donc que, même détournée de sa vocation première qui est de gérer des communautés d'utilisateurs, la fédération
d'identité trouve des applications dans l'intégration de l'informatique d'entreprise.
29
ISNET 76
4.3.1 La cible
Les grandes entreprises évoquées dans le précédent chapitre disposent en général
d'un département informatique conséquent, équipé d'une grande quantité de
matériel performant et au sein duquel travaillent plusieurs dizaines, voire plusieurs
centaines de collaborateurs.
Nous nous proposons de concevoir une solution adaptées aux petites et moyennes
entreprises67 du tissu économique local. On sait que ce type d'entreprises – moins de
250 employés – représente la très grande majorité des entreprises suisses68. Parmi ces
entreprises, celles qui nous intéressent tout particulièrement sont celles qui gèrent
elles-mêmes leur informatique. Une enquête réalisée en 200569 auprès de 138
entreprises de la région genevoise a mis en évidence que 64% des entreprises
interrogées possédaient un département informatique [Pag05]. Une autre étude,
réalisée en 200270 et portant sur 465 entreprises de la Suisse Romande, a montré que
38% des entreprises consultées faisaient réaliser leur site Internet par leur propre
équipe d'informaticiens ; de plus, pour 21% des entreprises, le site Internet est relié
au système d'information de l'entreprise [Leh02]. Nous considérerons donc des
entreprises dont le système informatique correspond à l'architecture de la figure 4.2.
Fig. 4.2 : L'architecture du système informatique des entreprises considérées.
Remarquons que la figure 4.2 illustre les différents éléments conceptuels que sont les
serveurs de données, d'applications et Internet par trois machines physiques
différentes. Ces trois fonctions peuvent bien sûr être remplies par une unique
machine physique, tout comme chacune d'elles peut être remplie par plusieurs
machines physiques. Tout va dépendre de la taille de l'entreprise et de la puissance
de calcul nécessitée par les différentes applications métier qu'elle fera fonctionner
67
PME.
68
L'Office fédéral de la statistique a déterminé lors de son dernier recensement qui date de 2001 que largement plus de 90%
des entreprises étaient des PME (http://www.bfs.admin.ch). Cette observation doit tout de même être tempérée par le fait que
plus de 80% des entreprises sont des entités employant moins de 10 personnes.
69
Enquête effectuée dans le cadre d'un travail de diplôme à la HEG Genève et portant sur l'ASP.
70
Étude réalisée par l'Inforge, HEC Lausanne, PSINet et le GRI et portant sur l'utilisation de l'Internet dans les entreprises
romandes.
30
ISNET 76
avec son système. Notons enfin que divers éléments de sécurité, tels que des
pare-feux71, doivent également être mis en place et ne sont pas représentés sur ce
schéma.
4.3.2 Architecture du système
Comme nous l'avons vu plus haut, pour qu'un fournisseur de service puisse faire
partie d'une fédération, il est nécessaire de modifier l'architecture du système et d'y
adjoindre un serveur d'identité. La figure 4.3 illustre cette nouvelle architecture du
système de l'entreprise.
Fig. 4.3 : La nouvelle architecture du système.
Comme nous l'avons déjà mentionné, le serveur d'identité n'est pas forcément
matérialisé par une machine physique distincte des autres. Cette fonction peut tout à
fait être assumée par une des autres machines physiques du site.
4.3.3 Accès aux services
Les services délivrés par un tel système sont ceux qui correspondent au métier de
l'entreprise. Très souvent, faute d'accords avec des partenaires potentiels, ces
services sont strictement réservés aux employés et ne sont donc disponibles que
depuis une connexion effectuée depuis un poste de travail du réseau local de
l'entreprise.
Si l'activité principale de l'entreprise consiste à effectuer du commerce électronique
en ligne ou une activité analogue impliquant des transactions financières telles que
des paiements, une partie des utilisateurs du système s'y connecte depuis l'extérieur
de l'entreprise, via Internet. Deux cas de figure peuvent alors se présenter :
Chaque paiement donne lieu à une transaction sécurisée au cours de laquelle
le client transmet ses informations d'identité personnelles telles que l'adresse
de livraison et le numéro de sa carte de crédit.
71
Firewall.
31
ISNET 76
L'entreprise gère, pour chacun de ses clients, un login formé d'une paire
identification / mot de passe à laquelle les informations d'identité personnelles
sont associées. Lors d'une transaction, seul le login est fourni par le client, le
système se chargeant de retrouver les informations qui y sont associées.
La première solution a l'inconvénient que le client doit fournir ses informations
personnelles chaque fois qu'il effectue une transaction avec l'entreprise ; de plus, des
informations confidentielles telles que le numéro de carte de crédit seront transmises
lors de chaque transaction, augmentant ainsi les risques de vol.
Pour la seconde solution, l'entreprise devra gérer des identifications pour ses clients
auxquelles elle associera les informations d'identité personnelles. Cette solution est
plus ergonomique pour le client qui doit saisir moins d'information lors de chaque
transaction ; elle est plus sûre également, puisque les informations confidentielles ne
sont transmises qu'une seule fois.
4.3.4 Authentification
Pour pouvoir faire partie d'une fédération d'identité, le système de l'entreprise doit
impérativement authentifier ses utilisateurs. Les utilisateurs doivent être authentifiés
au niveau du système de l'entreprise, de telle sorte que cette authentification soit
valide pour l'ensemble des applications auxquelles les utilisateurs ont accès. Ces
utilisateurs sont bien sûr les employés de l'entreprise, mais également les clients de
celle-ci, si ces derniers ont accès au système de l'entreprise par l'intermédiaire
d'Internet72.
Si aucun système d'authentification n'est mis en place, celui-ci pourra être pris en
charge par le serveur d'identités que nous avons ajouté au système. Si un système
centralisé d'authentification existe déjà, celui-ci pourra s'intégrer à la nouvelle
configuration.
Si par contre les identifications s'effectuent au coup par coup, sous la responsabilité
individuelle de chacune des applications fournissant les services, ces applications
devront être modifiées pour s'intégrer à une authentification centralisée.
4.3.5 Logiciel
De nombreux produits conformes aux spécifications et qui ont donc obtenu une
certification de Liberty Alliance sont disponibles sur le marché. Parmi ceux-ci, nous
suggérons d'employer Sun Java™ System Access Manager, car il s'intègre
relativement facilement à la plupart des plates-formes du marché et qu'il est possible
d'en obtenir des versions gratuitement pour effectuer des développements et tester
des configurations73. De surcroît, Sun Microsystems™ étant l'initiateur et l'un des
acteurs et animateurs principaux du consortium Liberty Alliance, ce choix garantit
une implantation la plus conforme possible des spécifications ; on peut compter enfin
sur le fait que, étant donné la position de Sun Microsystems™, les évolutions des
spécifications de Liberty Alliance seront intégrées rapidement dans leurs produits.
72
Notons que toute la partie du site Internet qui représente la vitrine de l'entreprise peut rester en accès libre. Seuls les accès
aux services sécurisés doivent être munis d'un système d'authentification.
73
C'est uniquement lorsqu'on décide d'en faire une exploitation commerciale qu'il est nécessaire d'acheter le produit.
32
ISNET 76
Ce système permet de gérer les identifications de manière centralisée, ainsi que la
fédération d'identité. Il fait partie de la suite Sun Java™ Entreprise System qui
comprend un serveur d'applications. Dans le cas d'applications s'exécutant sous le
contrôle de ce dernier, il sera donc relativement simple de mettre en place la
configuration d'un fournisseur de service intégré à un cercle de confiance.
Remarquons que si le système de l'entreprise est déjà muni d'une procédure
d'authentification centralisée et que celle-ci est réalisée par un logiciel d'un
constructeur offrant par ailleurs un composant de gestion de la fédération d'identité
certifié Liberty Alliance, nous conseillons alors de déployer ce dernier. En effet, une
telle solution aura pour avantage, en principe74, de diminuer grandement le temps
nécessaire à l'administrateur du système pour se familiariser avec le nouveau
composant, puisqu'il aura déjà l'habitude de travailler avec d'autres produits du
même constructeur.
4.3.6 Systèmes Microsoft Windows™
La compagnie Microsoft ne fait pas partie du consortium Liberty Alliance et offre des
solutions propriétaires, aussi bien pour l'authentification des utilisateurs du système
que pour la fédération d'identité. Les utilisateurs d'un domaine Windows™ sont
répertoriés via la technologie Active Directory qui est une implémentation du
protocole LDAP75. La fédération d'identité est implantée au moyen du composant
ADFS76 qui implante les spécifications de WS-Federation et fournit la technologie de
single sign-on pour les applications Internet dans un environnement Windows™.
Notre objectif, dans le cadre de ce projet, est de définir une architecture qui permet
de fédérer le système de l'entreprise avec des systèmes qui se conforment aux
spécifications de Liberty Alliance. Une telle architecture est ouverte et indépendante
des spécifications propriétaires d'un constructeur particulier. ADFS n'est pas
compatible avec les spécifications ID-FF de Liberty Alliance. Néanmoins, de nombreux
produits certifiés Liberty Alliance, dont le logiciel proposé au chapitre 4.3.5, sont
capables de s'appuyer sur les services fournis par Active Directory pour gérer les
authentifications des utilisateurs. De même, comme démontré dans les prototypes
réalisés, il est possible de mettre en place des serveurs multi protocoles qui
permettent l'inter opérabilité entre ADFS et Liberty Alliance.
4.3.7 Procédure
L'ensemble des éléments que nous avons évoqués nous amène à définir la procédure
de la figure 4.4 qui décrit la suite des différentes opérations à accomplir, en fonction
de la configuration initiale du système de l'entreprise, pour rendre ce dernier
compatible avec la fédération d'identités. Remarquons que certaines des étapes de
cette procédure, bien qu'étant relativement simples, peuvent avoir un coût non
négligeable, en particulier l'étape Modifier les applications.
74
Ce n'est bien sûr vrai que si le constructeur s'est préoccupé de maintenir une unité ergonomique entre les différents produits
constituant son offre.
75
Lightweight Directory Access Protocol.
76
Active Directory Federation Protocol.
33
ISNET 76
Fig. 4.4 : Étapes de la mise en conformité du système avec la fédération d'identités.
La réalisation de ces étapes permet d'obtenir un système au sein duquel les
utilisateurs s'authentifient avec un unique login77, ce qui est un gain appréciable pour
les systèmes pour lesquels ce n'était pas le cas. En effet, les nouvelles applications qui
seront développées dans ce cadre pourront aisément être intégrées à ce système et
s'appuyer dessus pour gérer l'authentification et les droits d'accès des différents
utilisateurs.
De plus, ce système est maintenant prêt à fonctionner dans le cadre d'une fédération
d'identités. Il peut faire partie d'un cercle de confiance et donc autoriser l'accès à ses
services à des utilisateurs externes authentifiés par des partenaires. De même, les
utilisateurs du système peuvent naviguer de façon transparente vers les services
offerts par les partenaires.
77
Single sign-on.
34
ISNET 76
5 MODÈLE BUSINESS
La gestion de l'authentification et de la fédération d'identité sont essentiellement
indépendantes du métier exercé par l'entreprise. Nous nous intéresserons donc
principalement aux aspects qui concernent la gestion de l'identité et son partage
avec des partenaires. Le modèle que nous allons décrire enrichit donc le modèle
business mis en œuvre par l'entreprise pour exercer son métier ; dans certains cas, les
revenus seront obtenus par des moyens différents, éventuellement à moindre coût
que le modèle de base, dans d'autres, de profits complémentaires et/ou
supplémentaires pourront être générés.
5.1 Cadre
Les différents concepts formant un business modèle78 peuvent être schématisés par la
figure 5.1. Ces concepts sont répartis en quatre grands piliers qui couvrent les
différents aspects à envisager lors de la définition de la structure de l'entreprise et de
son réseau de partenaires pour la création, le marketing et la livraison de valeurs avec
pour objectif la génération de profits durables [Dub02].
Innovation
produit
Relation
client
Clientèle ciblée
Stratégie d'information
Proposition de valeur
valeur proposée
Confiance / fidélité
nécessaire à
Compétences
Canaux de distribution
Gestion de
l'infrastructure
Aspects
financiers
Ressources et moyens
Modèle de revenu
Configuration activités
Modèle de profit
Réseau partenaires
Structure de coût
Fig. 5.1 : Les piliers des modèles business.
Ces piliers représentent respectivement les produits offerts79 par une entreprise qui
forment la valeur pour laquelle le client est disposé à payer, l'infrastructure et le
réseau de partenaires80 nécessaires à la création de valeur, les relations que
78
Principalement dans le contexte des nouvelles technologies de l'information.
79
Innovation produit : quoi ?
80
Gestion de l'infrastructure : comment ?
35
ISNET 76
l'entreprise entretient avec ses clients81 pour générer des revenus et les aspects
financiers82 des trois autres piliers tels que les modèles de coûts et de profit.
5.2 Type d'échange
La fédération d'identité permet à des systèmes informatiques d'entreprises
partenaires de reconnaître mutuellement les authentifications d'utilisateurs qu'ils ont
effectué. Le type d'échange de service qui aura lieu sera donc principalement de type
83
B2B . Dans certains cas, suivant le métier de l'un des partenaires, des échanges de
type B2C84 peuvent également être affectés par la fédération. Le modèle proposé
ci-dessous se base sur un type d'échange du type B2B ; le "client" est donc une
personne morale. S'il y a lieu, les éléments affectant une relation B2C que l'un des
partenaires pourrait avoir seront mentionnés explicitement.
5.3 Innovation produit
Services offerts
Chacun des différents partenaires d'une fédération d'identité offre un certain
nombre de services aux autres. Ce sont :
la reconnaissance d'utilisateurs authentifiés par les entreprises partenaires ;
la fourniture d'attributs d'identité aux entreprises partenaires pour les
utilisateurs authentifiés.
Si l'entreprise est de surcroît engagée dans une relation B2C avec des clients via son
site Internet, le service offert au client est :
la simplification de sa procédure d'identification pour l'ensemble des sites des
partenaires de la fédération par la mise à la disposition d'une identification
unique.
Proposition de valeur
Les valeurs de ces services sont :
la simplification de l'accès aux services du système par les utilisateurs
authentifiés par les entreprises partenaires ;
la fourniture automatique d'informations utiles aux entreprises partenaires
pour effectuer leurs transactions.
En ce qui concerne les clients d'une relation B2C, les valeurs de ces services sont :
l'amélioration ergonomique de la navigation entre les sites Internet des
différents partenaires de la fédération ;
les valeurs spécifiques du métier de l'entreprise qui sont proposées au client
peuvent être ciblées en fonction d'un profil qui peut être établi finement grâce
aux différents attributs associés à son identité.
81
Relation client : qui ?
82
Aspects financiers : combien ?
83
Business to business.
84
Business to customer.
36
ISNET 76
Clientèle ciblée
Dans le cas de la relation B2B :
les clients sont les partenaires commerciaux de l'entreprise.
Dans le cas de la relation B2C :
la clientèle est identique à celle définie pour le métier de l'entreprise ; la
fédération peut toutefois générer une nouvelle clientèle atteinte indirectement
au travers des partenaires de la fédération.
Compétences
L'entreprise dispose des compétences nécessaires pour offrir les valeurs proposées
par le fait même que le système informatique de l'entreprise est architecturé de telle
sorte qu'il puisse gérer la fédération d'identité. Ces compétences sont vraiment
disponibles, parce que l'entreprise gère elle-même son système informatique85.
5.4 Gestion de l'infrastructure
Configuration des activités
Pour mettre en œuvre la fédération d'identité, les différents partenaires concernés
doivent :
définir clairement les responsabilités de chaque entreprise ;
établir la liste des risques en cas de litige ou de fraude ;
élaborer les procédures de fédération des identités et celles pour terminer une
relation de confiance86 ;
définir la nature et le format des attributs à échanger entre les systèmes des
entreprises ;
rédiger les conditions d'utilisation et les chartes de sécurité.
D'un point de vue juridique87, il faut également :
que les données personnelles des utilisateurs soient protégées conformément
aux lois en vigueur ;
que l'anonymisation des données personnelles transmises soit garantie ;
que les procédures de résolution des litiges en cas de fraude ou de panne des
services offerts soient définies.
Réseau de partenaires
Les entreprises partenaires d'une fédération d'identité établissent des contrats de
partenariat bilatéraux ; l'objectif stratégique commun étant de regrouper dans un
85
Voir chapitre 4.3.1. Il en irait autrement si la gestion de l'informatique de l'entreprise étaient confiée à un tiers dans le cadre
d'une solution ASP par exemple.
86
Une relation de confiance peut se terminer en cas de fin de vie d'un service, d'une cessation d'activité de l'un des partenaires
ou encore du désengagement de l'association de l'un des partenaires.
87
Les aspects juridiques devront être particulièrement étudiés dans le cas d'établissement de partenariats inter cantonaux ou
encore transfrontaliers. En effet, tant les lois sur la protection des données que celles régissant les litiges dépendent en général
de la localisation géographique du siège social des partenaires et peuvent être différentes d'une entité juridique à l'autre.
37
ISNET 76
cercle de confiance un ensemble de métiers complémentaires et dont les services
collaborent.
Ressources et moyens
Les équipements suivants sont nécessaires à la création des valeurs proposées :
un serveur qui sera chargé de la gestion des identités et de leur fédération ;
comme déjà évoqué au chapitre 4.3.2, une nouvelle machine physique n'est
pas forcément nécessaire ;
un logiciel de gestion et d'administration de la fédération d'identité ; ce logiciel
sera déployé sur la nouvelle machine physique mentionnée ci-dessus ou sur
l'un des serveurs existants.
Le strict minimum des équipements nécessaires se résume donc au logiciel de gestion
de la fédération, le reste pouvant s'appuyer sur des ressources déjà existantes.
Remarquons que l'acquisition d'une machine dédiée à la gestion de la fédération
augmentera les performances globales du système informatique de l'entreprise, en
particulier ses temps de réponse, contribuant ainsi à la consolidation et à
l'amélioration de la réputation de l'entreprise auprès de ses partenaires et de ses
clients.
En ce qui concerne les ressources humaines, il est nécessaire de disposer d'un
administrateur système dont les responsabilités sont :
l'installation, la configuration et la maintenance du serveur de gestion de la
fédération d'identités ;
la gestion des identités des utilisateurs du système.
Ces ressources sont en partie disponibles, car une entreprise qui gère elle-même son
système informatique dispose déjà d'une personne qui s'occupe de l'administration
de ce système. Une disponibilité ponctuelle de l'administrateur en phase initiale du
projet sera nécessaire pour procéder à l'installation et à la configuration du serveur
d'identités. Les activités de maintenance et de gestion des identités quant à elles
représentent une charge qu'on peut évaluer au maximum à deux jours par mois ;
celles-ci pourront donc être facilement intégrées au cahier des charges de
l'administrateur, éventuellement en transférant une partie des ses responsabilités
vers d'autres collaborateurs de la division informatique de l'entreprise.
5.5 Relation client
Stratégie de l'information
Dans le cas de la relation B2B :
les clients sont des partenaires qui exercent un métier qui est complémentaire
à celui de l'entreprise ; les informations les concernant sont donc a priori
connues et ont donc déjà été récoltées ;
cette connaissance des caractéristiques des partenaires permet de définir de
façon optimale les accords bilatéraux de partenariat.
Dans le cas de la relation B2C :
les habitudes des clients, leur façon de naviguer dans le site de l'entreprise et
entre les différents sites des partenaires sont relevées et exploitées pour définir
38
ISNET 76
un profil personnalisé du client qui est mémorisé dans les attributs associés à
son identité ; en fonction de ce profil, des opportunités d'achat ciblées lui sont
proposées.
Confiance et fidélité
L'entreprise entretient, en principe, un climat de confiance avec ses partenaires
commerciaux usuels. Celui-ci est renforcé par :
la conclusion d'accords formels de partenariat, spécifiant explicitement et de
façon détaillée les droits et devoirs de chacune des parties ;
le fait que les accords de partenariat s'inscrivent dans un cadre juridique
clairement défini – code des obligations, loi fédérale sur la protection des
données88.
En offrant des capacités de fédération d'identité pour l'emploi de ses services,
l'entreprise s'ouvre à de nouveaux partenaires intéressés par la simplification des
procédures d'accès ainsi que l'automatisation des transactions, gagnant par là même
des parts de marché sur le terrain de l'échange d'informations d'identité.
Dans le cas de la relation B2C, les clients doivent faire confiance à l'entreprise à
propos de l'exploitation qui sera faite de leurs données personnelles. Cette confiance
est établie et renforcée en :
leur rappelant explicitement qu'un cadre juridique contraignant, la loi fédérale
sur la protection des données, fixe les limites de l'exploitation des données
personnelles ;
leur permettant de s'exclure explicitement de listes de publipostages
publicitaires et leur garantissant que leurs données personnelles ne seront pas
transmises à des tiers ;
exploitant le profil du client avec intelligence et parcimonie dans le but de
créer une dynamique de relation positive.
Les clients des entreprises partenaires sont incités, par la simplification des
procédures d'identification et par des liens croisés figurant dans les sites des
partenaires, à profiter des services de l'entreprise qui acquiert par ce biais un
nouveau segment de clientèle.
Canaux de distribution
Les valeurs proposées sont diffusées aux partenaires au travers de l'Internet, au sein
des cercles de confiances établis et formalisés par les divers accords bilatéraux
conclus.
5.6 Aspects financiers
Modèle de revenu
Chaque fourniture d'attributs d'identité aux entreprises partenaires est facturée sous
la forme d'un micro paiement, le montant de ces paiements est modulé par la
quantité et la qualité des informations fournies.
88
Voir [LPD92].
39
ISNET 76
Les transactions effectuées par le partenaire grâce à ces attributs donnent lieu au
versement d'une commission.
Dans le cadre d'une relation B2C, l'entreprise diversifie son offre de services en
proposant à ses clients des liens vers ses partenaires de la fédération, exerçant ainsi
un effet de levier sur les sources de revenus qui viennent d'être énoncées.
Structure de coût
Les coûts supplémentaires à ceux déjà engagés dans l'accomplissement du métier de
l'entreprise d'une telle solution sont constitués :
du prix d'achat du matériel (serveur) dédié à la gestion de la fédération
d'identités ;
du montant de la licence d'exploitation du logiciel de gestion et
d'administration de la fédération d'identités ;
d'une fraction du salaire de l'administrateur chargé de la gestion des identités
des utilisateurs du système et de la maintenance du système de fédération.
Modèle de profit
Les coûts du système sont principalement constitués de coûts fixes – le prix du
matériel et le montant de la licence – qui peuvent rapidement être amortis.
La couverture des autres frais et la génération de profit sont déterminées en
extrapolant les résultats des opérations effectuées avec les partenaires commerciaux
de l'entreprise avant la mise en œuvre du nouveau système.
Dans le cas d'une relation B2C, on peut également espérer une augmentation du
chiffre d'affaires dans le domaine du métier de l'entreprise dans la mesure où, via le
réseau de partenaires de la fédération, elle va atteindre de nouveaux clients.
Dans le cas de relations B2B, la productivité des employés est améliorée par le fait
que leur navigation au sein des sites des entreprises partenaires de la fédération s'en
trouvera simplifiée.
Enfin, le temps de développement de nouvelles applications au sein de l'entreprise se
trouvera réduit par le fait que tous les aspects de la gestion de l'authentification et
de la mémorisation des attributs d'identité nécessaires à l'application sont pris en
charge par le composant de fédération. Le temps nécessaire à la gestion des
utilisateurs sera également réduit, puisqu'une partie des attributs de ceux-ci seront
gérés par les partenaires.
40
ISNET 76
6 PROTOTYPES
L'architecture proposée au chapitre 4.3.2 a été testée en réalisant un prototype dont
les procédures d'installation sont décrites dans l'annexe A.
Différents prototypes d'architectures prenant en compte les différents scénarios
envisageables, y compris des solutions basées sur Microsoft Windows™, ont été
étudiés et réalisés et sont décrits dans l'annexe B. L'inter opérabilité des solutions
Windows™ avec Liberty Alliance est également démontrée.
41
ISNET 76
7 CONCLUSION
Dans le monde économique actuel, les entreprises partagent de plus en plus
d'informations avec leurs clients et leurs partenaires commerciaux. Ces différents
acteurs évoluent dans un environnement distribué dont Internet est la colonne
vertébrale. Les fonctions même de l'Internet ont évolué de la simple interconnexion
d'ordinateurs vers celle d'applications et de services ; simultanément, le nombre de
clients, de dispositifs et de points d'accès à ces applications et services a explosé.
Les utilisateurs de ces applications et services, qu'ils soient de simples clients ou des
employés de l'entreprise doivent s'authentifier pour y avoir accès. La gestion de
l'identité est ainsi devenue un élément vital de toute transaction commerciale
effectuée au travers de ces applications et services. L'accès à chaque application ou
service est en général protégé par un système d'authentification propre ; la
multiplication des identités est ainsi devenu le cauchemar des utilisateurs
commerciaux de l'Internet.
Les spécifications émises par Liberty Alliance définissent une architecture de gestion
de l'identité digitale dont le pilier fondamental est la fédération d'identités. Ce
concept permet à un utilisateur authentifié par un service d'une entreprise de
naviguer librement vers les services d'entreprises partenaires, faisant partie d'un
même cercle de confiance.
De grands groupes comme General Motors, ou encore France Télécom ont
commencé à mettre en œuvre ces principes à grande échelle, en ayant comme
objectif l'intégration des dizaines de systèmes disparates et des centaines
d'applications legacy des différentes entreprises faisant partie du groupe.
Nous avons montré que ces concepts étaient également applicables à beaucoup plus
petite échelle et avec un autre objectif. En effet, moyennant un investissement en
matériel, logiciel et ressources humaines très raisonnable, une PME peut
actuellement transformer l'architecture de son système d'information existant de
sorte qu'il soit compatible avec la fédération d'identité. Si ses partenaires
commerciaux en font autant, elle peut alors établir un cercle de confiance avec
ceux-ci, jetant ainsi les bases de nouvelles formes de collaboration entre les différents
partenaires.
Les entreprises concernées fonctionnent selon un modèle d'affaires qui est spécifique
au métier qu'elles exercent. Nous avons proposé un modèle d'affaires qui complète
celui-ci et qui définit les bases de ces collaborations. Nous avons montré que ces
collaborations pouvaient être profitables, qu'elles étaient source de nouveaux
revenus, qu'elles permettaient de réduire un certain nombre de coûts et, enfin,
qu'elles pouvaient être génératrices de nouveaux marchés.
Microsoft™, l'un des principaux acteurs du marché, ne fait pas partie de Liberty
Alliance et a défini un standard de fédération propriétaire. Nos prototypes illustrent
comment construire des solutions entièrement Microsoft™ d'une part, comment
définir des solutions inter opérables avec les produits implantant les spécifications de
Liberty Alliance d'autre part.
Nous avons ainsi défini les bases d'une solution complète et cohérente qui permet
aux entreprises de prendre en connaissance de cause les décisions stratégiques
techniques et commerciales nécessaires à leur positionnement dans un
42
ISNET 76
environnement distribué sécurisé et convivial. Pour que les PME adoptent ce type de
solution et modernisent leur fonctionnement, il faut bien sûr qu'elles s'affranchissent
de l'isolationnisme bien helvétique qui prévaut encore dans nombre d'entreprises,
principalement celles à base fortement familiale. Nous devons leur faire comprendre
que l'informatique n'est qu'un outil parmi d'autres pour accomplir leur mission. Il n'y
a pas de profit direct et immédiat à mettre en œuvre la fédération d'identité ; il s'agit
plutôt de mettre en place une structure qui s'inscrit dans une vision à moyen et long
terme du mode de fonctionnement de l'entreprise.
La fédération d'identité constitue, nous l'avons vu, le pilier fondamental des
spécifications de Liberty Alliance. Ces spécifications comportent également la
description d'autres services, de plus haut niveau, et pour lesquels les partenaires du
consortium vont fournir des implantations dans une seconde phase. Ces services
permettront principalement d'assurer l'inter opérabilité des Web Services requérant
une authentification et d'implanter de nouvelles fonctionnalités tels que la géo
localisation, des carnets de contacts décentralisés, des calendriers partagés, des
services de présence ou d'alerte, etc. Nous envisageons, pour nos recherches futures,
d'approfondir ces aspects qui sont la base sur laquelle il sera possible de construire
une architecture orientée services89 au sein d'une fédération, architecture qui sera un
enjeu stratégique pour l'entreprise de demain.
89
SOA.
43
ISNET 76
8 BIBLIOGRAPHIE
[Ang05]
Rajeev Angal, Srividhya Narayanan, Pat Petterson, Malla Simhachalam,
Building Identity-Enabled Web Services,
http://developers.sun.com/prodtech/identserver/reference/techart/idenabled-ws.html, 18 octobre 2005
[Ber04]
Philippe Beraud, Jean-Yves Grasset, Gestion des identités numériques,
http://www.microsoft.com, mai 2004
[Boy02]
Danah Boyd, FACETED ID/ENTITY : Managing representation in a digital
world, http://smg.media.mit.edu/people/danah/thesis/danahThesis.pdf,
septembre 2002
[Cah05]
Conor Cahill & al., Liberty Technology Tutorial,
http://www.projectliberty.org/liberty/content/download/800/5730/file/Spec
sOverviewAOL.pdf, 2005
[Cha02]
David Chappel, Tyler Jewell, Java Web Services, O'Reilly & Associates, Mars
2002, ISBN 0596002696
[Cla02]
Mike Clark, Peter Fletcher, Jeffrey Hanson, Romin Irani, Mark Waterhouse,
Jorgen Thelin, Web Services Business Strategies and Architectures, Expert
Press, Août 2002, ISBN 1904284132
[Cro05]
Pierre Cros, Authentic – Guide de l'administrateur,
http://authentic.labs.libre-entreprise.org/doc/fr/authentic-admin.html,
2005
[Dei02a]
Harvey Deitel, Paul Deitel, J. Gadzik, K. Lomeli, S. Santry, S. Zhang, Java
Web Services For Experienced Programmers, Prentice Hall, Août 2002,
ISBN 0130461342
[Dei02b]
[Dub02]
Harvey Deitel, Paul Deitel, B. Duwalt, L. Trees, Web Services: A Technical
Introduction, Prentice Hall, Août 2002, ISBN 0130461350
Magali Dubosson-Torbay, Alexander Osterwalder , Yves Pigneur, eBusiness
Model Design, Classification and Measurements, Thunderbird
International Business Review, vol 44, n°1, Janvier 2002
[Faj05]
Aries Fajar Dwiputera, Single Sign-On architectures in public networks,
INFOTECH Seminar Advanced Communication Services (ACS), 2005,
http://www.linecity.de/INFOTECH_ACS_SS05/infotech_acs_ss05.html.
[Fra04]
France Telecom, Focus sur Liberty Alliance,
http://www.francetelecom.com/sirius/rd/fr/ddm/fr/technologies/ddm20041
0/print_index1.htm, Octobre 2004
[JDN03]
JDN Solutions, Liberty Alliance : les premiers projets voient le jour,
http://solutions.journaldunet.com/0311/031114_liberty.shtml,
14 novembre 2003
[Kem04]
John Kemp, Liberty ID-WSF – a Web Services Framework,
http://www.projectliberty.org/liberty/content/download/390/2729/file/Liber
ty_ID-WSF_Web_Services_Framework.pdf, 2004
44
ISNET 76
[Koc05]
Michael Koch, Kathrin M. Möslein, Identities Management for
E-Commerce and Collaboration Applications, International Journal of
Electronic Commerce, vol 9, n°3, Spring 2005,
http://www11.informatik.tumuenchen.de/publications/pdf/Koch2004b.pdf.
[LaA03]
Liberty Alliance Project, Introduction to the Liberty Alliance Identity
Architecture,
http://www.projectliberty.org/liberty/content/download/383/2708/file/LAP
%20Identity%20Architecture%20Whitepaper%20Final.pdf, Mars 2003
[LaB03]
Liberty Alliance Project, Business Benefits Of Federated Identity,
http://www.projectliberty.org/liberty/content/download/382/2705/file/LAP
%20Business%20Benefits%20White%20Paper%20v4.pdf, Avril 2003
[LaC03]
Liberty Alliance Project, Business Guidelines : Raising the Business
Requirements for Wide Scale Identity Federation,
http://www.projectliberty.org/liberty/content/download/1366/8739/file/Lib
ertyBusinessGuidelines.pdf, Juillet 2003
[Leh02]
Patrick Lehner, Utilisation d'Internet dans les enterprises romandes, Georg
Editeur SA, Mai 2002, ISBN 2-8257-0789-9
[Lio04]
Yves Lions, La gestion de l'identité en ligne,
http://www.fing.org/servlet/com.univ.collaboratif.utils.LectureFichiergw?ID
_FICHIER=248, 2002
[LPD92]
Loi fédérale sur la protection des données du 19 juin 1992,
http://www.admin.ch/ch/f/rs/235_1, 19 juin 1992.
[Mad05]
Paul Madsen, Liberty ID-WSF People Service – federated social identity,
http://www.projectliberty.org/liberty/content/download/387/2720/file/Liber
ty_Federated_Social_Identity.pdf, 5 décembre 2005
[Min02]
Ministère du budget et de la réforme de l'état, Le projet Liberty Alliance :
pour un standard de l’identité numérique en réseau,
http://www.adae.gouv.fr/article.php3?id_article=78, 12 septembre 2002
[Miy06]
Teruko Miyata & al., A Survey on Identity Management Protocols and
Standards, IEICE Transactions on Information and Systems, vol. E89-D,
n°1, pp. 112-123, http://ietisy.oxfordjournals.org/cgi/content/refs/E89D/1/112, Janvier 2006.
[New04]
PR Newswire, Le livre blanc de la Liberty Alliance examine comment
l'identité fédérée permet de réduire le vol d'identité,
http://www.prnewswire.co.uk/cgi/news/release?id=117641,
23 février 2004
[New05]
PR Newswire, Liberty Alliance lance les Directives commerciales et de
politique pour le déploiement de la gestion de l'identité fédérée,
http://www.prnewswire.co.uk/cgi/news/release?id=155728,
11 octobre 2005
[Nor02]
Eric Norlin, André Durand, Federated Identity Management,
http://www.pingidentity.com, 2002
45
[Ola03]
[PaA04]
ISNET 76
Thor Olavsrud, Liberty Alliance Details Identity Architecture,
http://www.atnewyork.net/news/article.php/2108141, 11 mars 2003
Pat Patterson, Pirasenna Velandai Thiyagarajan, Federated Identity : Access
Control and Single Sign-On,
http://developers.sun.com/prodtech/javatools/jsenterprise/reference/presen
tations/sso_presentation.pdf, 5 octobre 2004
[PaB04]
Pat Patterson, Pirasenna Velandai Thiyagarajan, Marina Sum, Federated
Identity : Single Sign-On Among Enterprises,
http://developers.sun.com/prodtech/identserver/reference/techart/federate
d.html, 14 octobre 2004
[Pag05]
Sophie Page, L'ASP – Une nouvelle solution pour la gestion de
l'informatique en entreprise. Travail de diplôme à la Haute École de
Gestion de Genève, Département Informatique de Gestion,
http://campus.hesge.ch/Daehne/TD/2005/PageSophie1.pdf, Novembre
2005.
[Pap03]
Greg Papadopoulos, Getting It Right – Digital identification and finegrained billing in the Web services world,
http://www.sun.com/aboutsun/media/presskits/projectliberty/getright.html, 2003
[Pass]
Microsoft Passport, http://www.microsoft.com/net/default.asp
[Pfi03]
Birgit Pfitzmann, Michael Waidner, Analysis of Liberty Single-Sign-on with
Enabled Clients, Internet Computing, IEEE, Volume 7, Issue 6,
Novembre-Décembre 2003.
[Rit03]
Albert Ritch, Les Web Services. Travail de diplôme à la Haute École de
Gestion de Genève, Département Informatique de Gestion,
http://campus.hesge.ch/Daehne/TD/2003/RitchAlbert.pdf, Novembre
2003.
[Sal03]
Olivier Salaün, Introduction aux architectures web de Single Sign-On,
http://www.cru.fr/sso/jres-sso, 15 octobre 2003
[Saml]
SAML, http://www.oasis-open.org/committees/security
[Sem02]
Radovan Semancíc, Internet applications security,
http://storm.alert.sk/work/papers/phd-exam-work-november-2002-html,
Novembre 2002
[Sub04]
S. Subenthiran, K. Sandrasegaran, R. Shalak, Requirements for Identity
Management in Next Generation Networks, Advanced Communication
Technology, The 6th International Conference on, Volume 1, pp 138-142,
Septmbre 2004, ISBN-89-5519-119-7.
[Sun02a]
Sun Microsystems®, Developper’s Guide Sun One Application Server 7,
http://docs.sun.com/db/coll/s1_asse_en, 2002.
[Sun02b]
Sun Microsystems®, Federation Management,
http://docs.sun.com/source/816-6687-10/liberty.html, 2 décembre 2002
46
[Sun04]
ISNET 76
Sun Microsystems®, Sun Java System Access Manager – Contrôle d'accès
et services de fédération d'identité standardisés pour les intranets et les
extranets, http://www.janua.fr/doc/SunJavaSystemAccessManager_FR.pdf,
2004
[Sun05]
Sun Microsystems®, Sun Java System Application Server,
http://www.sun.com/software/products/appsrvr, 2005.
[Tas02]
John Taschek, Liberty Alliance or Passeport?,
http://www.eweek.com/print_article/0,3668,a=28521,00.asp, Juin 2002
[Thi05]
Pascal Thiaulier, Benard Roy, La gestion de l'identité et des accès,
http://www.fiq.qc.ca/_site/PHOTOS/QUEBEC/DOCUMENTS/la_gestion_de_i
dentite_architecture.ppt, 2005
[Van03]
Michelle Vance, Tiffany Van Gorder, Liberty Alliance Releases New
Specifications, Privacy and Security Guidelines to Drive Development of
Identity-Based Web Services,
http://www.projectliberty.org/liberty/news_events/press_releases/liberty_all
iance_releases_new_specifications_privacy_and_security_guidelines_to_dri
ve_development_of_identity_based_web_services, Avril 2003
[Var03]
[Var05]
Christine Varney, Privacy and Security Best Practices,
http://www.projectliberty.org/liberty/content/download/374/2681/file/final
_privacy_security_best_practices.pdf, 12 novembre 2003
Christine Varney, Victoria Sheckler, Deployment Guidelines for Policy
Decision Makers,
http://www.projectliberty.org/liberty/content/download/373/2678/file/depl
oyment_guidelines_v2_9.pdf, 21 septembre 2005
[Vis05]
Visual Studio .NET,
http://www.microsoft.com/france/vstudio/default.mspx, 2005.
[Was05]
Thomas Wason, IEEE-ISTO, Liberty ID-FF Architecture Overview, V1.2,
http://www.projectliberty.org/liberty/content/download/318/2366/file/draft
-liberty-idff-arch-overview-1.2-errata-v1.0.pdf , 2005
[Wss]
WS-Security, http://www.oasis-open.org/committees/wss
[Xml02]
OMG – XML Metadata Interchange Specification version 2.0.
http://www.omg.org/technology/documents/formal/xmi.htm, 2 mai 2002.
[Xpa99]
XML Path Language version 1.0. http://www.w3.org/TR/xpath,
16 novembre 1999.
47
HEG – Genève
Laboratoire de Technologies Objet
Campus de Battelle – Bâtiment F
Route de Drize 7
CH-1227 Genève
Tél : +41 22 388 17 00
Fax : +41 22 388 17 01
www.hesge.ch/heg
IDENTITÉ DIGITALE FÉDÉRÉE
ANNEXES
Projet déposé dans le cadre du programme de la réserve stratégique de la HES-SO
Novembre 2006
Sous la direction de Peter DAEHNE, professeur HES
http://campus.hesge.ch/Daehne/ISNet76
ISNET 76
ANNEXE A
Configuration pour sample1
Sur la base du document d’installation du sample1 de Sun.
HEG926 : SP1
SERVER_PROTO : http
SERVER_HOST : heg926.ge-em.ad.etat-ge.ch
SERVER_PORT : 46407
SERVICE_DEPLOY_URI : amserver
META_ALIAS : heg926.ge-em.ad.etat-ge.ch
Root suffix : dc=ge-em,dc=ad,dc=etat-ge,dc=ch
Utilisateur à créer sur le serveur : sp1User / ploufman
HEG931 : IDP1
SERVER_PROTO : http
SERVER_HOST : heg931.ge-em.ad.etat-ge.ch
SERVER_PORT : 19709
SERVICE_DEPLOY_URI : amserver
META_ALIAS : heg931.ge-em.ad.etat-ge.ch
Root suffix : dc=ge-em,dc=ad,dc=etat-ge,dc=ch
Utilisateur à créer sur le serveur : sp1User / ploufman
Répertoires
Sun Access Manager :
D:\Sun\AccessManager
Sun Web Server :
D:\Sun\WebServer
Répertoire du serveur virtuel dans Sun Web Server :
D:\Sun\WebServer\https-<hostname>
Autres configurations
Les deux machines se trouvant sur le même DNS, il faut modifier le nom du cookie
qu’elles utilisent pour éviter qu’ils ne s’écrasent mutuellement sur le browser (voir les
notes d’installation).
1
ISNET 76
Notes sur Access Manager
Démarrer les services
pour démarrer le serveur web, il faut d’abord fermer IIS : dans les services windows,
il faut arrêter Service de publication World Wide Web. Ensuite on peut démarrer
Web Server (https-<hostname>)
Configuration des serveurs
la configuration des serveurs virtuels se trouve dans :
D:\Sun\WebServer\https-<hostname>\config
Le fichier server.xml indique notamment le port que le listener de Web Server
écoute :
<LS id="ls1" port="19709" servername="HEG931.ge-em.ad.etatge.ch" defaultvs="https-HEG931.ge-em.ad.etat-ge.ch" ip="any"
security="false" acceptorthreads="1" blocking="false"/>
Si Access Manager est installé sur Web Server, c’est donc également sur ce port qu’il
est accessible.
On trouve aussi dans ce fichier la liste des applications web déployées.
Admin du serveur web
pour accéder à l’administration du serveur web, il faut démarrer le service
correspondant : Démarrer\Sun Microsystems\Web Server\Start Web
Server Administration Server ou aller dans les services Windows et
démarrer Web Server Administration Server.
On y accède ensuite avec l’url du serveur web mais sur le port 8888
Supprimer le password admin du serveur web
pour supprimer le mot de passe admin pour Web Server Administration :
Dans le fichier D:\Sun\WebServer\https-admserv\config\admpw, le mot de passe est
écrit sous la forme login:password
Il faut supprimer le mot de passe après le login, et se logger en admin sans mot de
passe.
2
ISNET 76
Pages de login AM
pour modifier l’aspect des pages de login d’Access Manager, il faut éditer les fichiers
dans
D:\Sun\WebServer\https-HEG931.ge-em.ad.etat-ge.ch\is-webapps\services\config\auth
(Supposition : à la création du serveur virtuel https-HEG931.ge-em.ad.etat-ge.ch, les
fichiers contenus dans D:\Sun\AccessManager\web-src sont copiés dans
D:\Sun\WebServer\https-HEG931.ge-em.ad.etat-ge.ch\is-web-apps).
Admin AM
pour accéder à l’interface de gestion d’Access Manager, il faut aller sur le serveur
web dans le répertoire amconsole, par exemple : http://heg931.ge-em.ad.etatge.ch:19709/amconsole
Créer un utilisateur
Dans la console d’administration (ex : http://heg931.ge-em.ad.etatge.ch:19709/amconsole), aller dans l’onglet Gestion des Identités, puis afficher
Utilisateurs, cliquer sur Nouveau… et remplir les champs obligatoires.
Déployer une application web
Il y a deux manières de déployer une application web :
1) avec la commande wdeploy, en suivant les instructions du guide d’installation.
uri_path : /sp1
instance : heg926.ge-em.ad.etat-ge.ch
vs_id : https-HEG926.ge-em.ad.etat-ge.ch (Attention: sensible à la casse)
-d directory : ignoré
2) depuis l’interface d’administration du serveur web Sun. Il faut pour cela démarrer
le serveur d’administration (dans les services windows), puis ouvrir la console web de
la machine sur le port 8888 (ex : http://heg931.ge-em.ad.etat-ge.ch:8888) et
se logger avec les login choisi à l’installation.
Sur la page principale, choisir le serveur et cliquer sur manage, puis aller à l’onglet
virtual server class. Choisir la classe et cliquer sur manage, puis choisir le serveur
virtuel et cliquer sur manage. Dans l’onglet Web applications, choisir le menu Deploy
Web Application (à gauche), sélectionner le fichier war et choisir l’URI (par exemple
"/sp1"), puis valider.
Serveurs IDP et SP sur le même domaine
Si les serveurs d’identification (IDP) et du fournisseur de service (SP) sont sur le même
domaine (ex : heg931.ge-em.ad.etat-ge.ch et heg926.ge-em.ad.etat-ge.ch sont tous
les deux dans le domaine ge-em.ad.etat-ge.ch), les cookies se trouvent dans la même
3
ISNET 76
entrée sur le browser et par conséquent, ils s’écrasent mutuellement. Ceci provoque
un échec dans la fédération (l’utilisateur n’arrive jamais sur la page Federation Done).
Pour éviter cela, il faut renommer les cookies utilisés par les serveurs pour que
chacun porte un nom différent. Par défaut, le cookie est nommé iPlanetDirectoryPro.
Il faut éditer le fichier AMConfig.properties qui se trouve dans le sous-répertoire
config du répertoire d’installation d’Access Manager. Il suffit ensuite de modifier la
propriété com.iplanet.am.cookie.name pour que les cookies de chaque serveur
soient nommés différemment (ex : com.iplanet.am.cookie.name=IDP1Cookie sur le
serveur IDP1 et com.iplanet.am.cookie.name=SP1Cookie sur le serveur SP1)
Pour créer une organisation / sous-organisation
Aller dans la console d’administration, onglet gestion des identités. En haut du menu
de gauche est inscrit l’organisation courante (ex : ge-em). On peut voir les
informations relatives à cette organisation avec la liste déroulante Afficher. En
choisissant Organisations et Nouveau…, on peut créer une sous-organisation.
Ensuite, en cliquant sur cette sous-organisation (sur lien hypertexte, pas sur la flèche
à droite), on entre dans la sous-organisation, comme l’indique l’indication en haut du
menu de gauche (ex : ge-em > subOrg).
4
Annexe B : ISNet76
HEVs
Active Directory Federation Services (ADFS).................................................. 4
Système requis ...................................................................................................................... 4
Scénarios ............................................................................................................................... 4
B2B: ADFS Federated Web SSO....................................................................................... 4
B2E: ADFS Extranet Web SSO ......................................................................................... 5
B2C : ADFS « Online » Web SSO .................................................................................... 5
Extensions/interopérabilités ................................................................................................ 6
Token-based and Claims-aware applications .................................................................... 6
Lab (Scénario B2B) .............................................................................................................. 7
AD configuration................................................................................................................ 8
ADFS Configuration .......................................................................................................... 8
Création d’une application claims-aware ........................................................................... 9
Troubleshooting ............................................................................................................... 10
Url du site ......................................................................................................................... 10
Scénario B2C ...................................................................................................................... 11
ADFS configuration ......................................................................................................... 11
Url du site ......................................................................................................................... 11
Erreur................................................................................................................................ 11
Intégration du scénario avec Authorization Manager.................................................... 12
Fonctionnalités de l’application ....................................................................................... 12
Configuration de l’Active Directory et Active Directory Federation Services................ 12
Configuration de l’Authorization Manager...................................................................... 12
Configuration de l’application (web.config) .................................................................... 14
Code behind...................................................................................................................... 14
Limitations ....................................................................................................................... 16
Erreurs .............................................................................................................................. 17
URL du site ...................................................................................................................... 17
Application Token-Based – Exemple SharePoint ........................................................... 17
AD Configuration............................................................................................................. 17
SharePoint Configuration................................................................................................. 18
ADFS Configuration ........................................................................................................ 18
Url du site ......................................................................................................................... 18
Sources................................................................................................................................. 18
MIIS .................................................................................................................... 19
Versions............................................................................................................................ 19
Compatibilité.................................................................................................................... 19
Système requis: ................................................................................................................ 20
Password Management..................................................................................................... 20
Bon à savoir:..................................................................................................................... 21
Sources: ............................................................................................................................ 21
Centrify DirectControl ..................................................................................... 21
Composants DirectControl................................................................................................ 22
Téléchargement de Centrify DirectControl ..................................................................... 23
1
Installation du module ....................................................................................................... 24
Configuration de Tomcat pour l’authentification avec Centrify DC ............................... 24
Installation de l’exemple « ADFS-claims-aware » .......................................................... 24
Configuration du server d’application pour SSL ............................................................. 25
Déclaration de l’application au niveau du serveur ADFS................................................ 25
Tester l’application........................................................................................................... 26
Développez l’application claims-aware ............................................................................ 26
Rôles Tomcat.................................................................................................................... 26
IfUserInRole tag............................................................................................................... 26
Source............................................................................................................................... 26
Problème de certificats....................................................................................................... 27
Source .................................................................................................................................. 28
Liberty Alliance ................................................................................................. 28
Concepts clés....................................................................................................................... 29
Fédération – SSO initiation ............................................................................................... 29
Implémentations libres ...................................................................................................... 30
Membres actuels................................................................................................................. 30
Liberty Alliance Interoperability...................................................................................... 30
PingFederate..................................................................................................................... 30
SymLabs........................................................................................................................... 31
Sun.................................................................................................................................... 31
IBM .................................................................................................................................. 31
Oracle ............................................................................................................................... 32
Novell ............................................................................................................................... 32
Liste complète .................................................................................................................. 32
Sources................................................................................................................................. 32
PingFederate ...................................................................................................... 33
Overview ............................................................................................................................. 33
Nature du produit ............................................................................................................. 33
Description du produit...................................................................................................... 33
Concepts clés.................................................................................................................... 35
Adapters et Agent toolkit ................................................................................................. 37
Interopérabilités................................................................................................................ 37
Installation du serveur ....................................................................................................... 38
Déploiement des scénarios (SAML 2.0)............................................................................ 38
Paramètres locaux ............................................................................................................ 39
Configuration de l’IDAdapter .......................................................................................... 40
Configuration du SP Adapter ........................................................................................... 41
Connexion au SP .............................................................................................................. 42
Connexion à l’IdP............................................................................................................. 44
Test du scénario IdP-Initiated .......................................................................................... 45
Test du scénario SP-Initiated............................................................................................ 46
Personnalisation de l’application en fonction de l’utilisateur........................................ 47
Ajout d’un attribut............................................................................................................ 47
Configuration du SpAdapter pour l’ajout d’un attribut.................................................... 48
Configuration de l’IdPAdapter pour l’ajout d’un attribut ................................................ 49
Modification de l’application ........................................................................................... 49
Intégration avec l’ADFS (SP connexion) ......................................................................... 50
2
LDAP IdPAdapter Configuration..................................................................................... 50
LDAP Data Store Configuration ...................................................................................... 51
ADFS account partner...................................................................................................... 51
ADFS SP Connexion........................................................................................................ 52
Test de l’application ......................................................................................................... 53
Erreur................................................................................................................................ 56
Intégration avec l’ADFS (IdP connexion)........................................................................ 56
ADFS resource partner..................................................................................................... 56
ADFS IdP Connexion....................................................................................................... 57
Test de l’application ......................................................................................................... 58
Erreur................................................................................................................................ 59
Sources................................................................................................................................. 60
SourceID............................................................................................................. 61
Installation du framework et des exemples...................................................................... 61
Test de l’application ........................................................................................................... 61
Interopérabilité................................................................................................................... 63
Erreurs ................................................................................................................................ 63
Org.Mentalis.Security ...................................................................................................... 63
System.Security.dll........................................................................................................... 63
Autres projets d’identité fédérée ..................................................................... 63
Shibboleth ........................................................................................................................... 63
Source............................................................................................................................... 63
Liberty Alliance, Shibboleth et Lemonldap..................................................................... 64
Source............................................................................................................................... 64
http://fr.wikipedia.org/wiki/Authentification_unique ...................................................... 64
Microsoft Passport ............................................................................................................. 64
Standards identités fédérées.............................................................................................. 64
Tableau des principaux projets d’identités fédérées ........................................................ 64
Evolution des standards.................................................................................................... 65
Tableau de comparaison .Net Passport, Ping ID et Shibboleth........................................ 65
FAQ..................................................................................................................... 66
Existe-il un méta-annuaire unique pour une fédération ? ................................................ 66
L’interopérabilité entre les protocoles Liberty Alliance et ADFS est-elle possible ?...... 67
ADFS ou Liberty Alliance ?............................................................................................. 67
Sources................................................................................................................ 67
3
Active Directory Federation Services (ADFS)
ADFS est un composant de Windows Server 2003 R2. Il fournit la technologie SSO (Single
Sign-On) pour des applications Web dans des scénarios extranet tels que B2C, B2B ou interne
à une compagnie (multi-forest) dans un environnement Windows.
ADFS utilise les spécifications WS-Federation. Cependant, il fournit en extension une
architecture supportant les assertions SAML et l’authentification via Kerberos.
Système requis
Windows Server 2003 R2
Internet Information Services (IIS) version 6.0
Microsoft ASP.NET 2.0
Microsoft .NET Framework 2.0
Le site Web IIS par défaut configuré avec TLS (Transport Layer Security) ou SSL (Secure
Sockets Layer), utilisé par Microsoft IT pour sa solution. ADFS est installé dans le site Web
par défaut sur le serveur IIS.
Un certificat pour le service de fédération. Microsoft IT utilise le même certificat X.509 pour
la signature des jetons et pour l'authentification SSL auprès des sites Web.
Scénarios
B2B: ADFS Federated Web SSO
Dans ce scenario, l’utilisateur d’une compagnie partenaire n’a pas besoin d’un compte à
l’intérieur de l’Active Directory du domaine dans lequel se trouve la ressource qu’il veut
utiliser. Il se connecte en local, initialise sa connexion SSO et peut accéder à la ressource du
domaine partenaire grâce à la Federation Trust entre les deux serveurs de fédération : le
serveur de fédération account auprès duquel s’authentifie l’utilisateur et le serveur de
fédération resource qui le met en lien avec l’application Web qui tourne sur le serveur Web du
domaine.
[projectDirectory]/ADFS/ADFS_ITForum.ppt
4
B2E: ADFS Extranet Web SSO
Tous les employés d’une compagnie ont un compte dans l’Active Directory. Ils peuvent se
connecter soit en intranet (Windows Desktop logon) soit à partir d’une application Web
(Forms-based logon).
A noter la nécessité d’utiliser un serveur de fédération proxy qui va faire le lien avec le
serveur de fédération account, afin de permettre à l’utilisateur venant de l’internet de
s’authentifier dans son domaine (Active Directory du domaine, son « royaume »)
B2C : ADFS « Online » Web SSO
Dans ce cas là, les utilisateurs internet sont des clients et ont leur compte dans la DMZ. Ils
utilisent un login internet (Form-based login).
5
Extensions/interopérabilités
ADFS a été conçu pour tourner dans un environnement Windows, selon les scenarios décrits
précédemment. Il gère deux types d’applications (ressources) aux mécanismes différents,
Token-based et Claims-Aware, tournant sur le serveur Web IIS (langage .Net).
Cependant, il existe des extensions ou toolkits pour étendre l’ADFS à d’autres plateformes,
tels que :
a. Centrify
b. SourceID
L’interopérabilité entre ADFS et des plateformes autres que Windows peut se faire à l’aide
des serveurs de fédération résultants des projets Liberty Alliance et Shibboleth, basés sur les
spécifications SAML, mais intégrant également les fédérations basées sur WS-federation.
a. Pingfederate (SourceID)
b. Shibboleth
Token-based and Claims-aware applications
Claims-Aware applications:
Les “Claims” sont des déclarations (par exemple: name, identity, key, group, privilege, ou
capability) faites sur les utilisateurs et comprises par les deux partenaires dans l’ADFS. Elles
sont utilisées pour des buts d’autorisation dans une application. Ces claims se baladent à
travers le service de fédération entre les serveurs de fédérations et entre les serveurs de
fédération ressource et la ressource.
Une application claims-aware accepte les claims envoyés par le service de Fédération.
Lien :
http://technet2.microsoft.com/WindowsServer/en/Library/050392bc-c8f5-48b3-b30ebf310399ff5d1033.mspx?mfr=true
Sitemap :
Welcome to the Windows Server TechCenter > Windows Server TechCenter > Windows Server 2003 Technical
Library > Windows Server 2003: Product Help > R2: Product Help (R2 only) > Active Directory Federation
Services (ADFS) > ADFS Concepts > Understanding ADFS Authentication and Authorization > Understanding
Claims
Et :
Services (ADFS) > ADFS Concepts > Understanding ADFS Authentication and Authorization > Controlling
Access to Web-based Applications > Claims-aware applications
Token-Based applications:
Une application Token-based est une application IIS (sharepoint par exemple) qui utilise les
mécanismes d’autorisation « natifs » de Windows. Ces applications ne sont pas préparées
pour utiliser les claims. Elles ne peuvent être utilisées que par des utilisateurs du royaume
local ou d’un royaume de confiance (trusted realm).
Pour plus d’informations, suivez le lien :
Sitemap:
Services (ADFS) > ADFS Concepts > Understanding ADFS Authentication and Authorization > Controlling
Access to Web-based Applications > Windows NT token-based applications
6
Lab (Scénario B2B)
L’architecture mise en place se présente sous la forme suivante:
[projectDirectory]/ADFS/ADFS_Step-by-Step_Guide.doc
J’ai donc configuré quatre machines virtuelles :
- serveur de fédération resource (domaine treyresearch.net)
- serveur de fédération account (domaine adatum.com)
- serveur Web (domaine treyresearch.net) où se trouve la resource
- poste client (domaine adatum.com) d’où un utilisateur du domaine local veut
accéder à la ressource du domaine partenaire.
Machine virtuelle
Computer use
Computer name
Adresse IP
Passerelle
DNS
Alternate DNS
Composants
Windows
Active Directory
DNS server
Domain
NetBios Name
Softwares
Others
W2003 Enterprise
Edition adfsresource
Federation Server
adfsresource
192.168.73.141
192.168.73.2
192.168.73.141
W2003 Enterprise
Edition adfsaccount
Federation Server
adfsaccount
192.168.73.142
192.168.73.2
192.168.73.142
W2003 Standard
Edition adfsclient
Poste Client
adfsclient
192.168.73.137
192.168.73.2
192.168.73.141
192.168.73.142
Application server (IIS) Application server (IIS)
Federation service
Federation service
yes
yes
no
yes
yes
no
treyresearch.net
adatum.com
adatum.com
treyresearch
adatum
IIS Resource kit 6.0
SQL Server 2000
SQL Server 2000
enterprise edition sp 4 enterprise edition sp 4
MIIS
MIIS
PingFederate
Java SDK 1.5/Apache
SSL Certificate
SSL Certificate
generated
generated
Set
Set
AdfsAppPoolIdentity
AdfsAppPoolIdentity
(both fed server and domain controller on the same computer)
W2003 Standard
Edition adfsweb
Web server
adfsweb
192.168.73.143
192.168.73.2
192.168.73.141
Application server (IIS)
ADFS web agents
no
no
treyresearch.net
SQL Server Express
2005
Windows sharepoints
services
SSL Certificate
generated
Stepbystep website
Se référer au document « ADFS_Stepbystep.doc » pour les étapes de l’installation.
7
AD configuration
Le but était de créer deux utilisateurs dans l’Active Directory de leur domaine, pouvant
accéder à une petite application Web du domaine partenaire, mais avec des rôles différents.
Concrètement, l’utilisateur adminis se connecte en local sur son domaine, initie le Web SSO
et accède à l’application Web du domaine partenaire avec les droits administrateur. Le
cheminement est le même pour l’autre utilisateur, mise à part qu’il n’a pas les droits pour
accéder à l’administration de l’application Web.
Dans l’Active Directory du domaine adatum.com, création des utilisateurs et des groupes
d’utilisateurs :
Création
Security global group
User
Nom
TreyClaimAppAdmins
TreyClaimAppUsers
Admin Hister
User
Alan Shen
User
Admin Hister
Alan Shen
User name
Not applicable
Not applicable
Adminis
(adminis va pouvoir accéder
à l’application Claims-aware
avec le rôle administrateur)
Alansh
(alansh va accéder à
l’application Claims-aware
avec le rôle guests)
Add as a member of:
TreyClaimAppAdmins
TreyClaimAppUsers
ADFS Configuration
Le principe est le suivant : on crée des « Organization claims » de type groupe du côté
« account » du service de fédération qui sont liés à des groupes d’utilisateurs de l’Active
Directory. A partir des ces « Organization claims », des « Outgoing claims » sont envoyés à
travers la fédération. Du côté « resource », ils sont réceptionnés en tant que « Incoming
claims » et transformés en « Organization claims ». Chaque « claims » requis par l’application
sont activés, afin qu’elle puisse les recevoir :
Federated
Account
Resource
type
Claim
Namespace
Active
Account
(incoming/
Resource
Enabled
Directory
Organization
outgoing)
Organization
in
Claims
App
Adatum ClaimApp Claim
Oui
Adatum ClaimApp
Oui
Claims
TreyClaimsAppUsers
Trey ClaimApp Claim
ClaimAppMappi
Group
ng
TreyClaimsAppAdmin
Trey Claim App
s
Admin
ClaimAppAdmin
Admin
8
Schéma du flux des claims à travers la fédération :
Création d’une application claims-aware
Il reste à construire une application Web en .Net qui réceptionne et utilise les claims. Dans
mon exemple, j’attribue les rôles aux utilisateurs en fonction de leur « Organization claims ».
J’ai d’abord créé une petite application avec login qui gère des utilisateurs et des rôles
enregistrés dans une base de données SQL (ASPNETDB.mdf). Cette application accepte deux
rôles : Administrators et Guests. L’utilisateur auquel est attribué le rôle Administrators a
accès aux pages d’administration, les autres non. Si un utilisateur de la fédération a pour
claims l’ « Organization claims » « Adatum ClaimApp Admin », alors il se voit attribuer le
rôle Administrators, autrement il a le rôle « Guests ».
Pour créer une application qui accepte les claims, voir le fichier Web.config de l’application.
Dans le fichier de code behind, j’ai utilisé le code suivant :
using System.Web.Security.SingleSignOn;
using System.Web.Security.SingleSignOn.Authorization;
…
protected void Page_Load(object sender, EventArgs e)
{
SingleSignOnIdentity ssoId = User.Identity as SingleSignOnIdentity;
…
SecurityPropertyCollection spc = ssoId.SecurityPropertyCollection;
SecurityProperty sp = spc[1];
…
if (sp.Value.Equals("Adatum ClaimApp Admin"))
{
…
Roles.AddUserToRole(name, "Administrators");
…
}
…
}
9
Pour gérer les droits utilisateurs de manière plus précise et plus personnalisée, il y a la
possibilité d’utiliser AzMan (Authorization Manager).
Le login (basé sur ASP.NET Role Manager) ne fonctionne pas avec les claims. Impossible de
se loguer.
Troubleshooting
En cas de problème de fonctionnement du service de Fédération, le lien suivant permet de
mettre en place l’environnement permettant le Débogage et d’établir un diagnostic des pannes
de l’ADFS :
http://technet2.microsoft.com/WindowsServer/en/Library/ed76b687-7585-421d-ad4147c21499de001033.mspx?mfr=true
Sitemap:
Library > Windows Server 2003: Operations > R2: Operations (R2 only) > ADFS Operations Guide >
Troubleshooting Active Directory Federation Services
Erreur
Si éventuellement cette erreur survient et qu’en apparence tout est bien paramétré, remplacé
dans la configuration des serveurs de fédération l’adresse DNS par l’adresse IP du serveur.
Url du site
http://adfsweb.treyresearch.net:8081/claimapp/
10
Scénario B2C
Le scénario B2C consiste à créer une application Web permettant à un utilisateur internet
(mais qui possède un compte dans l’Active Directory) de se connecter à l’Active Directory,
afin d’accéder à la ressource du domaine.
Comme les machines virtuelles ont des adresses IP privées, je dois installer l’application Web
d’authentification à Active Directory sur le même domaine que l’application claims-aware.
En cas de succès de l’authentification, l’application redirige l’utilisateur sur l’application
claims-aware pour l’initialisation du SSO.
Pour plus d’informations sur la manière d’utiliser les formulaires d’authentification à l’Active
Directory en ASP.NET 2.0 consultez les sites :
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnpag2/html/paght000026.asp
Et
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnpag2/html/paght000021.asp
De même que les fichiers sources du site « formsADAuth ».
ADFS configuration
Il faut créer un claim pour un utilisateur du domaine treyresearch.net. Prenons l’exemple de
l’utilisateur Terry Adams (terrya) créé dans l’Active Directory du domaine treyresearch.net
sous Users.
J’ai créé un nouvel « Organization Claim » Trey ClaimApp External (Facultatif, car
l’utilisateur Terry Adams peut être mappé à un « Organization Claim » déjà existant. Ensuite,
j’ai mappé (populate) l’utilisateur depuis l’Active Directory au groupe (« Organization
Claim ») (« Group Claim Extraction »). Finalement, j’ai activé le groupe pour l’application
claims-aware.
Url du site
http://adfsweb.treyresearch.net:8080/b2c
Erreur
Impossible de se connecter à l’annuaire LDAP du domaine Adatum.com ("Unable to establish
secure connection with the server"). Nécessite probablement l’installation d’un proxy.
11
Intégration du scénario avec Authorization Manager
L’Authorization Manager (AzMan) est une nouvelle fonctionnalité de Windows Server 2003
qui permet à l’aide d’un « snap-in mmc » (azman.msc) d’implémenter l’administration d’une
application basé sur les rôles. Et comme la sécurité sur le framework .Net met essentiellement
l’accent sur les rôles…
Dans AzMan, on définit les autorisations pour une application pour un utilisateur de l’Active
Directory. Comme les rôles liés à un utilisateur peuvent contenir des tâches, qui peuvent
contenir des opérations, on peut définir de manière plus précise (affiner) et mieux structurée
les autorisations pour chaque utilisateur.
Plus d’infos à l’adresse (Concepts + création d’un nouveau magasin):
http://www.windowsecurity.com/articles/Authorization_Manager_Role_Based_Administratio
n_Windows_Server_2003_Part1.html
Fonctionnalités de l’application
J’ai une application Web qui accède à la base de données Northwind et affiche les tables
Customer et Order dans un Gridview.
Les données comprises dans la table Customer peuvent être effacées ou mise à jour à partir du
Gridview.
Il est possible d’ajouter un nouveau client ou une nouvelle commande. Un lien hypertexte
renvoie sur une page de l’administration (dossier admin accessible uniquement avec le rôle
ASPNET Administrator), qui permet l’insertion via un FormView.
Chaque fonctionnalité de l’application correspond à une opération définie dans AzMan. Selon
les rôles affectés à l’utilisateur, il pourra accéder à l’une ou l’autre des fonctionnalités. Les
rôles AzMan définissent les fonctionnalités accessibles à un utilisateur (propriétés « enabled »
ou « visible » des contrôles), mais ils doivent aussi correspondre aux rôles ASPNET qui
définissent l’accès aux dossiers et aux fichiers.
Ainsi, l’utilisateur MrS contenu dans le rôle Manager de AzMan, doit aussi, d’après son rôle
AzMan être ajouté au rôle Administrator de ASPNET. Le rôle AzMan permet à cet utilisateur
d’activer l’hyperlien qui pointe sur la page d’ajout d’un nouveau client et le rôle ASPNET
donne les droits d’accès à cette page ou au dossier dans laquelle elle se trouve.
Configuration de l’Active Directory et Active Directory Federation Services
Il faut créer les utilisateurs qui vont pouvoir accéder à l’application. Tous les utilisateurs
proviennent du domaine treyresearch.net. Les domaines étant privés, AzMan n’arrive pas à
accéder à l’annuaire LDAP du domaine adatum.com.
Utilisateurs créés : terrya, mrs, azbak. Les deux premiers existent déjà et sont configurés dans
l’ADFS. Par contre l’utilisateur Azman Rbac doit figurer dans l’ADFS pour la création du
claim lisible par l’application. Simplement, dans le magasin Active Directory de l’ADFS, au
niveau du groupe d’extraction des claims (*, Trey ClaimApp External), rajouter l’utilisateur
azbak.
Configuration de l’Authorization Manager
Pour créer un nouveau magasin, une nouvelle application et pour des détails sur les concepts
et les objets se trouvant dans AzMan, se référer aux liens « Création d’un magasin AzMan »
et « Définition des rôles AzMan » de la section source.
Voici à quoi ressemble ma configuration AzMan. A noter le nom de l’application (très
important) : claimsaware :
12
Dans le dossier Groups du magasin, j’ai créé un groupe admins avec l’utilisateur mrs.
J’ai ensuite défini les opérations suivantes :
ID Opération
Nom Opération
Description Opération
1
Select Customers
Active l’affichage du GridView des clients
2
Add Customer
Active la fonctionnalité d’ajout d’un nouveau client
3
Delete Customer
Active le bouton Delete du GridView des clients
4
Update Customer
Active le bouton Edit du GridView des clients
5
Create Customer
Active la fonctionnalité d’ajout d’une commande
6
Select Orders
Active l’affichage du GridView des commandes
Puis les tâches suivantes :
ID Tâche
Nom Tâche
Description Tâche
Contient opérations/tâches
1
Display Customer
Active l’affichage des GridView
op:1, op:6
2
Modify Customer
Active la gestion des données des grilles
op:2, op:3, op:4, tâche:1
Et enfin les rôles suivants :
Nom Rôle
Description Rôle
Contient rôle/tâches/opérations
Reader
Peut lire les données
tâche:1
Manager
Gère les données
rôle:1, tâche:2, op:5
Ensuite, reste à assigner les utilisateurs aux rôles :
Nom Rôle
Assignement utilisateurs
Reader
[email protected]
Manager
[email protected] (groupe admins)
Restricted (facultatif)
[email protected]
La
création
des
tâches
n’est
pas
très
utile,
car
la
référence
« Microsoft.Interop.Security.AzRoles.dll » en .Net ne permet pas d’accéder aux tâches, mais
uniquement aux opérations en fonction de leurs identifiants.
13
Configuration de l’application (web.config)
Il faut tout d’abord rajouter à la section <ConnectionStrings>, la connexion à la base de
données (utilisation de SQL Express Server 2005) et la connexion à l’annuaire LDAP.
<connectionStrings>
<add name="NorthwindConnectionString" connectionString="Data
Source=adfsweb\SQLExpress;integrated security=true;attachdbfilename=C:\SQL Server 2000 Sample
Databases\NORTHWND.MDF;user instance=true;"
providerName="System.Data.SqlClient" />
<add name="LocalPolicyStore"
connectionString="msldap://adfsresource.treyresearch.net/CN=App,DC=treyresearch,DC=net" />
</connectionStrings>
Dans la section <roleManager>, il faut ajouter le roleManager d’AzMan :
<roleManager
enabled="true"
cacheRolesInCookie="true"
defaultProvider="AspNetSqlRoleProvider"
cookieName=".ASPXROLES"
cookiePath="/"
cookieTimeout="30"
cookieRequireSSL="true"
cookieSlidingExpiration="true"
createPersistentCookie="false"
cookieProtection="All">
<providers>
<add name="RoleManagerAzManProvider"
type="System.Web.Security.AuthorizationStoreRoleProvider, System.Web, Version=2.0.0.0,
Culture=neutral, publicKeyToken=b03f5f7f11d50a3a"
connectionStringName="LocalPolicyStore"
applicationName="claimsaware"/>
</providers>
</roleManager>
Le provider par défaut est le roleManager AspNet (défini dans machine.config). Si l’on met le
roleManager d’AzMan comme provider par défaut, alors les rôles utilisés seront ceux
d’AzMan. Par exemple, le code suivant :
if (!User.IsInRole(role))
Roles.AddUserToRole(name, role);
Si le provider par défaut est AzMan: le test se fait sur les rôles AzMan et le code
« Roles.AddUserToRole » génère une exception. Il ne semblerait pas que l’on puisse
administrer AzMan avec du code .Net (ce qui paraît logique pour des questions de sécurité).
De plus, je n’ai pas trouvé le moyen de gérer les droits d’accès aux dossiers ou fichiers de
l’application Web avec des donc rôles AzMan, pas d’accès à la partie administration.
Si le provider par défaut est ASPNET : le test se fait sur les rôles ASPNET et le code cidessus permet de transférer le rôle AzMan en rôle ASPNET. Ainsi, si un utilisateur à le rôle
Manager sous AzMan, il obtiendra le rôle Administrator sous ASPNET, lui donnant ainsi
accès à la partie admin.
Code behind
La première chose à faire est d’importer la référence
« Microsoft.Interop.Security.AzRoles.dll ». Elle se trouve dans l’onglet « COM » sous le nom
de « AzRole 1.0 » (je ne sais pas le nom exact) si l’on travaille sur Windows Server 2003.
14
Sinon, il faut télécharger le runtime « Windows 2000 Server Authorization Manager
Runtime » à l’adresse
http://www.microsoft.com/downloads/details.aspx?FamilyID=7edde11f-bcea-4773-a29284525f23baf7&DisplayLang=fr
Après exécution du setup, la dll se trouve dans le répertoire
« [installation _directory]\Windows(R) 2000 Authorization Manager Runtime\PIA \1.2\»
using Microsoft.Interop.Security.AzRoles;
Le code pour se connecter à AzMan, initialiser un magasin et ouvrir l’application
« claimsaware » est le suivant :
AzAuthorizationStoreClass AzManStore = new AzAuthorizationStoreClass();
AzManStore.Initialize(0, ConfigurationManager.ConnectionStrings
["LocalPolicyStore"].ConnectionString, null);
IAzApplication azApp = AzManStore.OpenApplication("claimsaware", null);
Création du contexte client
IPrincipal userPrincipal = HttpContext.Current.User;
WindowsIdentity userIdentity = userPrincipal.Identity as WindowsIdentity;
clientContext = azApp.InitializeClientContextFromName(name, sp.Value, null);
où
SingleSignOnIdentity ssoId = User.Identity as SingleSignOnIdentity;
name = HttpContext.Current.User.Identity.Name.ToString();
SecurityPropertyCollection spc = ssoId.SecurityPropertyCollection;
SecurityProperty sp = spc[1];
On récupère ensuite tous les rôles ASPNET de l’utilisateur et on les efface. Cette
réinitialisation est nécessaire, au cas où on aurait changé le rôle d’un utilisateur dans AzMan.
Les rôles ASPNET doivent correspondre aux rôles AzMan tels qu’il sont définis au moment
de lancer l’application.
String[] myRoles = Roles.GetRolesForUser();
Roles.RemoveUserFromRoles(name, myRoles);
Ensuite, pour chaque rôle AzMan attribué à l’utilisateur courant, on va générer le rôle
ASPNET correspondant.
Array data = (Array)clientContext.GetRoles(null);
foreach (string Role in data)
{
if (Role == "Manager")
goGetRole("Administrators");
if (Role == "Reader")
goGetRole("Guests");
if (Role == "Restricted")
Label2.Text += "restricted access: no role obtained";
}
protected void goGetRole(String role)
{
if (!User.IsInRole(role))
{
Roles.AddUserToRole(name, role);
}
Label2.Text += role;
}
15
Cette façon de faire n’est pas dynamique et l’ajout d’un rôle AzMan peut entraîner l’ajout
d’un rôle ASPNET, ce qui dans le code ci-dessus implique que l’on doive rajouter une ligne.
Pour éviter cette situation, le mieux est de créer des rôles AzMan et ASPNET avec des noms
identiques, évitant ainsi les tests :
foreach (string Role in data)
goGetRole(Role);
Pour créer un rôle ASPNET dynamique, utiliser le contrôle « CreateUserWizard”.
Pour activer les fonctionnalités liées à un utilisateur, on va tester pour chaque opération si
l’utilisateur peut accéder à cette opération. Si oui, fonctionnalité activée.
if (op_validation(1))
activeOp_SelectCustomer();
activeOp_AddCustomer();
activeOp_DelCustomer();
activeOp_ModCustomer();
activeOp_AddOrder();
activeOp_SelectOrders();
protected Boolean op_validation(int opID)
{
object[] operationIds = new object[] { opID };
object[] result = (object[])clientContext.AccessCheck("Auditstring",
new object[1], operationIds, null, null, null, null, null);
int accessAllowed = (int)result[0];
if (accessAllowed != 0)
{
return false;
}
else
{
return true;
}
}
Si on ajoute une opération, il faut ajouter un test avec la méthode qui va avec. Dans le
principe, j’ai créé une méthode pour chaque fonctionnalité (=pour chaque opération).
Limitations
Les tâches ne peuvent pas être gérées avec .Net.
Le code est peut dynamique. Un changement dans AzMan peut entraîner une réécriture du
code de l’application.
Avec une application de type claims-aware, il n’est pas possible de se loguer avec un
utilisateur ASPNET, malgré que le rôle manager pour ASPNET est activé.
Cette solution apporte quand même un plus par rapport à une solution sans AzMan, car il
permet un affinage des droits utilisateurs, grâce à la notion d’opérations. Sans AzMan, c’est
possible de gérer l’application de la même manière, mais comme la notion d’opérations
n’existe plus, il faudrait créer un rôle pour remplacer chaque opération. Au niveau de l’ADFS,
16
il faudrait créer des groupes (« Claims Aware Applications ») pour chaque rôle ASPNET, car
on détermine le rôle d’un utilisateur en fonction de son groupe claims. C’est possible, même
si c’est moins intéressant avec une structure moins logique.
Erreurs
1. Le nom de l’application est « claimsaware » et non pas « app » (=magasin).
2. La chaine de connexion à LDAP commence par « msldap » et non « ldap ». CN= au nom
du magasin.
3. « Database is read-only »
Solution:
Télécharger l’outil SSEUtil de SQLExpress, puis tapez en commande:
C:\temp>SSEUtil.exe -child "NT Authority\Network Service" -detach
C:\Inetpub\stepbystep\claimapp\App_Data\aspnetdb.mdf
4. Droits d’accès insuffisants pour accéder à AzMan (ouverture de l’application). Dans
AzMan, faites un clique droit sur le nom du magasin > propriétés > security, puis ajouter les
droits de lectures à IIS (IIS_WPG).
URL du site
http://adfsweb.treyresearch.net:8080/claimappaz/
Application Token-Based – Exemple SharePoint
L’application SharePoint est une application de type Windows Traditionnal ou Token-Based.
On va voir avec cet exemple, comment mettre en place l’ADFS avec une application de ce
type.
Dans l’idée, on a deux utilisateurs de deux domaines différents : terrya du domaine
treyresearch qui à un rôle administrateur et adamcar du domaine adatum qui a un rôle lecteur.
AD Configuration
Dans l’Active Directory du domaine treyresearch:
Création
Nom
Federated users/
AdatumTokenAppUsers
User
Terry Adams
Dans l’active Directory du domaine adatum :
Création
Nom
TreyTokenAppUsers
User
Adam Carter
User name
Not applicable
Terrya
(terrya va pouvoir accéder à
l’application Token-Based
avec le rôle administrateur)
User name
Not applicable
adamcar
(adamcar va pouvoir accéder
à l’application Token-Based
avec le rôle lecteur)
Adam Carter est ajouté au groupe TreyTokenAppUsers.
Via l’ADFS, le groupe TreyTokenAppUsers sera associé au groupe AdatumTokenAppUsers à
qui est attribué le droit de lecture dans SharePoint. Ce droit de lecture ne peut pas être attribué
directement à Adam Carter dans la configuration de SharePoint, car il appartient à un autre
domaine que celui où est installé SharePoint.
17
SharePoint Configuration
Pour installer SharePoint, se référer au manuel « ADFS_stepbystep.doc » : En résumé, dans
« add/remove programs/windows components », il faut installer « SharePoints services » et
« ADFS Web Agents », de même qu’il faut configurer IIS avec l’ADFS Web Agent (TokenBased).
Une fois l’installation effectuée, il faut configurer les permissions d’accès à SharePoint :
Création de l’utilisateur terrya avec le rôle administrateur et du groupe TreyTokenAppUsers
avec le rôle lecteur.
ADFS Configuration
Adam Carter appartient au groupe TreyTokenAppUsers, qui va se retrouver associé au groupe
AdatumTokenAppUsers du serveur resource, via les claims.
Federated
type
Group
Claim
Account
Active
Account
Directory
Organization
Claims
TreyTokenAppUsers
Trey TokenApp Claim
Namespace
(incoming/
outgoing)
Resource
Resource
Active Directory
Organization
Resource group
Claims
TokenAppMappi
Adatum TokenApp
AdatumTokenAp
ng
Claim
pUsers
L’utilisateur terrya n’a pas besoin d’être configuré dans l’ADFS. Il faut être logué en local
sous terrya pour accéder au site.
Url du site
http://adfsweb.treyresearch.net/
Sources
Windows Server 2003 R2 home:
http://www.microsoft.com/windowsserver2003/default.mspx
MS IT Showcase ADFS:
http://download.microsoft.com/download/1/C/E/1CE0BC41-88F1-4208-9F7E97CC93FE2C2D/ADFS-R2ITVC.doc
Claims-Aware or Token-Based applications:
Troubleshooting ADFS
http://technet2.microsoft.com/WindowsServer/en/Library/ed76b687-7585-421d-ad4147c21499de001033.mspx?mfr=true
ADFS Overview
[projectDirectory]/ADFS/ADFS_Overview.doc
Architecture ADFS et interopérabilité
[projectDirectory]/ADFS/ADFS_Architecture_DrillDown.ppt
[projectDirectory]/ADFS/ADFS_Federated_Identity.ppt
[projectDirectory]/ADFS/ADFS_ITForums.ppt
18
Lab/B2B Scénario
[projectDirectory]/ADFS/ADFS_Lab.pdf
Création d’un magasin AzMan
http://www.windowsecurity.com/articles/Authorization_Manager_Role_Based_Administratio
n_Windows_Server_2003_Part1.html
Définition des rôles AzMan
http://www.windowsecurity.com/articles/Authorization-Manager-Role-Based-AdministrationWindows-Server-2003-Part2.html
Définition des opérations et des tâches
msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager/
Authorization Manager et ASP.Net 2.0
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnpag2/html/PAGHT000019.asp
Résolution d’erreurs
http://forums.asp.net/941457/ShowPost.aspx
MIIS
MIIS est un système qui gère et coordonne les informations d’identités provenant de multiples
sources de données dans une organisation, permettant ainsi de combiner ces informations en
une seule vue logique qui représente toutes les informations d’identités pour un utilisateur ou
une ressource donné.
En d’autres termes, il permet de regrouper (centralise et manage) les données utilisateurs,
applications ou provenant d’autres ressources réseau en une seule vue.
Versions
- Microsoft Identity Integration Server 2003 SP1, Enterprise Edition
- Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory:
o Gratuit, mais utilisable uniquement entre AD, ADAM, Exchange Server.
Identity Integration Feature Pack 1a for Microsoft Windows Server Active Directory a été
conçu pour intégrer les informations d’identités entre plusieurs forêts Active Directory ou
entre AD et ADAM.
Compatibilité
MIIS Server 2003 intègre les informations d’identités provenant des sources suivantes :
Network operating systems
Microsoft Windows NT, Active Directory, Active Directory Application Mode, IBM Directory
and directory services
Server, Novell eDirectory, Resource Access Control Facility (RACF), SunONE/iPlanet
Directory, X.500 systems, Global Address Lists (Exchange), LDAP Directory Interchange
Format and other met directory products
E-mail
Lotus Notes and Domino, Microsoft Exchange 5.5
19
Application
PeopleSoft, SAP, ERP, telephone switches, XML- and DSML-based systems
Database
Microsoft SQL Server, Oracle, Informix, dBase, IBM DB2, Access, Excel, OLE DB via SQL
Data Transformation Services (DTS)
File-based
DSMLv2, LDIF, CSV, delimited, fixed width, attribute value pairs
Système requis:
- Windows Server 2003 enterprise Edition (y.c. CALs (Client Access Licenses))
- SQL Server 2000 standard ou enterprise Edition SP3
Ceci est valable pour les deux versions.
Password Management
Cette fonctionnalité permet de regrouper les mots de passe d’un utilisateur dans une même
vue, afin de faciliter la réinitialisation (resetting) des mots de passe. En effet, l’administrateur
peut grâce à cette fonctionnalité gérer les mots de passe d’un utilisateur depuis une seule
application, au lieu de devoir perdre du temps à se déplacer là où il peut le réinitialiser.
Exemple :
Recherche de l’utilisateur
Accès à la vue de l’ensemble des mots de passe de l’utilisateur
20
Cette fonctionnalité ne fournit donc pas une solution SSO.
Extrait du FAQ MIIS :
MIIS 2003 peut-il synchroniser les mots de passe ? Permet-il l'implémentation de l'identification unique
(single sign-on, également appelé SSO) ?
Non. MIIS 2003 ne synchronise pas les mots de passe. Il permet à travers une simple interface Web de définir ou
réinitialiser les mots de passe de différents systèmes. MIIS 2003 ne permet pas le single sign-on ; ce rôle est dévolu à
Active Directory, Kerberos et d’autres composants du système d’exploitation Windows.
Bon à savoir:
- MMS n’est plus valable. Il est définitivement remplacé par MIIS 2003.
- Avec MIIS, la gestion des mots de passe entraîne également une synchronisation entre
MIIS et l’Active Directory (ou autre méta-annuaires). ADFS, par contre, est
étroitement intégré à Active Directory et ne nécessite pas de méta-annuaires à
maintenir ou d’architecture de synchronisation à construire.
- MIIS et ADFS: “ADFS is used for authentication, e.g., for WebSSO and for federated
scenarios. MIIS is used for user provisioning with business rules and for directory
synchronization. They complement each other. »
(http://www.microsoft.com/technet/community/chats/trans/windowsnet/05_0517_tn_a
d.mspx)
Sources:
MIIS 2003 Product Overview:
http://www.microsoft.com/windowsserversystem/miis2003/evaluation/overview/default.mspx
MIIS 2003 SP1 System Requirements:
http://www.microsoft.com/windowsserversystem/miisM2003/evaluation/requirements/default
.mspx
Microsoft Identity Integration Server 2003 Frequently Asked Questions:
http://www.microsoft.com/windowsserversystem/miis2003/evaluation/faqs/default.mspx
FAQ MIIS
http://www.microsoft.com/france/miis/decouvrez/faq.asp
Overview documentation:
[projectDirectory]/MIIS/MIIS_SP1.doc
Password management:
[projectDirectory]/MIIS/MIIS_2003_Password_Management.doc
Centrify DirectControl
Centrify et Microsoft ont collaboré pour donner naissance au produit DirectControl qui
permet notamment d’étendre l’ADFS à des applications Web tournant sur des plateformes
Microsoft ou non-Microsoft (Unix, Linux, Mac). Avec cette solution, Microsoft ADFS peut
être utilisé pour fournir le Web SSO pour des applications Web hébergé sur Apache et
différents serveurs J2EE tels qu’IBM WebSphere, BEA WebLogic, JBoss, et Tomcat.
Les rôles et droits d’accès sont gérés dans l’Active Directory. Les systèmes Linux et Unix
sont intégrés à l’Active Directory pour gérer les comptes de manière centralisée.
21
Le logiciel DirectControl suit les mêmes mécanismes que l’ADFS, c’est-à-dire qu’il va
fournir des Web Agents qui seront chargés d’intercepter les claims, de les valider et de les
transférer à l’application.
Il suffit d’installer le Web Agent de DirectControl sur le serveur Web qui héberge
l’application.
Composants DirectControl
Les composants suivants peuvent être téléchargés dans le « Download Center » de Centrify :
-
Windows Management Tools : permet de mapper les utilisateurs des environnements
Unix ou Linux dans l’Active Directory
System Agents : agents systèmes pour les systèmes d’exploitation suivants :
22
-
Les agents web pour les plateformes web suivantes :
Téléchargement de Centrify DirectControl
Le premier objectif de l’utilisation de Centrify DirectControl était d’étendre l’ADFS à une
plateforme Web Apache pour l’utilisation d’applications java. Comme Centrify ne propose
pas de modules d’application pour Apache sur Windows, j’ai choisi de tester avec Tomcat.
A noter que l’outil Windows Management Tool et que les agents systèmes ne sont utiles que
si l’on veut intégrer des utilisateurs Unix ou autres à l’Active Directory.
Pour tester l’ADFS avec une application Java, il suffit de télécharger le module d’application
Apache Tomcat on Microsoft Windows.
Le dossier dézippé contient :
- la doc « Web_Java.pdf »
- le fichier d’installation « install.pl » sous le répertoire « \centrifydc-web\java\ »
- les exemples d’applications sous le répertoire « \centrifydcweb\java\sampleapps\tomcat\tomcat5 ». Les fichiers « adfs-claims-aware.war » et
« adfs-ordering.war » sont les plus intéressants pour nous.
23
Installation du module
Dans l’idéal et selon Centrify, il suffit de lancer l’application « install.pl » qui va se charger
de configurer Tomcat et mettre en place les exemples d’application (Télécharger Perl pour
pouvoir exécuter le fichier). Après avoir choisi Tomcat, les options suivantes se présentent :
Configuration de Tomcat pour l’authentification avec Centrify DC
Des trois options proposées, seule la première option [1] fonctionne correctement. Elle copie
les librairies Centrify au bon endroit dans l’environnement Tomcat.
Installation de l’exemple « ADFS-claims-aware »
L’option [2] ne fonctionne pas : le programme n’arrive pas à mettre à jour le fichier .war.
Deux solutions : soit modifier les fichiers Perl, soit effectuer l’installation manuellement.
Pour faire fonctionner l’option, il suffit de mettre en commentaire la ligne 235 du fichier
« FsCommon.pm » du répertoire
« C:\temp\centrify_tomcat\centrifydc-web\java\scripts\perl\CentrifyFs »
Tel que
# return (-4, "Failed to update $tmp_dir/$app_name.war with $CENTRIFYDC_FS_CONFIG_FILE");
C’est mieux de vérifier manuellement que les changements ont bien été faits dans les fichiers
de configuration de Tomcat. On effectue la vérification pour l’exemple « adfs-claimsaware » :
Attention : le guide « web_java.pdf », utile pour la modification manuelle des fichiers de
config, contient des erreurs de frappe, caractères non UTF et erreurs de case-sensitive. Un
copier-coller du code peut entraîner des erreurs de serveur Tomcat.
1. Dans le fichier « server.xml » sous le répertoire
“C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf”:
<Context path="/centrifydc-samples" docBase="adfs-main"/>
<Context path="/centrifydc-samples/adfs-claims-aware" docBase="adfs-claims-aware"/>
Ces deux lignes correspondent plus ou moins aux «Virtual Path » de IIS. Elles mettent en lien
l’adresse URL de la page Web avec le chemin physique qui contient cette page.
2. Dans le fichier “centrifydc_fs.xml” sous le repertoire
« C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\adfs-claimsaware\WEB-INF », vérifier les lignes suivantes :
24
<federationServerUrl>https://adfsresource.treyresearch.net/adfs/fs/federationserverservice.asmx</fede
rationServerUrl>
<entryUrl>https://adfsresource.treyresearch.net:8443/centrifydc-samples/adfs-claimsaware/entry.jsp</entryUrl>
Ces deux lignes sont les mêmes qui se trouvent dans le fichier « web.config » des applications
.Net et qui font le lien avec le serveur ADFS.
Configuration du server d’application pour SSL
L’option [3] ne fonctionne pas du tout. Il faut faire la configuration manuellement.
1. Dans le fichier « server.xml » sous le répertoire
“C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf”, enlever les
commentaires à la balise suivante.
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" keystoreFile="\conf\keystore.jks" sslProtocol="TLS" />
2. Générer un certificat pour ce serveur avec l’outil keytool et qui sera stocké dans le fichier
« \conf\keystore.jks » :
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore C:\Program
Files\Apache Software Foundation\Tomcat 5.5\conf\keystore.jks
3. Importer le certificat du serveur host du serveur de fédération resource (certificat autosigné généré par selfSSL ; exportation dans un fichier .cer depuis le site Web par défaut
sous IIS) :
Déclaration de l’application au niveau du serveur ADFS
Dans le snap-in «Active Directory Federation Services » du serveur de fédération resource,
créer une nouvelle application « claims-aware ».
Ajouter à cette application des « organizations claims » déjà existants ou nouveau (voir le
chapitre consacré au lab du scénario B2B sous ADFS).
L’Application URL doit correspondre à la balise <entryUrl> du fichier « centrifydc_fs.xml »
de l’application claims-aware :
https://adfsresource.treyresearch.net:8443/centrifydc-samples/adfs-claims-aware/entry.jsp
25
Tester l’application
L’Url du site est le suivant :
http://adfsresource.treyresearch.net:8080/centrifydc-samples/adfs-claims-aware/
Après SSO, l’application aboutit avec succès :
Développez l’application claims-aware
La bibliothèque « centrifydc_fs_taglib.jar » de Centrify fournit les tags SAML qui permettent
de récupérer les informations concernant les assertions SAML et les claims.
Il n’est pas possible (en tout cas pas fait pour) d’appliquer AzMan avec une application Java.
Par contre, il est possible d’imiter l’application .net basée sur les rôles ASPNET.
Rôles Tomcat
Pour mapper des utilisateurs ou des groupes (group claims) à un rôle Tomcat, modifiez dans
le fichier centrifydc_fs.xml de l’application la balise <RoleMapping> :
<RoleMapping separator=";">
<Role name="Role1" group=”Adatum ClaimApp Claim” user="[email protected]"/>
<Role name="admin" group="Adatum ClaimApp Admin"/>
<Role name="manager" user="[email protected]"/>
</RoleMapping>
IfUserInRole tag
Ce tag permet de tester si un utilisateur appartient à un rôle (=group) ou non. On peut ainsi
afficher en fonction du group claim de l’utilisateur les éléments de la page qui lui sont visibles
ou non.
<saml:ifUserInRole role="Adatum ClaimApp Admin" var="isAdmin" />
<c:when test="${isAdmin}"> <a href=http://adfsweb.treyresearch.net:8080/claimapp>.Net Claims-Aware
Application
ASPNET Role-based Manager</a> </c:when>
Source
Plus d’informations sur le guide [projectDirectory]/Centrify/Web_java.pdf
26
Problème de certificats
Lors du lancement de Tomcat, l’erreur suivante est générée :
GRAVE: RMI error encountered while getting federation service trust info
java.rmi.RemoteException: Erreur de transport HTTP : javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested
target; nested exception is:
Erreur de transport HTTP : javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested
target
Cette erreur entraine l’erreur suivante lors du lancement de l’application web : le serveur de
fédération ne peut pas être contacté.
Cette erreur est due au fait que le certificat du serveur hébergeant le serveur de fédération
ressource qui a été importé n’est pas reconnu comme Certification d’Autorité valide par Sun.
Or ce certificat n’a pas de CA, puisqu’il est auto-signé.
Il y a trois outils et trois fichiers importants pour résoudre ce problème.
Les outils :
- selfSSL : outil de Microsoft qui permet de générer des certificats auto-signés. Le
certificat du serveur resource a été généré par cet outil.
- keytool : outil de Sun qui permet notamment de générer et d’importer des certificats
(génération de certificats auto-signés) dans des keystores au format JKS ou PKCS12
utilisés par java et Tomcat
- install.pl : ce petit programme en Perl de Centrify utilise l’outil keytool pour
l’importation de certificat
Les fichiers ou keystores:
- C:\Sun\AppServer\jdk\jre\lib\security\cacerts : contient les CA reconnus par Sun.
- C:\Documents and Settings\Administrator.ADFSRESOURCE\.keystore: keystore par
défaut de l’outil keytool ; lorsqu’aucun keystore n’est précisé dans la ligne de
commande.
- C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\keystore.jks: keystore
par défaut de Tomcat. Après avoir configuré Tomcat avec SSL, celui-ci va lire les
certificats dans ce keystore.
Résolution du problème
1. Si ce n’est pas déjà fait, exporter le certificat du serveur Host du serveur de fédération
resource dans un fichier .cer
2. Ne pas utiliser l’outil Centrify, qui ne fonctionne pas.
3. Généré un certificat auto-signé avec keytool dans le keystore par défaut de Tomcat :
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore C:\Program
Files\Apache Software Foundation\Tomcat 5.5\conf\keystore.jks
27
4. Importer le certificat du serveur resource dans le fichier cacerts des CA trusted par
Sun.
Source
Centrify et ADFS
http://www.centrify.com/directcontrol/adfs.asp
Centrify et Tomcat
[projectDirectory]/Centrify/Web_Java.pdf
Tomcat et SSL
http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
Perl
http://www.activestate.com/.
Liberty Alliance
Liberty Alliance, aussi connu sous le nom de Project Liberty, est un projet qui réunit des
acteurs des mondes industriel, informatique, bancaire et gouvernemental sous la forme d'un
consortium. L'objectif est de définir des ensembles de spécifications de protocoles de
fédération d'identité et de communication entre services web.
Dans le contexte de Liberty Alliance, l'authentification unique correspond à la possibilité pour
l'utilisateur d'accéder, après s'être identifié à l'aide d'un compte unique, à des services
proposés par différents fournisseurs appartenant à un même "cercle de confiance" ("Circle of
Trust"). Ces spécifications techniques et fonctionnelles décrivent donc les mécanismes qui
devraient d'une part simplifier l'usage d'Internet (mise en œuvre du principe de signature
unique) et d'autre part permettre à un individu de maîtriser la diffusion de ses données
personnelles (nom, prénom, adresse électronique, etc., qui définissent en réalité son identité
numérique dès lors qu'il fait usage d'Internet) en décidant lesquelles il désire partager.
Une caractéristique spécifique de Liberty Alliance est la notion de fédération. Au lieu que ce
soit un fournisseur de service qui décide si un utilisateur a le droit d'accéder à son service sans
se ré-identifier, c'est l'utilisateur qui décide s'il veut accéder à ce service sans se ré-identifier.
Cette possibilité ne peut être laissée à l'utilisateur que s'il doit au préalable s'identifier auprès
d'un fournisseur d'identité reconnu par le fournisseur du service demandé.
28
Concepts clés
[projectDirectory]/Liberty Alliance/LibertyTechnologyTutorial[1].pdf
Dans le chapitre sur PingFederate, ces concepts sont repris plus précisément.
Fédération – SSO initiation
[projectDirectory]/Liberty Alliance/LibertyTechnologyTutorial[1].pdf
Dans le chapitre sur PingFederate, les concepts d’IdP-Initiated SSO et SP-initiated SSO sont
repris en détails.
29
Implémentations libres
-
SourceID: http://www.sourceid.org/
“SourceID is the #1 open source project for federated identity”
-
Lasso: http://lasso.entrouvert.org/
o Fournit une librairie c++
o Interopérable avec SourceID toolkit for Java ID-FF 1.2
o Langages de développement conseillé : c++, c (pas terrible pour le Web SSO)
o Langages possibles : php, java, c#
-
FederID: le projet FederID est le résultat de l’intégration des logiciels libres suivants :
o Lasso : une implémentation libre des standards Liberty Alliance.
o InterLDAP : un gestionnaire d'annuaire LDAP avancé.
o LemonDAP : un mandataire inverse (reverse proxy) SSO.
Plus de détails à l’adresse:
http://federid.objectweb.org/xwiki/bin/view/Main/WebHome
Le projet est en cours et n’offre donc pas de solutions pour l’instant.
Membres actuels
http://www.projectliberty.org/membership/current_members.php
Liberty Alliance Interoperability
PingFederate
PingFederate n’apparaît pas sur cette liste, bien qu’il intègre le protocole standard SAML 2.0
qui appartient également aux protocoles Liberty Alliance (pas exclusivement). En fait, le
serveur PingFederate semble ne pas être interopérable avec le protocole ID-WSF (1.1) pour
les web services interopérable avec le protocole SAML 2.0. Et ceci est une des conditions
pour être reconnu LA Interoperable.
(http://www.projectliberty.org/press/details.php?item_id=134).
Tiré du document « PingFederate3_overview » :
Pour l’instant PingFederate n’intègre pas les protocoles ID-WSF de Liberty Alliance pour les
services web.
30
SymLabs
SymLabs est une entreprise qui a créé un produit « SymLabs Federated Identity Access
Manager » et qui a le même objectif que PingFederate, en ce sens qu’il est technologiquement
neutre. Mais, en plus des protocoles SAML 2.0 et WS-Federation (gérés par PingFederate), il
propose des protocoles spécifique à Liberty Alliance tels que ID-FF 1.2 et ID-WSF 1.1. Il
mérite donc d’être cité. Il est donc encore plus « Liberty Alliance Interoperable » que
PingFederate.
Ce logiciel n’est toutefois pas supporté par les plateformes Windows. Plateformes
supportées :
• Linux (any major distribution on x86 architecture, other architectures on request)
• Solaris 2.6 - 10 on UltraSparc architecture
• Solaris for Intel 8 - 10
• HP-UX (any architecture on request)
• AIX on request
• Mac OS X on request
• BSD family operating systems, any architecture, on request
• Any modern UNIX operating system on any architecture on request
• Embedded or blade operating systems on request
URL : http://www.symlabs.com/Products/SFIAM.html
Sun
Le produit Sun Java System Federation Manager possède entre autre les fonctions de SSO.
Il n’est pas encore disponible sur Windows.
Il n’intègre pas le protocole WS-Federation à sa solution.
URL : http://www.sun.com/software/products/federation_mgr/index.xml
IBM
Produit Tivoli Federated Identity Manager.
“Allow collaboration with a wide variety of partner organizations, through concurrent support
for all leading Federated Single Sign-On protocols”
“Align with open standards and specifications including Liberty, SAML, WS-Federation,
WS-Security and WS-Trust.”
URL : http://www-306.ibm.com/software/tivoli/products/federated-identity-mgr/
31
Oracle
Le produit Oracle Identity management contient notamment la solution de SSO (web y.c.)
Oracle Identity Federation qui supporte les protocoles SAML, Liberty et WS-Federation.
Supported Platforms and Components
Supported Platforms
Microsoft Windows 2000
Microsoft Windows 2003
Red Hat Linux
Supported Directory Servers and
Databases
Oracle Database
Microsoft SQL Server
Microsoft Active Directory
Oracle Internet Directory
Sun Java System Directory Server
Supported Identity & Access Management
Systems
Oracle Access Manager
Oracle Single Sign-On
Oracle COREid Access & Identity
CA SiteMinder
Supported Protocols
SAML 2.0
SAML 1.1
SAML 1.0
Liberty ID-FF 1.2
Liberty ID-FF 1.1
WS-Federation Passive Requestor Profile
URL:
http://www.oracle.com/technology/products/id_mgmt/coreid_fed/htdocs/fov_identity_federati
on_10gr3.html
Novell
Le produit Novell Identity Manager traite du SSO, mais pas du Web SSO, donc sans rapport
avec Liberty Alliance.
URL : http://www.novell.com/products/identitymanager/
Le produit Novell agréé par Liberty Alliance et appelé Novell Access Manager ou Odyssey,
ne semble pas encore disponible sur le commerce (rien trouvé sur le site). Il ne semble pas
non plus inclure le protocole WS-Federation.
URL : http://www.novell.com/news/press/archive/2004/07/pr04048.html
Liste complète
http://projectliberty.org/activities/conformant_products.php
Sources
Définition
http://fr.wikipedia.org/wiki/Liberty_Alliance
Site officiel
http://projectliberty.org/
32
PingFederate
Overview
Nature du produit
L’entreprise Ping Identity, qui soutient également le projet sourceID, a mis au point un
serveur de fédération PingFederate, qui intègre les protocoles SAML 1.1, 2.0 et WSFederation. PingFederate ne peut pas être considérée comme une application issue du projet
Liberty Alliance. En fait, elle est technologiquement neutre. Elle est tout aussi bien
interopérable avec ADFS (WS-Federation) qu’avec Liberty Alliance ou Shibboleth (SAML
2.0).
Description du produit
Le produit PingFederate est un serveur de fédération d’identité qui permet le Web SSO pour
des scénarios de B2B, B2C et en interne pour les employés. Il supporte également le protocole
WS-Federation, ce qui lui permet de se connecter à l’Active Directory et de dialoguer avec
l’Adfs.
http://www.pingfederate.com/products/pingfederate
PingFederate permet aux utilisateurs internes de se connecter SSO entre les domaines de
sécurité, mais aussi auprès des applications partenaires. Les utilisateurs partenaires peuvent
aussi se connecter SSO auprès des applications internes.
33
[projectDirectory]\PingIdentity\PingFederate\PingFederate_Datasheet.pdf
Un seul serveur PingFederate permet de fédérer des applications provenant de multiples
domaines de sécurité. Ce serveur fait office de fournisseur de service, alors que chaque
domaine de sécurité joue le rôle de fournisseurs d’identité. Chaque IdP peut gérer de manière
différente son contexte de sécurité.
[projectDirectory]\PingIdentity\PingFederate\PingFederate_Admin_Manual.pdfs
34
Concepts clés
Les derniers standards SAML 2.0 et WS-Federation définissent deux rôles dans un partenariat
de fédération d’identité : un fournisseur d’identité (Identity Provider or IdP) et un fournisseur
de service (Service Provider or SP).
IdP : c’est une entité système qui authentifie un utilisateur et transmet l’information de
référence de l’identité de cet utilisateur basé sur cette authentification.
SP : c’est le consommateur de l’information d’identité fournit par les IdPs. Les applications
SP déterminent la façon d’utiliser l’information contenue dans une assertion SAML.
Assertions : ce sont des documents XML envoyés depuis un IdP vers un SP et qui
contiennent les informations sur un utilisateur qui a initié un SSO.
Authentification context : Le contexte d’authentification est un supplément d’information
sur un utilisateur par rapport à une assertion requis par un SP pour permettre l’accès à une
ressource. Ces contextes d’authentification peuvent être fournis par des kits d’intégration.
IdP-initiated SSO : dans ce scénario, un utilisateur est logué auprès de l’IdP et tente
d’accéder à une ressource sur un serveur SP distant. L’utilisateur n’est pas logué sur le site
SP.
35
SP-initiated SSO : dans ce scénario, un utilisateur essaie d’accéder à une ressource protégée
directement sur le site SP sans y être logué. L’utilisateur n’a pas de compte sur le site SP,
mais il a un compte fédéré auprès d’un IdP tiers.
Account linking : cette méthode fournit un moyen pour un utilisateur de se loguer sur
différents sites avec seulement une authentification dans les cas où l’utilisateur possède des
comptes ou des credentials sur chaque site.
1. David Smith se logue avec son compte davidsmith sur le site A et décide de se loguer sur le
site B via le site A.
3. PingFederate crée un pseudonyme sur le site A et le fait passer sur le site B
4. PingFederate sur le site B retrouve le compte existant sur le site grâce aux informations
passées avec le pseudonyme.
36
Adapters et Agent toolkit
Un des avantages de PingFederate, qui lui permet d’intégrer les différentes plateformes Web
et selon les protocoles, est qu’il constitué d’un noyau central sur lequel viennent se greffer des
Adapters qui ont comme but de se connecter avec ces plateformes. Des agents sont placés du
côté des plateformes Web pour dialoguer avec ces Adapters.
Les Adapters pour les protocoles SAML et WS-Federation sont délivrés par défaut avec le
serveur PingFederate.
Les Agent Toolkits pour les applications Java et .Net peuvent être téléchargés sur le site de
SourceID. Ils sont déjà présents avec les exemples d’application.
Voici un schéma qui illustre cela dans un scénario de SSO IdP-initiated.
1. Login SSO
2. Application IdP insère les attributs de l’utilisateur dans un PFTOKEN (Token
PingFederate) via l’agent toolkit (pour .Net) dans notre scénario.
3. PFTOKEN est redirigé vers l’IdP serveur de PingFederate
4. A partir du PFTOKEN, génération d’une assertion SAML
5. Envoi de l’assertion SAML au serveur SP
6. A partir du SAML, génération du PFTOKEN
7. PFTOKEN redirigé vers l’application
8. L’agent toolkit lit le TOKEN et rend les attributs valables pour l’application
Interopérabilités
37
Installation du serveur
Etapes (tirées des docs « PingFederate_Admin_Manual.pdf » et « Quick_start_guide.pdf »)
1. Téléchargement du server PingFederate 4.0
2. Téléchargement et installation du Framework jdk 1.5
3. Demande pour obtenir pour une licence pour le serveur, puis installation de la licence dans
le répertoire <pingfederate_directory>/server/default/conf.
Attention ce n’est pas un fichier txt. Ne pas le sauvegarder comme un fichier txt.
4. Set java_home
5. Installation de PingFederate
a. Dezipping
b. Démarrage : Run.bat sous le répertoire <pingfederate_directory>/bin
c. Console d’administration : http://<server_full_name (hevsidf2.fedserver.idf)>:9030/pingfederate
d. New Password Liberty06 (user Administrator, init pwd 2Federate)
6. Téléchargement et installation de Java Cryptography Extension (JCE) dans le répertoire
/lib/security du répertoire JAVA_HOME
http://java.sun.com/products/jce/javase.html#UnlimitedDownload
Déploiement des scénarios (SAML 2.0)
Le but est de tester les différents scénarios (IdP-initiated et SP-initiated) avec l’exemple
d’application .Net.
En premier lieu, je monte un serveur unique Pingfederate qui officiera comme serveur IdP et
serveur SP.
Pour l’installation de pingfederate, voir les guides « PingFederate_Admin_Manual.pdf » et
« Quick_Start_Guide.pdf ».
38
Paramètres locaux
Attention, le port n’est pas 8090, mais 8070.
39
Configuration de l’IDAdapter
40
Configuration du SP Adapter
41
Connexion au SP
42
43
Connexion à l’IdP
44
Test du scénario IdP-Initiated
Lancez l’application idp et connectez-vous en local avec joe :
http://192.168.73.143:8070/idp/login.aspx
Le résultat donne cette page :
Maintenant que Joe est authentifié auprès du serveur IdP, il peut initier un SSO en se
connectant au serveur SP. Résultat :
45
Test du scénario SP-Initiated
Lancer l’application SP: deux solutions s’offrent à vous. La première est de se connecter en
local à l’application, puis d’initier le SSO (avec authentification auprès du server IdP) :
L’autre solution consiste à se connecter au server IdP qui effectue ensuite un SSO (type IdP
initiated).
46
Le SSO effectué donne la page suivante :
Cette page est la même que la page finale du SSO IdP-initiated, sauf que pingfederate a entre
temps été configuré pour l’initialisation SP SSO, ce qui a simplement rajouté la colonne de
gauche « IdP Connection » à la page.
Personnalisation de l’application en fonction de l’utilisateur
Le but est de développer un peu l’application, afin de donner des droits ou des restrictions
d’accès aux utilisateurs.
Les exemples d’applications stockent les utilisateurs dans des fichiers XML. On peut les
stocker dans une base de données pour plus de sécurité. Pour l’exemple, on va laisser les
informations utilisateurs dans un fichier xml.
Ces utilisateurs ne sont pas liés à un data store (base de donnée) qui contiendrait des
informations supplémentaires sur les utilisateurs et qui pourraient être utilisées pour
personnaliser l’application.
Ajout d’un attribut
Le fichier XML « \IdpSample\config\pingfederate-idp-demo-users.xml » contient les infos
utilisateurs. Par défaut, il contient l’identifiant utilisateur et le mot de passe. On peut rajouter
des attributs dans ce fichier. Voyons ce qui ce passe si on rajoute un attribut « group » :
a. si on lance l’application IdP et que l’on se connecte en locale, l’attribut group viendra
s’ajouter aux autres attributs. Ensuite, lors de l’initialisation SSO, la page est redirigée
vers l’application SP, mais l’attribut group n’est pas transmis.
b. Si l’on rajoute l’attribut group dans le fichier de conf de l’application SP, l’attribut
apparaîtra également après une connexion locale, mais pas après la connexion SSO.
47
Pour comprendre le fonctionnement, suivons étape par étape le mécanisme de SSO (SPinitiated):
1. Lancement de l’application SP
2. Login local : l’attribut group apparaît s’il a été ajouté au fichier
« \SpSample\config\pingfederate-idp-demo-users.xm »
3. Login SSO (redirection vers la page de login IdP + login) : tout d’abord, si l’attribut
group a été ajouté au fichier « \IdpSample\config\pingfederate-idp-demo-users.xml »,
il sera chargé dans le PFToken lors de sa création par l’application et envoyé au
serveur IdP. Ensuite le serveur IdP va générer une assertion SAML à partir de ce
PFToken et l’envoyer au serveur SP qui va reconstituer le PFToken et le renvoyer à
l’application resource qui va pouvoir le lire. Si l’on suit toute cette dernière étape sur
la console du serveur PingFederate qui tourne, on peut remarquer que l’attribut group
n’est pas inscrit dans l’insertion SAML et qu’il n’est donc pas transmis plus loin.
De cela, on peut déduire qu’il faut, premièrement, configurer l’IdPAdapter et la connexion SP
afin de permettre la retranscription de l’attribut du PFToken dans l’assertion SAML (IdP
serveur reçoit le PFToken de l’application IdP, génère l’assertion SAML et l’envoie au
serveur SP), puis deuxièmement, de configurer le SPAdapter et la connexion IdP afin de
retranscrire l’attribut de l’assertion SAML dans le PFToken (SP serveur reçoit l’assertion du
serveur IdP, génère le PFToken et l’envoie à l’application SP).
Configuration du SpAdapter pour l’ajout d’un attribut
Dans les paramètres de configuration du SpAdapter, sous la rubrique Extended Adapter
Contract, rajoutez l’attribut group (le nom doit correspondre exactement à la balise afficher
dans le fichier XML).
48
Dans les paramètres de configuration de la connexion IdP, sous la rubrique Attribute Contract,
rajoutez l’attribut group :
Puis, sous la rubrique Adapter Mapping & User Lookup, dans la sous-rubrique Adapter
Contract Fullfillment, mappez l’attribut group à l’attribut group provenant de l’assertion
SAML.
Un attribut peut provenir d’une Assertion (ce qui est le cas dans notre exemple, étant donné
que les attributs ajoutés dans le fichier XML de l’application IdP sont enregistrés dans le
fichier PFToken, qui sert de base à la création de l’assertion SAML dont on a configuré la
génération dans l’IdPAdapter en précisant qu’il fallait retranscrire l’attribut group), d’un
champ text (dont la valeur est écrite à la main dans le champ value), et finalement d’un data
store (une base de données ou un annuaire active directory).
Configuration de l’IdPAdapter pour l’ajout d’un attribut
Même mécanisme que pour le SpAdapter.
Modification de l’application
J’ai rajouté une rubrique à l’application SP qui contient les liens vers lesquels l’utilisateur
peut accéder (avec les droits d’accès correspondants) selon son groupe.
49
Problème : l’application est en .Net 1.1 et le code behind est compilé dans une dll. Je ne peux
donc pas modifier le code source directement et je ne peux pas le compiler non plus avec
Visual studio (.Net 2.0 et pingfederate non accessible pour les assemblies).
Il n’y a de toute manière aucun code spécial à rajouter. Il suffit de récupérer le groupe, puis
d’afficher ou non les liens en fonction du groupe et de transférer le nom d’utilisateur et le
groupe à l’application dont l’accès aux fonctionnalités va dépendre de ces paramètres.
Intégration avec l’ADFS (SP connexion)
Dans cette rubrique, on va voir comment réaliser l’interopérabilité entre l’ADFS et la solution
Liberty Alliance de SourceID.
L’objectif est de permettre à un utilisateur enregistré auprès d’un serveur IdP PingFederate
d’accéder à une application ressource par le truchement du serveur de fédération resource
ADFS (L’inverse est aussi possible, c’est-à-dire qu’un utilisateur de l’ADFS puisse accéder à
une application d’un SP configuré sous PingFederate).
Si on suit la logique ADFS, il faut créer un partenaire account qui se connecte à un
IdPAdapter de PingFederate. L’IdPAdapter doit stocker les informations utilisateurs dans un
data store (LDAP data store est le mieux indiqué pour cette opération). Ceci correspond à une
connexion IdP.
Du côté PingFederate, il faut créer une connexion SP avec le serveur ADFS.
En première instance, je vais configurer une connexion de type WS-Federation avec un
IdPAdapter de type LDAP. Ensuite, je vais tenter de créer une connexion avec un IdPAdaper
de type SAML (Remarque : les tokens ou assertions dans l’ADFS sont en format SAML 1.1).
LDAP IdPAdapter Configuration
50
LDAP Data Store Configuration
L’utilisateur administrator possède les droits d’accéder aux utilisateurs de l’Active Directory.
ADFS account partner
Au niveau du serveur de fédération resource :
L’url endpoint doit correspondre à l’IdPAdapter de type LDAP.
Incoming claim de type UPN.
51
ADFS SP Connexion
L’Adapter ci-dessus est de type standard, alors que l’adapter ci-dessous est de type LDAP.
52
Test de l’application
1. Lancez l’application http://adfsweb.treyresearch.net:8080/claimapp/
2. Choisir le royaume PingFederate
53
3. Choisir l’IdP Provider auprès duquel l’utilisateur doit s’identifier
4. a. Adapter Standard : Se connecter
Le login ID doit contenir un nom de domaine (adatum.com, treyresearch.net dans ce cas).
54
5. b. LDAP Adapter. Se connecter
6. Accès à l’application
55
Erreur
L’erreur suivante apparaît :
Cette erreur apparaît lorsque le filtre de recherche donne un résultat toujours vrai. On peut
ainsi se loguer avec n’importe quel nom. Le token ne sera pas créé pour autant, car le login ne
correspond à rien. Il faut donc trouver un critère de filtrage qui fonctionne (LDAP query).
Mais aussi, il faut que le login utilisateur comprenne un nom de domaine, car du côté ADFS,
seuls les utilisateurs avec le suffixe de nom de domaine adatum.com et treyresearch.net (que
j’ai défini moi) sont acceptés.
Intégration avec l’ADFS (IdP connexion)
Dans ce cas de figure, c’est un utilisateur
de l’ADFS qui doit pouvoir accéder à
une application ressource d’un SP géré
par PingFederate.
On va développer le cas de figure où un
utilisateur du domaine adatum.com (adfs
account federation server) désire accéder
à l’application sampleSP.
Ceci nécessite de créer une connexion
IdP côté PingFederate entre le
SPAdapter déjà existant et le serveur de
federation account de l’ADFS. Et du
côté du serveur account de l’ADFS, il
faut créer un partenaire resource.
ADFS resource partner
Au niveau du serveur de fédération
account :
Outgoing claim type : UPN (tous les
suffixes sont remplacés par le suffixe
adatum.com)
56
ADFS IdP Connexion
La connexion est mappée au SP standard.
Le groupe ne peut pas être récupéré depuis l’assertion, car le mécanisme de « outgoing claim
mapp » de l’ADFS n’est pas compatible avec PingFederate. J’ai mis du texte à la place. Pour
déterminer un groupe à un utilisateur, il faudrait créer un data store qui stocke les
informations sur les utilisateurs provenant de l’ADFS et qui indique le groupe auquel
appartiendraient ces utilisateurs.
57
1. Lancez l’application SP http://adfsweb.treyresearch.net:8070/sp/
2. Connectez-vous en local avec un utilisateur de votre choix
3. Initialisez le SSO (SP-initiated mode)
58
4. Identifiez-vous auprès du fournisseur d’identité (account serveur de l’ADFS)
5. SSO successful
Erreur
59
Pour permettre le SSO, il est nécessaire que le login local de l’application SP soit lié au login
du fournisseur d’identité.
Exemple : Utilisateur Adam Carter :
- AD IdP login : adamcar (Liberty06)
- Application SP login : adam (test)
L’application doit savoir que l’identité loguée en tant que adamcar correspond au login local
adam. Si ce n’est pas le cas, le message d’erreur ci-dessus apparaît.
Si l’on tente un IdP-initiated SSO au premier login et que les deux logins de l’utilisateur
diffèrent, alors l’application ne peut pas associer les deux logins à un utilisateur. Pour
remédier à ce problème, il faut effectuer un SP-initiated SSO, c’est-à-dire se loguer d’abord
en local auprès de l’application, puis effectuer l’identification auprès de l’IdP, ainsi
l’application pourra désormais lier les deux logins.
Le serveur PingFederate ne peut pas accéder à un fichier qui se trouve dans le répertoire data.
Il semblerait que se soie soit un bug de l’application, soit un bug du serveur. Pour y remédier,
remplacez dans l’URL la page affichée par la page default.aspx.
Sources
Site officiel
http://www.sourceid.org/projects
Overview
[projectDirectory]/PingFederate_Datasheet.pdf
Interopérabilité
http://www.networkworld.com/news/2005/0315saml2.html?nl
http://discuss.andredurand.com/newsItems/departments/pingid
Administrator guide
[projectDirectory]/PingFederate_Admin_Manual.pdf
Déploiement des exemples
[projectDirectory]/ Quick_Start_Guide.pdf
60
SourceID
SourceID fournit gratuitement des frameworks permettant la gestion d’identité fédérée
utilisant les spécificités Liberty Alliance. J’ai choisi comme premier essai de télécharger le
framework utilisant le protocole Liberty ID-FF 1.1 pour les applications .Net.
Installation du framework et des exemples
Se référer au document « [projectDirectory]/sourceID/ ID-FF 1.1 .Net Toolkit 1.1\ID-FF 1.1
Toolkit\Documentation\index.html »
1. Lancer l’application http://adfsweb.treyresearch.net:8050/sp/
2. Se connecter en local (SP-Initiated SSO)
3. Initier le SSO en s’authentifiant auprès de l’IdP
61
4. S’authentifier auprès de l’IdP
5. SSO Successful
62
Interopérabilité
Cet exemple qui utilise le Framework Liberty ID-FF 1.1 ne fonctionne qu’avec des
applications intégrant également ce protocole. Autrement dit, il est impossible de se connecter
directement à un serveur ADFS (évident), mais aussi à un serveur PingFederate. Celui-ci
n’inclut pas le protocole ID-FF 1.1, qui bien qu’il soit un ancêtre du protocole SAML 2.0
(intégré par PingFederate) n’en est pas moins incompatible avec ce dernier.
Dans les toolkits sourceID, seuls ceux avec le Framework SAML 1.1 sont interopérables avec
PingFederate, mais ce n’est pas un protocole Liberty.
Quant à un éventuel toolkit pour le Framework SAML 2.0, il serait probablement similaire à
l’exemple inclut avec PingFederate.
Erreurs
Org.Mentalis.Security
Si l’application signale que la bibliothèque Org.Mentalis.Security ne peut pas être trouvée,
alors copiez là depuis le répertoire de téléchargement du framework « ID-FF 1.1 .Net Toolkit
1.1\ID-FF 1.1 Toolkit\lib » dans le répertoire bin du site SP ou IDP.
System.Security.dll
Si vous avez une erreur du type :
System.ArgumentNullException: Value cannot be null.
Parameter name: elem
at System.Security.Cryptography.Xml.SignedXml.GetPropagatedAttributes(XmlElement elem)
at System.Security.Cryptography.Xml.Reference.CalculateHashValue(XmlDocument document,
CanonicalXmlNodeList refList)
at System.Security.Cryptography.Xml.SignedXml.BuildDigestedReferences()
at System.Security.Cryptography.Xml.SignedXml.ComputeSignature()
La dll System.Security.dll pour ASPNET 1.1 contient un bug. Indiquez dans IIS que le site
doit tourner avec ASP 2.0 et tout fonctionnera.
Autres projets d’identité fédérée
Shibboleth
Shibboleth est un middleware open-source (Java) basé sur les spécifications OASIS SAML
(comme Liberty Alliance) et qui fournit le WEB SSO. Peut-être installé sur les plateformes
Windows ou autres. Il possède une extension lui permettant de s’intégrer avec un service
ADFS. Il existe des implémentations de Shibboleth (essentiellement réalisées par des
universités – très utilisé dans les milieux universitaires, alors que Liberty Alliance est plutôt
utilisé en production).
C’est donc une alternative au projet Liberty Alliance (mêmes principes Identity Provider et
Service Provider).
Source
WebSite : http://shibboleth.internet2.edu/
Fédération d’identités avec Shibboleth
[projectDirectory]/others/Shibboleth - JRES2005.ppt
63
Liberty Alliance, Shibboleth et Lemonldap
La différence entre ces trois projets est caractérisée par son approche. Lemonldap (Logiciel
libre) dispose d’une base de données globale et centralisée de tous les utilisateurs. Cette
approche est principalement destinée à des services dépendant tous d'une même entité, par
exemple à l'intérieur d'une société.
Dans l’approche de Liberty Alliance, chaque service gère une partie des données d'un
utilisateur (l'utilisateur peut donc disposer de plusieurs comptes), mais partage les
informations dont il dispose sur l'utilisateur avec les services partenaires.
Cette approche a été développée pour répondre à un besoin de gestion décentralisée des
utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de
sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue
commercial et organisationnel.
Dans l’approche de Shibboleth, chaque utilisateur dépend d'une des entités partenaires. Ainsi,
lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est authentifié par le partenaire
dont il dépend. Comme dans l'approche fédérative, cependant, chaque service du réseau gère
indépendamment sa propre politique de sécurité.
Cette approche répond notamment aux besoins de structures institutionnelles dans lesquelles
les utilisateurs sont dépendants d'une entité, comme par exemple les universités, les
laboratoires de recherche, les administrations, etc.
Source
http://fr.wikipedia.org/wiki/Authentification_unique
Microsoft Passport
Tout comme le projet Liberty Alliance, Passport est un système standardisé permettant de
partager les informations d’identification utilisateurs. Il fédère les identités sur le réseau
Passport (MSN, Hotmail,…) de Microsoft.
Il ne présente aucun intérêt dans le cadre de ce projet, car il n’est pas possible d’implémenter
son propre réseau Passport. Ce réseau est administré par Microsoft et n’est accessible par un
tiers qu’en tant qu’utilisateur.
Standards identités fédérées
Tableau des principaux projets d’identités fédérées
[projectDirectory]/ Shibboleth/Shibboleth - JRES2005.ppt
PingFederate ne figure pas sur ce tableau car il est neutre. Il est interopérable avec tous les
projets ci-dessus (A vérifier pour Oblix).
64
Evolution des standards
[projectDirectory]\ADFS\ITPRO_Microsofts_Identity_and_Access_Management_Strategy_S
teven_Adler.ppt
Tableau de comparaison .Net Passport, Ping ID et Shibboleth
.NET/Passport • .NET Passport is a service; Liberty is
not a service rather Liberty defines a set
of specifications.
• Passport will use Kerberos for its
authentication token format; Liberty
uses SAML
• Passport defines a single mechanism
for authentication token exchange
between sites (through Kerberos);
Liberty defines multiple mechanisms by
which the authentication token can be
exchanged between sites
• Identity Provider exists in both
communities and maps between
different token formats
• Service Provider exists in both
communities and chooses
appropriate Authentication
Authority on a per transaction
basis
• Security Token Exchange
65
Ping ID
• Ping-ID focuses on the nature of the
business agreements and policies
between sites; Liberty provides a
technical framework
• If both are Ping-ID members,
Liberty Identity and Service
Providers can base their business
trust with respect to each other
on that membership
• Liberty Authentication Context
statement can be extended to
include PingID PICA score
Shibboleth
• Shibboleth users not required to have
account at Resource site
• Shibboleth sites exchange attribute
information to enable authorization
decisions; Liberty sites exchange opaque
identifier for principal
• Concept of end-user
controlling their privacy
preferences is fundamental to
both Liberty and Shibboleth
• Liberty Circle of Trust (COT)
and Shibboleth ‘club’ are similar
policy domains
• Liberty common-domain
discovery mechanism and
Shibboleth WAYF
interchangeable
Pour plus de détails, se référer au document :
[projectDirectory]/Liberty Alliance/Liberty And 3rd Party Identity Systems White Paper.pdf
FAQ
Existe-il un méta-annuaire unique pour une fédération ?
Non, une fédération ADFS se base sur les Active Directory des « claims » entrant (provenant
de domaines partenaires).
L’approche fédérative, tel que représentée par Liberty Alliance, répond à un besoin de gestion
décentralisée des utilisateurs.
[projectDirectory]/Liberty Alliance/LibertyTechnologyTutorial.pdf
66
L’interopérabilité entre les protocoles Liberty Alliance et ADFS est-elle possible ?
Non, pour se connecter à l’ADFS, il faut nécessairement utiliser le protocole WS-Federation
de Microsoft. Il n’y a aucun moyen de se connecter à l’ADFS avec un protocole SAML ou
Liberty Alliance.
Par contre, l’utilisation de serveurs de fédération multi protocoles tels que le serveur
PingFederate de Ping Identity ou SLIM de Symlabs règle le problème en intégrant à sa
solution les principaux protocoles (SAML, WS-Federation, Liberty ID-FF, Liberty-IDWSF).
Il permet ainsi de mettre en relation des utilisateurs et des ressources appartenant à des
réseaux ADFS et Liberty Alliance (et d’autres…)
Les assertions échangées entre les serveurs sont par contre toutes en format SAML.
En résumé, il est possible grâce à une application multi protocoles de résoudre le problème
d’interopérabilité.
Toutefois, il n’est pas possible de se connecter à l’ADFS avec un protocole basé SAML, de
même que l’ADFS ne permet en aucun cas de se connecter à un partenaire par un autre
protocole que le sien (WS-Federation).
ADFS ou Liberty Alliance ?
ADFS est un produit fini alors que Liberty Alliance est un projet. Parmi les implémentations
de Liberty Alliance on retrouve des vendeurs comme Sun, Novell, IBM et Oracle. Le choix
d’un produit plutôt qu’un autre va dépendre de la structure informatique de l’entreprise et des
objectifs qu’elle cherche à atteindre.
Cependant, rien n’empêche non plus de combiner les différents produits, ce qui est d’ailleurs
un objectif de Liberty Alliance et ce qui en fait son principal intérêt. En effet, pour fédérer des
entités provenant de systèmes différents, il faut que ces systèmes aient un protocole commun.
Actuellement, la plupart des produits proposés par les principaux vendeurs intègrent les
protocoles Microsoft et Liberty Alliance, permettant ainsi de connecter les deux réseaux.
Sources
Liberty Alliance, le nouveau Big Brother ?
http://www.sam-mag.com/P53,53,5,78,,,default.aspx
Liberty Alliance, les premiers projets voient le jour
http://solutions.journaldunet.com/0311/031114_liberty.shtml
Liberty Alliance, Wikipedia
http://fr.wikipedia.org/wiki/Liberty_Alliance
SAML et WS-Security
http://www.idevnews.com/CaseStudies.asp?ID=36
Pingfederate, sourceID et ADFS
http://www.genioprotocol.org/news/show/116
Standards protocols
http://arch.doit.wisc.edu/wiki/index.php/FIAM_White_Paper#OASIS_SAML
67

isnet 76 - serveur campus des écoles hes genevoises

Transcription

Documents pareils

Arrive à l`agence

Mon Journal au point de croix page 71 corrigée pdf

Tuner.be - Libertytv

Pour réussir vos cadeaux de Noël et combler tous vos proches, le

La maquette du Liberty ship Jérémiah O Brien entre au musée

fiche de réservation - Mobicités Location de véhicules sans permis

Petits riens pour chambre d`enfant : couture déco

OCÉANIS 411 CLIPPER

Imprimer - Le ptit char du nord

chatam 33 di - LIBERTY MARINE