Gebruikersnamen en wachtwoorden in één centraal bestand.

[jhvdberg]

Hallo,

 

Ik heb een vraag m.b.t. gebruikers accounts.

 

Is het mogelijk om (onder FileMaker) een bestand aan te maken waar ik alle gebruikers in zet die met de database moeten werken?

In dat bestand wil ik dan de gebruikersnamen, wachtwoorden en rechten in vermelden.

 

Wanneer een gebruiker dan inlogt op het "start scherm", moeten de gegevens worden vergeleken in dat ene bestand waarna bepaald wordt of er wel of geen toegang wordt verleend.

 

De database bestaat uit meerdere FM bestanden die aan elkaar gerelateerd zijn en die allemaal worden afgeschermd middels een wachtwoord.

 

Wanneer de gebruiker via het start scherm op een button klikt om een ander bestand te openen moet deze geopend worden met de gegevens van de huidige gebruiker zonder dat deze opnieuw zijn gegevens moet invoeren.

 

Of een andere mogelijkheid dat een ander bestand van de database wordt geopend zonder dat de gebruiker opnieuw zijn gegevens moet invoeren.

Maar het moet wel zichtbaar zijn welke gebruiker er op dat moment is ingelogd.

 

 

Gr.

 

Remco van den Berg

[Jeroen de Wit]

Is het mogelijk om binnen de organisatie gebruik te maken van een centrale Active Directory / LDAP installatie? Dan kunnen daar de gebruikers(groepen) in worden gedefinieerd en worden gekoppeld aan FileMaker. Enige wat je vervolgens hoeft te doen is in FileMaker de juiste privelige set aan te maken en te koppelen aan de gebruikersgroep.

 

Zo niet, kijken of je gebruik kunt maken van een script die een custom dialog laat openen bij het openen van het bestand waar 2 globale velden ingevoerd kunnen worden (username/password), vervolgens controleer je deze input tegenover de gegevens uit je gebruikersdatabase en koppel je daar ook een privelligesetID aan, wie weet dat dat werkt?

[andries]

als je in elk bestand dezelfde gebruikersnaam en paswoorden gebruikt, zal FileMaker automatisch de andere files met die accounts openen (of de Active Directory is ook een goed systeem).

 

Het is echt een zeer slecht idee om paswoorden te gaan opslaan in FileMaker. FileMaker heeft een vrij stevig veiligheidssysteem, en ik zou ten stelligste aanraden om hier gebruik van te maken. Al de andere systemen zijn vrij snel te kraken. Met vrij snel bedoel ik in het slechtste geval 1 minuut in het beste geval 1 dag.

 

Bekijk even deze post: viewtopic.php?f=29&t=6705&p=40904

[menno]

De beveiliging van Filemaker met zijn eigen security structuur is prima, maar is vooral prima in (filemaker)omgevingen die niet al te complex zijn. Er zijn bijvoorbeeld bedrijven die bijvoorbeeld een deel van de opdrachten onzichtbaar willen maken voor medewerker X omdat dat de omzet van zijn directe baas is (ik noem maar ff een dwarsstraat) Je kan beveiligen met de Record Level Access van Filemaker en dat werkt ook prima bij 10000 records, maar bij 100000 of 1000000 en meer wordt de database al aardig traag. Dit is slechts één voorwaarde, maar bij bedrijven die op deze manier beveiligd willen worden hebben vaak nog veel meer van dit soort voorwaarden. Je snapt dat dit een behoorlijk lastig verhaal wordt als je naast deze beveiliging ook nog eens een systeem hebt dat modulair is opgebouwd (uit meerdere bestanden bestaat).

 

De meeste FM-databases in organisaties zijn net vanaf internet bereikbaar, daarvoor moet je eerst op het netwerk zien te komen en dat lukt vaak alleen met vpn en ssh. Dat is dus de eerste deur waar iemand doorheen moet, dan moet iemand filemaker openen en de juiste database opstarten met de juiste privileges. Als dat is gebeurd kan je er rustig vanuit gaan dat degene die dat iemand van jouw bedrijf en er wat heeft te zoeken. Het lijkt me dan prima dat daarna een tabel raadpleegt bij iedere actie die die gebruiker doet om te kijken of hij/zij dat wel mag.

 

