Newsgroup: it.comp.appl.access
Titolo: SSO semplificato per Applicazioni MS Access

Salve a tutti,
da qualche tempo  nell’angusta aia della mia scatola cranica razzolava
l’idea
di implementare una sorta di Single Sign On per le mie applicazioni
vba Access.
 
Da cotanto decerebrato razzolare ne è sortito fuori un un POC che
sembrerebbe funzicare
 
Beninteso:  si tratta di un semplice  workaround; di un SSO, come
dire,  “de noantri”.
 
D’altronde potrebbe anche trattarsi  della proverbiale scoperta
dell’acqua calda o della metaforica  “Corazzata di Fantozzi”(e ho
detto tutto...).   ;-))
 
Imho, fatte salve le premesse, potrebbe rivelarsi di una qualche
utilità, in quanto non richiede l’implementazione di  query Ldap e
compagnia cantando:  una semplice Dir$/ ChDir fa quasi tutto il lavoro
sporco.
 
La soluzione, in modo indiretto, fa uso delle autorizzazioni NTFS
impostate su uno specifico set di cartelle.
 
Può funzionare sia in ambienti con Directory Services o,  ben più
semplicemente,  in locale(e.g. un SO con account multipli)
 
Giudicherete voi(occhio che i pomodori  costano!) .   :o)))
------------------------------------------------------------------------
In un area accessibile agli utenti  dell’applicazione(e.g.:  “C:\Users
\Public\Documents”) creare un set di cartelle strutturato nel modo
seguente:
 
                   |====== Administrators
PolicyTree  |
                   |====== Users
 
Autorizzazioni
------------------
PolicyTree        :   read only per  everyone
Users               :   read only per  i soli  utenti  previsti con
ruolo User
Administrators :   read only per i soli utenti  previsti con ruolo
Administrator
 
*** Applicazione ***
In sintesi il workaround funziona così:
 
Alla partenza l’applicazione invoca una funzione che opera  un Dir$
(strPath, vbDirectory) ricorsivo di PolicyTree e dei subfolders.
Ogni subfolder viene passato alla seguente funzione.
****
Public Function IsAuthorized(ByVal strDirectory As String) As Boolean
    On Error GoTo ErrorHandler
    Dim blnHasPermissions As Boolean
 
    blnHasPermissions = True
    ChDir strDirectory
 
Uscita:
IsAuthorized = blnHasPermissions
    Exit Function
ErrorHandler:
    If Err.Number = 75 Then
        blnHasPermissions = False
        Resume Uscita
    End If
 
End Function
***
Se per uno specifico subfolder la funzione restituisce True, vuol dire
che l’utente ricopre quel ruolo.
 
Il valore booleano può quindi essere  salvato in una variabile o,
meglio, in un oggetto dictionary, al fine
di permettere al programma di variare il proprio comportamento a
seconda delle aurorizzazioni.
 
La struttura dei folder, poi, può essere resa complessa a piacere
aggiungendo ulteriori  livelli di subfolder.
 
E’ altresì possibile  informare le autorizzazioni sulle operazioni,
piuttosto che sul ruolo.
e.g.:
                      |====== SolaLettura
PolicyTree     |
                      |======  ControlloCompleto
 
La gestione delle permissions, poi, può anche essere implementata in
vba tramite l’uso dell’oggetto Wscript.Shell.
 
Tutto qui. :-))
 
Un salutone,
Stolcius, AKA Michele Collatina

"Stolcius Von Stolcenberg"  ha scritto nel messaggio 
news:dbd0ee18-ff62-40fd...@y12g2000vba.googlegroups.com...

___________________________Risposta:
Ciao Stolcius,
perché non usi semplicemente una chiave di registro?
Basta "algoritmarla" e quindi diventa difficile da violare dall'utente
MA
 
 
 
 

 MA
 
Ciao, Masimiliano,
grazie per la risposta. :-)
 
Potresti,  per cortesia, spiegarmi più dettagliatamente come dovrebbe
funzionare la procedura?
 
Scrivere sul registro implicherebbe possedere le permission per farlo
e
ciò potrebbe rendere la cosa ingestibile in certi contesti
operativi...
 
