Discussion :

[Papy214]

reBonjour,

Je cherche maintenant à faire une authentification simple avant le lancement de la première WinForms de mon programme. Et je ne sais pas trop où positionner les éléments.

J'ai créé:

• une classe Utilisateur qui va contenir un nom et un niveau de droits.
• une classe Authentification qui lit un bète fichier xml pour remplir les infos utilisateur

Je précise que le but n'est pas de gérer une sécurité forte. Il s'agit juste d'un "paramétrage" pour des postes internes.

Dans le point d'entrée de mon programme, j'écris:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
        static void Main()
        {                       
            Authentification authentification = new Authentification();
            Utilisateur utilisateur = new Utilisateur();
 
            if (authentification.Authentifie(ref utilisateur))
            {
                Application.EnableVisualStyles();
                Application.SetCompatibleTextRenderingDefault(false);
                Application.Run(new FormEntree());
            }
 
        }

Première question : Est-ce une bonne façon de procéder ?

Seconde question : Vu que j'ai besoin du niveau de "droit" de l'utilisateur un peu partout dans le programme, je pensais déclarer cette variable utilisateur à l'endroit vu ci-dessus. Problème, dans FormEntree, il semble que je ne puisse pas accéder à cette variable. Si je la déclare dans FormEntree, avant la création de l'instance, je ne peux pas accéder à utilisateur et donc pas l'utiliser dans la méthode Main() où je fais l'authentification. Dans ce cas, quel serait le meilleur endroit pour déclarer ma variable ?

Merci de vos lumières ..

[Bluedeep]

Première question : Est-ce une bonne façon de procéder ?

Personnellement, je ne trouve pas. Pour des autorisations pas trop compliquées, je trouve que le plus simple est de créer des groupes windows d'utilisateurs (ou des roles via AD) et de tester via l'utilisateur loggé la méthode IsInRole.
Ainsi tu délègues la gestion des droits à windows, et basta.
Tu as le logging windows qui authentifie l'utilisateur, pas utile de réinventer l'eau chaude à ce niveau, non ?

Seconde question : Vu que j'ai besoin du niveau de "droit" de l'utilisateur un peu partout dans le programme,

Classe statique ou singleton avec le niveau de droit en question dans cette classe; c'est le plus simple (le singleton, c'est la version objet des variables globales , donc à utiliser avec les même précautions ; en user c'est bien, en abuser c'est mal )

[Papy214]

je trouve que le plus simple est de créer des groupes windows d'utilisateurs (ou des roles via AD) et de tester via l'utilisateur loggé la méthode IsInRole.

Là, tu me parles d'un truc que je maitrise pas encore. Je pensais effectivement à un truc dans ce genre au début, mais je n'ai aucune idée sur la façon de procéder. Je débute en C#, faut pas l'oublier

La classe statique sera plus de mon niveau actuel.

Mais si tu as une URL vers un tutoriel expliquant comment accéder aux comptes utilisateurs sous Windows et comment l'utilisateur actuellement loggué, je suis preneur.

[Bluedeep]

Là, tu me parles d'un truc que je maitrise pas encore. Je pensais effectivement à un truc dans ce genre au début, mais je n'ai aucune idée sur la façon de procéder. Je débute en C#, faut pas l'oublier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
        /// <returns></returns>
        public bool authenticateUser(string groupToCheck)
        {
                // Vérifier le rôle
                if (getAuthenticatedUser().IsInRole(groupToCheck))
                {
                    // L'utilisateur est autorisé à effectuer des opérations du groupe
                    return true;
                }
            return false;
        }
 
        private static WindowsPrincipal getAuthenticatedUser()
        {
            return (WindowsPrincipal)System.Threading.Thread.CurrentPrincipal;
        }