Ik snap best dat je nu op het puntje van je stoel zit om te roepen dat dit niets met beveiligen heeft te maken, maar daar zit je mijns inziens fout:

1) Als iemand op de een of andere manier op je netwerk kan komen, dan is de grootste beveiliging die je hebt al gekraakt, want hij kan nu op alle plekken in je netwerk komen en daar voor hem nog onleesbare/ontoegankelijke bestanden stelen. De regel is algemeen: als iets ziet kan je er op de een of andere manier ook bij

2) Als die iemand nu ook de bestanden kan stelen, laten we zeggen dat ie de backup heeft gevonden en die als pakketje steelt. Hij gaat dan op zijn gemak met software (het bestaat want ik heb die software zelf ook) de (filemaker)passwords verwijderen, dan kan hij daarna bij alle gegevens.

 

Deze methode is héél véél gemakkelijker dan te proberen wijs te worden van de eigengebouwde inlog die een ontwikkelaar de gebruiker voorzet, nadat deze de FM-bestanden opent ..... na het verwijderen van het wachtwoord volg je immers het opstartscript en draai de privilegechecks simpelweg de nek om

 

De standaardbeveiliging van Filemaker is helemaal prima om ervoor te zorgen dat je vanaf bijvoorbeeld internet het moeilijk maakt om überhaupt bij de gegevens te komen. Daarna is het soms een beter idee om zelf een privilege-check in te bouwen en te raadplegen zodat eenmaal in de database er een hele flexibele manier van toegangscontrole is.

 

Beveiliging kent veel benaderingshoeken en er bestaat volgens mij geen beste methode die alle aspecten omvat, soms is dit beter en soms is dat beter en vaak is een combinatie van dit en dat beter. Ik ga persoonlijk voor de gecombineerde aanpak, waarbij soms een beetje meer FM-beveiliging en soms een beetje meer eigen-beveiliging wordt toegepast.

 

Active-Directory is feitelijk niet meer of minder dan de eigen filemaker beveiliging, daarbij wordt gecontroleerd of iemand die inlogt deel uitmaakt van een groep in AD die is aangemaakt als account in FM. Heb je behoefte aan veel individuele getaylorde privileges, dan schiet je met AD dus ook niet veel op.

[rmw]

Ja, dat is heel goed mogelijk.

Openen met een standaard account, wachtwoord en privilegeset, wat alleen de usertabel mag lezen.

Opstartscript toont dialog voor het opvragen van de inloggegevens.

Controleren en als het klopt de scriptstap Re-login gebruiken om met het goede nivo opnieuw in te loggen in alle benodigde databases.

 

Twee dingen die daarbij van belang zijn:

- je moet dan wel elk nivo als account/wachtwoord voordefinieren in elke database

- re-login moet uitgevoerd worden in de database zelf, dus elke database moet een re-login script hebben. Maar met behulp van scriptparameters kan je de inloggegevens prima doorgeven.

 

rmw

[andries]

ik daag jullie uit

 

de enige manier die het een beetje beveiligd is sinds FileMaker 11 waar je kan aanduiden dat enkel een [Full Access] account het bestand mag toevoegen als extern bestand. Op die manier is het mij nog niet gelukt...

[menno]

Ja, dat is heel goed mogelijk.

Openen met een standaard account, wachtwoord en privilegeset, wat alleen de usertabel mag lezen.

Opstartscript toont dialog voor het opvragen van de inloggegevens.

Controleren en als het klopt de scriptstap Re-login gebruiken om met het goede nivo opnieuw in te loggen in alle benodigde databases.

 

Dat is ook mogelijk, maar dat is niet wat ik heb beschreven. Ik leg het dus nog heel kort uit en vul het nog aan met andere punten waar je dan op moet letten:

