Forms et sécurisation d'accès

Bonjour,

Je travaille sur un projet Forms 6i/Oracle 8i et nous nous posons des questions quand à la sécurisation de l'accès à notre appli.
Pour faire simple, l'utilisateur lance l'appli en exécutant un fichier bat contenant entre autres la chaine de connexion à la base Oracle. Cette chaine est utilisée en paramètre de l'appel à ifrun60.EXE qui lance l'appli forms proprement dite.

A partir de là une fenêtre de connexion (Forms) s'ouvre demandant à l'utilisateur de renseigner son login/mdp (différent de la chaine de connexion : de ce login/mdp dependent des autorisations d'acces sur certains ecrans). Le mdp est crypté (DBMS_OBFUSCATION_TOOLKIT) et comparé aux mdp cryptés stockés dans une table afin de s'avoir si l'on peut lui laisser un libre accès à l'appli.
Cela nous paraissait très bien jusqu'à ce que nous nous rendions compte qu'en éditant le fichier bat, un utilisateur averti aurait vite fait de récuperer la chaine de connexion et de se connecter à la base sous SQL*Plus et là ca pourrait être le drame (du moins pour les DBA :) )

Du coup, nous avons changé notre fusil d'épaule : l'idée est de faire en sorte que la chaine de connexion située dans le bat pointe vers un schema restreint ayant un droit SELECT sur la table d'authentification. Si l'authentification est validée, alors on connecte, dans forms, l'utilisateur sur le 'bon' schema...

De mon coté, je trouve que c'est beaucoup de bruit pour rien et je me demande si ce classique probleme de controle d'acces n'a pas une solution plus simple...

Qu'en pensez vous ?

Forms offre aussi la possibilité de contrôler les accès via la gestion des roles au niveau des menus.
Rien ne t'empêche d'avoir un menu général donnat accès aux fonctionnalités de ton application et de pouvoir controler les droits des utilisateurs.
.

Si le mot de passe est crypté, je ne vois pas comment les utilisteurs pourraient se connecter sans le décrypter...

Citation:

---

Envoyé par SheikYerbouti

Si le mot de passe est crypté, je ne vois pas comment les utilisteurs pourraient se connecter sans le décrypter...

---

c'est le mot de passe "forms" (celui qui verifie si l'utilisateur est bien enregistre pour l'appli et qui lui donne des droits particuliers) qui est crypté, pas celui de la BDD. La chaine de connexion SQL est localisée dans le fichier bat appelant ifrun60.exe, il est donc possible pour l'utilisateur (tres) averti de se connecter au niveau de la base et de faire a peu pres tout et n'importe quoi...

Citation:

---

Envoyé par star

Forms offre aussi la possibilité de contrôler les accès via la gestion des roles au niveau des menus.
Rien ne t'empêche d'avoir un menu général donnat accès aux fonctionnalités de ton application et de pouvoir controler les droits des utilisateurs.
.

---

Je ne vois pas de quoi tu parles, tu pourrais préciser stp ?
merci ! :wink:

La solution que tu as adopté est très semblable à celle que nous avons mise en place (sauf que nous passon directement par un raccourci windows sur le bureau :wink: ).

Citation:

---

Envoyé par plaineR

La solution que tu as adopté est très semblable à celle que nous avons mise en place (sauf que nous passon directement par un raccourci windows sur le bureau :wink: ).

---

Quand tu parles de la solution que nous avons adopté, tu parles de la solution retenue actuellement (et qui pose pb aux DBAs) ou celle qu'il nous faut mettre en place (avoir deux schemas : un gérant le pb de droits, l'autre contenant des données) ?
Si chez toi c'est la 1ere solution qui est en place, ne trouves tu pas qu'il y a effectivement une petite faiblesse au niveau de la securité, ca ne te pose pas de pb ?

Non, je parlais de la seconde (uniquement accès à la table d'authentification, puis connexion au schéma ensuite).

La problématique était peut-être un peu différente : en effet suivant le login saisi, on connecte l'utilisateur à tel ou tel schéma.

Il me semble en effet que la première solution est un peu légère au niveau sécurité. On peut toujours dir qu'il faut être un utilisateur averti pour intervenir avec SQL*Plus, mais cela n'en reste pas moins une faille au niveau de la sécurité.

Pourquoi ne pas mettre la connexion en dur dans la forme (trigger ON-LOGON) ?
Comme cela, il ne serait pas nécessaire de la passer dans le fichier .bat

Citation:

---

Envoyé par SheikYerbouti

Pourquoi ne pas mettre la connexion en dur dans la forme (trigger ON-LOGON) ?
Comme cela, il ne serait pas nécessaire de la passer dans le fichier .bat

---

Les DBAs demandent a ce que cela ne soit pas fait comme ca afin qu'ils aient plus de souplesse : qui dit changement d'utilisateur pour une raison X ou Y, dit modification et nouvelle livraison de la forme contenant la connexion en dur...
De plus, si plusieurs environnements (dev, qualif, recette, prod) possedent des chaines de connexion differentes, il faudrait avoir une forme par environnement, ce qui n'est pas top en cas d'evols ou de modifs...

Ca n'est pas pire que de livrer/modifier tous les .bat...

Citation:

---

Envoyé par SheikYerbouti

Ca n'est pas pire que de livrer/modifier tous les .bat...

---

Pas faux, mais en fait les bat ce sont les DBA qui les maintiennent, donc ils ont moins l'impression de perdre la main si la config se fait dans le .bat...
bref il est plus simple de leur livrer une seule appli et qu'ils se débrouillent ensuite pour configurer les acces... enfin ils preferent...

Le problème avec les DBA, c'est qu'ils veulent avoir la main sur tout...

Citation:

---

Je ne vois pas de quoi tu parles

---

Dommage, tu passes à côté de fonctionnalités intégrées à Forms qui sont pourtant très profitables.
Au lieu de monter une usine à gaz à la main, je te conseille de reprendre le chapitre sur la gestion des menus dans la doc Oracle "Advanced Techniques Manual", cela vaudra mieux qu'un long discours.
.

Citation:

---

Envoyé par star

Citation:

---

Je ne vois pas de quoi tu parles

---

Dommage, tu passes à côté de fonctionnalités intégrées à Forms qui sont pourtant très profitables.
Au lieu de monter une usine à gaz à la main, je te conseille de reprendre le chapitre sur la gestion des menus dans la doc Oracle "Advanced Techniques Manual", cela vaudra mieux qu'un long discours.
.

---

C'est noté !
Je vais me pencher la dessus !
Merci à tous ceux qui ont participé à ce thread