Hej Hej Roger Går det inte att använda Oracles Applikations-roller till detta ? Hej igen RogerServerbehörighet
Har ett projekt som involverar Oracle och .Net. Applikationen som finns idag använder sig inte av .Net utan den kommer eventuellt att migreras till .Net. Exakt hur saker och ting skall fungera är oklart men idag fungerar applikationen på följande sätt.
"Serverbehörigheten bygger på Oracles användande av roller, dessa hindrar åtkomst av vyer och metoder för ickeauktorizerade användare."
Ett senario är att man har kvar Oracle som databas och flyttar helt eller delvis ut affärslogiken till en applikationsserver som kör .Net. De erfarenheter jag har av .Net är applikationer som inte utnytjar användare och inbyggd säkerhet i databasen utan att det styrs av affärslagret.
Ett annat senario är att man även flyttar från Oracle till t ex MS Sql server.
Jag kan inte se några direkta problem med detta. Har jag inte behörighet till en vy alternativt en procedur i databasen så kan jag inte köra denna även om jag migrerar till .Net på applikationssidan.
Finns det någon som har erfarenhet av att använda .Net i ett liknande senario? Funkar det bra eller finns det något att tänka på?
RogerSv: Serverbehörighet
Jag måste säga att jag inte riktigt förstår vad du är ute efter.
Går det inte att använda Oracles Applikations-roller till detta ?
Bästa Hälsningar
Folke LarssonSv: Serverbehörighet
Vad innebär Oracles Applikations-roller?!
Vad jag förstått så finns det två skolor om hur man vill hantera kopplingen till databasen.
Den ena så kopplar man upp med användaren som loggar in i applikationen och håller sessionen öppen under hela tiden denna är inloggad. Behörigheten finns i databasen med mera.
Den andra är att man loggar in i applikationen och att man sedan har ett konto som kopplar upp när man ställer t ex en fråga mot databasen. Kopplar ner när man är färdig. Då kan man inte låta databasen hantera säkerheten eller?!
För att köra connection poling måste kan man använda båda sätten, skilljer det sig mellan Oracle och MS SQL?!
Om man kör en tre skiktad lösning med en applikationsserver där klienten använder webbservices för att kommunicera med applikationsservern fungerar då båda alternativen eller blir det inte lösning 2 då?
Hoppas jag var lite tydligare...
RogerSv: Serverbehörighet
Hade jag inte varit ute i ödemarken där inte mobiler eller internet verkar hade
jag nog svarat tidigare.
Jag vet inte om det är skolor eller inte, men det borde väl bero på vilka uppgifter
databasen används till. Det klassiska är att en användare logar in direkt via
en arbetsstation med en speciell användare och lösen. Rättigheterna i databasen
kan sättas på systemnivå eller objektnivå. Ett exempel på det första är
"SELECT ANY TABLE" och "CREATE TABLE" och på det andra
"SELECT, UPDATE(fnamn, enamn) ON fl.anstallda_t". Privilegierna grupperas
efter roller som baseras på typen av användare som t. ex administratör och
handläggare. Rollerna tilldelas sedan användarna. Man kan också användarna
autenticeras( heter det så ? ) via operativsystemet, vilket också går att
göra via nätverk. Privilegier sätts dock som vanligt.
Med Internets frammarch och alla flyktiga användare blir det besvärligt. Detsamma
gäller om databasen är kopplad till ett tredje skikt. Tidigare var man tvungen
använda lösenord inne i applikationerna eller tredjeskiktet.
Den som utvecklar applikationer kan numera bestämma villkoren som avgör användarnas behörigheter i Oracle. Dom sk applikationsrollerna reglerar åtkomst i gränssnittet till Oracle. Rollen aktiveras av ett PL/SQL-package med funktioner/procedurer och tillåter bara access från vissa bestämda IP-adresser, mellanskikt eller host. Den kan alltså bara aktiveras av applikationen och behöver inget lösenord. Till applikationsrollen tilldelar man andra tradinionella roller med system- och objekt-privilegier.
Detta har sitt ursprung i något som Oracle ibland kallar Virtual Private Database (VPD),
men ibland något annat som Fine Grade Access Control(FGAC). En riktig databas kan ha flera VPD med egna säkerhetsdomäner. Villkor( WHERE-satser ) kan sättas i runtime för queries mot databasen mha procedurer och funktioner. Det går också att se vem som försöker köra frågan och varifrån.
Ytterligare en term hör till, nämligen Global Application Context(GAC).
Med hjälp av detta skapas en pool av inte bara connections utan vad jag förstår
rentav sessioner. Med funktionen SYS_CONTEXT kan man kolla klientens context, till exempel host, ip-adress mm. Detta autenticerar användaren och alltså inte user/password.
Proxy-autentisering gör att det går att skilja på om användaren ansluter direkt
eller genom ett tredje-skikt. Genom att kolla både ip-adressen och varifrån
sessionen startades fås en hög säkerhet.
Slutresultatet är att varje applikation kan ha sitt eget säkerhets-context och
attribut. Kontroll av att alla villkor uppfyls för en användare görs alltså i
procedurer och funktioner.
Jag tror att jag återkomer till ämnet, kanske till helgen med en artikel, mer
pedagogiskt genomtänkt.och med testade exempel. Jag håller på med lite
sånt här, men när man ska förklara så verkar det bli rätt krångligt.
MS SQL-Server har också nån sorts applikationsroller om det nu är samma sak.
Jag vet dock inte så mycket om MS SQL-Server så det vore kul om någon
som kan det ämnet kunde haka på, om det inte redan skrivits om.
Bästa Hälsningar
Folke Larsson