1) De gebruikers loggen in met een standaard account, dat kan heel gemakkelijk in een URL-bestand worden opgeslagen, zodat ze zelf niet het een naam en wachtwoord hoeven in te tikken (de koppeling in een URL-bestand is: fmp7://adres_van_de_server/startbestand.fp7).

=====

Uiteraard wordt door de gebruikers geen [full access]-privileges gebruikt, anders heeft dit allemaal geen zin.

=====

2) Zodra het systeem opent wordt een inlogdialoog getoond zodat het systeem weet wie je bent, als je correcte inloggevevens invoert.

=====

Er wordt met deze methode verondersteld dat je iets hebt te zoeken op het netwerk waar de fm-server draait. De beveiliging daarvan wordt in principe door Active-Directory cq. Open-Directory (VPN, Wifi etc) voor zijn rekening genomen. Als je fysiek aanwezig bent in het netwerk, dan ben je meestal door de voordeur gekomen en heb je er ook iets te zoeken

=====

3) Om deze "beveiliging" goed te laten laten werken zijn er twee belangrijke voorwaarden waaraan je systeem moet voldoen:

a) Alle navigatie moet via knoppen en scripts verlopen.

b) Er is altijd maar één layout die open is, eventuele andere vensters moeten een blanco layout tonen

4) Als de gebruiker nu het systeem open heeft wordt bij iedere navigatiestap die hij zet gecontroleerd of hij dat wel mag. Dwz als jij dat in het script zo hebt geprogrammeerd.

=====

Bijv: op het hoofdmenu staat een knop financiële administratie, daarachter zit de verkoopfacturering en de inkoopfactuurregistratie. Door het systeem heen kunnen gebruikers wél zien dat er op een project is gefactureerd en hoeveel, maar ze kunnen alleen boekingen invoeren als ze via het hoofdmenu naar "financiële administratie" gaan/kunnen. Wat er gebeurt is het volgende: ze klikken op de knop en je controleert dan eerst in de gebruikerstabel of ze dat mogen, zo ja dan laat je ze verder en zo nee, dan weiger je de toegang te geven.

=====

 

Je denk nu mogelijk waarom zo moeilijk doen als je gemakkelijke FM-beveiliging kan toepassen? Daarvoor zijn een flink aantal redenen:

1) Je moet de beveiliging in elk bestand doorvoeren, met 2 of 3 account en evenzovele privilege-sets is dat nog wel te doen, maar bij meer wordt het al lastig.

2) Bedrijven en beheerders bij bedrijven willen graag op overzichtelijke wijze de privilegestructuur inzichtelijk hebben, waarbij het bij voorkeur over gegevens en plekken in een systeem gaat en niet over databasetechniek

3) Het wijzigen van privileges moet bij voorkeur op één plek geschieden.

4) Filemaker bied op geen enkele wijze de beveiliging van Active- en Open-directory waarbij de rechten simpelweg een concatenatie zijn van de rechten van de groepen waar de gebruikers lid van zijn. Dit houdt in dat je met de FM-beveiliging voor iedere combinatie van rechten een aparte privilege-set zou moeten maken.

5) Als je met hetzelfde systeem met verschillende ontwikkelaars bij verschillende klanten zit, dan wil je graag eenvoud en eenvoud is: één [full access]-account en 1 of 2 [alleen bewerken]-accounts en dat liefst in alle bestanden. (In de praktijk lukt het vaak niet om het tot zo simpel als 2 a 3 accounts te beperken, maar véél moeilijker hoeft vrijwel nooit)

 

Ik weet eerlijk gezegd niet of dit nu alle redenen zijn om het zo te doen, maar het zijn de belangrijkste. Ik ga ook niet zeggen dat dit dé oplossing is, want dat is ie niet, maar hij is werkbaar. Als Filemaker het nu zo zou gaan maken dat een account aan meerdere privilegesets kan worden gekoppeld (zodat de security meer lijkt op AD/OD) en dat accounts en privilegeset kunnen worden geïmporteerd (accountnamen en basisprivileges voor aanmaak), of dat in een bestand met de security naar securitystructuur van een ander bestand kan worden verwezen, dan zou ik mijn huidige manier van beveiligen meteen laten varen en daarmee verder gaan