Per chiarezza, il workaround in topic garantisce quanto segue:
- L'utente si autentica sul dominio e accede al suo profilo;
- lancia l'applicazione;
- il workaround, basandosi sul PolicyTree, gli attribuisce un ruolo,
più ruoli o
  specifiche permission;
- l'utente quindi non deve inserire nessuna password, pur ottenendo un
buon
  livello di sicurezza.
- l'applicazione è, di fatto, disaccoppiata dall'attribuzione dei
ruoli; infatti
  l'abbinamento ruoli/account può essere demandata a un utente
amministratore
  che possiede diritti di fullcontrol nell'area(shared) relativa al
PolicyTree.
  La gestione delle utentenze può quindi essere gestita "ad manellam"
o tramite
   un'apposita funzione vba(incardinata sull’oggetto Wscript.Shell).
- Sempre tramite coding vba, la struttura della directory con le
policy può essere
  salvata e replicata a piacere.
- Più applicazioni possono autenticarsi con un unico PolicyTree senza
variazioni
  strutturali. E' sufficiente cambiare la stringa con il percorso
della directory-
 
 
Un salutone,
Stolcius
 
Per aspera ad dis-astra
 
 
 

"Stolcius Von Stolcenberg"  ha scritto nel messaggio 
news:9a32efd1-8bb6-4c7c...@gl2g2000vbb.googlegroups.com...
[CUTTONE]
 
Un salutone,
Stolcius
_________________________________Risposta:
C'è qualcosa che non mi quadra.
L'amministratore ha le credenziali di creare folder e gradare le credenziali 
e non di scrivere nel registro??
Delle due l'una o hai a che fare con un admin o no.
Nel primo caso puoi crearti una semplice chiave di registro, leggerla e 
gestire ciò che vuoi;
nel secondo caso non puoi far nulla
 
MA
 
 
 

 gestire ciò che vuoi;
 
Chiedo scusa, Massimiliano,  ma non riesco a capire in che modo, nella
fattispecie, possa essere utilizzata la chiave di registro.
 
Forse, mea culpa, non ho specificato che l'applicazione da me
vagheggiata non è necessariamente allogata su una specifica macchina,
ma può essere ospitata in una cartella di rete sia in forma
"monolitica" o come frontend backend(con il backend nella
shared).  :-)))
 
Grazie K per la risposta.
 
Un salutone,
Stolcius

"Stolcius Von Stolcenberg"  ha scritto nel messaggio 
news:93faafaf-3763-44c3...@w15g2000yqc.googlegroups.com...
 
 
Chiedo scusa, Massimiliano,  ma non riesco a capire in che modo, nella
fattispecie, possa essere utilizzata la chiave di registro.
 
Forse, mea culpa, non ho specificato che l'applicazione da me
vagheggiata non è necessariamente allogata su una specifica macchina,
ma può essere ospitata in una cartella di rete sia in forma
"monolitica" o come frontend backend(con il backend nella
shared).  :-)))
 
________________Risposta:
E questo è un errore marchiano (se vuoi fare peggio puoi solo dire "Forza 
Juve"!!!!)
Ogni postazione DEVE aver il suo Front End, ti risparmi corruzioni di file, 
traffico di rete e casini come questi.
 
Per quanto riguarda il discorso invece non allocato sulle macchine: ma 
allora perché ci metti delle directory sulle postazioni?
gestisci le permission come si è sempre fatto attraverso user e psw
MA 
 

 gestisci le permission come si è sempre fatto attraverso user e psw
 
Al momento non ho ancora intenzione di implementare il workaround
sulle mie applicazioni.
 
Così a scatola chiusa? Fossi matto! ;-))))
 
Ho pubblicato la cosa su ICAA proprio per sottoporlo alle giuste
critiche di voi veterani e vedere se non emergano degli elementi
critici o dei miglioramenti.
 
Imho il SSO, in linea di principio e in certe circostanze, potrebbe
avere i suoi indiscutibili vantaggi; il problema è per appunto se il
workaround sia funzionale o no; o se, come già detto, tramite i
contributi di questo NG possa essere migliorato.
 
Un salutone,
 
Stolcius