C'est un bout de code qui vient d'un de mes projets (je l'ai expurgé à la va vite).

[LooserBoy]

Première question: non
L'idéal serait d'avoir une classe static (par ex. Manager) qui s'occupe de gerer tout cela. Un petit exemple issu partiellement de mes dev. actuels...
En reprennant l'idée initiale, mon kernelmanager equivaut à Authentification...
et checklogin à authentifie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
public class KernelManager
    {
        // Design Pattern: Singleton!
        // Un seul manager doit être utilisé!
        private static KernelManager _me;
        private Utilisateur current_utilisateur;
        public static KernelManager Manager
        {
            get
            {
                if (null == _me)
                {
                    _me = new KernelManager();
                }
                return _me;
            }
        }
 
        // Recupère les paramètres de l'utilisateur courant
        private void LoadParameters()
        {
             ...
        }
 
        // Sauvegarde les paramètres de l'utilisateur courant
        private void SaveParameters()
        {
             ...
        }
 
        public bool CheckLogin(ref Utilisateur utilisateur)
        {
            ...
            current_utilisateur = utilisateur;
        }
 
        public bool HasAccessToX()
        {
            ...
        }

Ensuite pour pouvoir acceder à tout moment aux infos de l'utilisateur dans l'appli:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
// verification du login dans FormEntree
if(KernelManager.Manager.CheckLogin(utilisateur))
{
    KernelManager.Manager.LoadParameters();
}
...
// Verification des droits où c'est necessaire
if(KernelManager.Manager.HasAccessToX())
{
    // Autorisé
    ...
}
else
{
    // Pas autorisé
}

En cas de questions... on est là..

P.S.: Pfiou le temps que je ponde mon truc... plein de reponses...

[LooserBoy]

@bluedeep: cette methode est certes pas trop compliquée à mettre en oeuvre mais peut parfois s'averer etre inapplicable à cause de politiques de securité d'entreprise... et peut aussi poser des pbs du genre un admin regarde la liste des groupes, ne comprends pas le pourquoi du comment, les supprime et zou! plus d'appli en fonctionnement.
Dans le cas d'une classe static, l'application est autosuffisante...

[Bluedeep]

P.S.: Pfiou le temps que je ponde mon truc... plein de reponses...

Pas grave, comme cela il a deux solutions.

Néanmoins, je reprocherais à la tienne (à première vue, si je me trompe, corrige moi) de faire ce que je lui recommandais d'éviter : windows possède un système d'authentification, autant l'utiliser.

[Bluedeep]

@bluedeep: cette methode est certes pas trop compliquée à mettre en oeuvre mais peut parfois s'averer etre inapplicable à cause de politiques de securité d'entreprise...

Désolé, mais je ne comprends pas : elle a justement l'avantage de s'intégrer à la politique de sécurité de l'entreprise !

et peut aussi poser des pbs du genre un admin regarde la liste des groupes, ne comprends pas le pourquoi du comment, les supprime et zou! plus d'appli en fonctionnement.

Dans ce cas, je crois que l'admin va avoir quelques soucis : a priori on installe pas une appli sans concertation avec le SI, non ?

Dans le cas d'une classe static, l'application est autosuffisante...

Mais c'est justement le problème : tu es obligé de créer et de supprimer les comptes en "double", alors que cela doit être centralisé (arrivée, départ, mutation interne).

Ici, tu dois donc avoir un admin de ton appli en plus des admin SI.

[Papy214]

merci à tous deux ...

Je vais étudier tout ça.

LooserBoy, ton code façon singleton me permet donc d'accéder au manager depuis n'importe quel endroit du code ? y compris depuis le Main() ?

Bluedeep, l'utilisation du groupe d'utilisateurs windows me donnera des droits genre Windows par définition si j'ai bien compris. Et ça m'oblige à créer des groupes d'utilisateurs sur les postes qui vont utiliser cette petite appli. Dans le cas présent, c'est peut-être un peu "lourd". Mais ça me sera utile pour d'autres choses. Je crois que je vais débordé de projets en C# en 2008

[Bluedeep]

Bluedeep, l'utilisation du groupe d'utilisateurs windows me donnera des droits genre Windows par définition si j'ai bien compris. Et ça m'oblige à créer des groupes d'utilisateurs sur les postes qui vont utiliser cette petite appli. Dans le cas présent, c'est peut-être un peu "lourd". Mais ça me sera utile pour d'autres choses. Je crois que je vais débordé de projets en C# en 2008

Les groupes peuvent être créés au niveau domaine. De plus, si le domaine où tu implémentes l'application utilise Active Directory, les groupes peuvent être remplacés par des rôles AD.

[LooserBoy]

Désolé, mais je ne comprends pas : elle a justement l'avantage de s'intégrer à la politique de sécurité de l'entreprise !

Pas mal d'entreprises ont pour politique de creer des groupes pour x raisons (fonctionnelles, geographiques, historiques, en fonction de l'humeur de l'admin,...) mais le fait d'avoir le droit à ceci ou cela d'une application particulière : . De plus, j'ai deja eu affaire à des SI qui n'acceptaient même pas que tu aille les voir pour leur annoncer que tu as besoin d'un role supplementaire et de redistribuer les utilisateurs à cause d'une evolution de ton appli...

Dans ce cas, je crois que l'admin va avoir quelques soucis : a priori on installe pas une appli sans concertation avec le SI, non ?

Dans un monde parfait, certes...

Mais c'est justement le problème : tu es obligé de créer et de supprimer les comptes en "double", alors que cela doit être centralisé (arrivée, départ, mutation interne).

Ici, tu dois donc avoir un admin de ton appli en plus des admin SI.

Oui! Le talon d'Achile de cette solution et sans aucun doute...
[EDIT]MAIS cela permet d'empecher l'admin reseau d'avoir acces à l'appli. Ceci est une solution retenue par tous les editeurs de logiciels compta ou gestion commerciale qui manipulent des données parfois extremement sensibles (ex. SAGE). De plus, on a pas obligatoirement la necessité d'etre admin pour administrer l'usage de l'appli.[EDIT]

[LooserBoy]

merci à tous deux ...

Je vais étudier tout ça.

Papy retourne à ses études, youpi!!!

LooserBoy, ton code façon singleton me permet donc d'accéder au manager depuis n'importe quel endroit du code ? y compris depuis le Main() ?

Oui mais je deconseille de toucher au main sauf pour enrichir le paramétrage général de l'appli (genre culture: separateur decimal par defaut, monnaie, etc..)

[Bluedeep]

Pas mal d'entreprises ont pour politique de creer des groupes pour x raisons (fonctionnelles, geographiques, historiques, en fonction de l'humeur de l'admin,...) mais le fait d'avoir le droit à ceci ou cela d'une application particulière : . De plus, j'ai deja eu affaire à des SI qui n'acceptaient même pas que tu aille les voir pour leur annoncer que tu as besoin d'un role supplementaire et de redistribuer les utilisateurs à cause d'une evolution de ton appli...

Je pratique ces gens là depuis de longues années; après c'est plus une question de "poids" que tu as auprès de l'entreprise.

[EDIT]MAIS cela permet d'empecher l'admin reseau d'avoir acces à l'appli. Ceci est une solution retenue par tous les editeurs de logiciels compta ou gestion commerciale qui manipulent des données parfois extremement sensibles (ex. SAGE).

L'argument est quelque peu faiblard dans la mesure où un admin réseau a virtuellement accès de toute manière aux données, sauf si elles sont cryptées.(auquel cas, je t'accorde qu'il fait envisager les choses sous un angle différent - mais uniquement dans ce cas).

@De plus, on a pas obligatoirement la necessité d'etre admin pour administrer l'usage de l'appli.[EDIT]

Euh .. si tu n'as pas un niveau "admin de l'appli", ca ne sert à rien d'avoir une sécurité d'accés.