[menno]

ik daag jullie uit

 

de enige manier die het een beetje beveiligd is sinds FileMaker 11 waar je kan aanduiden dat enkel een [Full Access] account het bestand mag toevoegen als extern bestand. Op die manier is het mij nog niet gelukt...

 

Je hebt helemaal gelijk, als je dit niet hebt uitgezet, dan kan je een database aanmaken en simpel een externe referentie aanmaken en dan de tabellen opnemen. Het is dus niet handig om je databases toegankelijk te maken via internet en die automatisch te laten openen met account-x. Iets met een re-login zou hier niet werken, omdat je op dit punt al toegang hebt tot de database.

[andries]

ik daag jullie uit

 

de enige manier die het een beetje beveiligd is sinds FileMaker 11 waar je kan aanduiden dat enkel een [Full Access] account het bestand mag toevoegen als extern bestand. Op die manier is het mij nog niet gelukt...

 

Je hebt helemaal gelijk, als je dit niet hebt uitgezet, dan kan je een database aanmaken en simpel een externe referentie aanmaken en dan de tabellen opnemen. Het is dus niet handig om je databases toegankelijk te maken via internet en die automatisch te laten openen met account-x. Iets met een re-login zou hier niet werken, omdat je op dit punt al toegang hebt tot de database.

 

dan zijn we het eens

 

Wij hebben ook een user tabel met daarin privileges, maar dat is om intern het proces te sturen, niet om toegang te geven tot de database. De toegang tot de database wordt bij ons altijd via een account en paswoord geregeld. En zo heb je inderdaad gelijk, je hebt bescherming van data voor gebruikers, en je hebt bescherming van data voor "hackers" van buitenaf. Beide kunnen op een andere manier aangepakt worden.

 

het is het enige wat ik even wou zeggen: er zijn ontwikkelaars die proberen met een standaard account een database te openen en dan met een "simpele" find gaan kijken of de gebruikersnaam/paswoord een match is. Het is belangrijk om te weten: als het script er toegang toe heeft, heeft ook de gebruiker er toegang toe.

 

Trouwens ik bel al helemaal geen fan van systemen/websites die mijn paswoord opslaan. Ik zie dit het liefst gecodeerd. Ik test dit meestal door mijn paswoord opnieuw aan te vragen. Kunnen ze het recupereren -> bad business, resetten ze mijn account -> goed zo !

[jhvdberg]

Allen dank voor de antwoorden, was even worstelen soms...

 

De reden voor mijn vraag is eigenlijk omdat binnen de database de meeste gebruikers alleen maar "schrijf/lees" rechten hebben, maar een aantal moeten meerdere rechten krijgen, dit ligt per "onderdeel" bij verschillende personen.

Bijvoorbeeld:

- DB1 (File1) wordt beheerd door mijzelf, daar moet ik bijvoorbeeld rapportages/overzichten uit kunnen printen en eventueel gegevens wijzigen ALS deze verkeerd zijn ingevoerd

- DB2 (File2) wordt beheerd door een andere collega die daar de rapportages moet kunnen printen, maar niet in mijn DB (File1), of aanpassingen moet kunnen maken.

 

Maar ik ga het even verder proberen met de opties van FM.

 

Ik heb ergens eens een script gezien om account gegevens vanaf een centrale locatie (in mijn geval bijv. het Start scherm) in te voeren en deze automatisch in de overige aan de database gekoppelde bestanden in te voeren, maar kon deze nu niet meer zo 1-2-3 vinden.

Is er dan ook zo'n manier om een gebruiker uit alle gekoppelde bestanden te verwijderen?

 

Gr.

 

Remco