18. juni 2003 - 08:20Der er
58 kommentarer og 2 løsninger
Konstruktiv kritik af opgave
Hejsa, jeg ved ikke helt om det er muligt det her. Men det er sådan at vi har skrevet en opgave og godt kunne tænke os lidt konstruktiv kritik omkring vores sikkerhedsafsnit i denne opgave. Afsnittet kommer ind på noget omkring java, samtidighedsproblemer, EJB, synchronized... Jeg kan desværre ikke smide afsnittet op da der er fodnoter osv. Men kunne man ikke lave det på en sådan måde at jeg mailer det til en (hvis en kunne tænke sig at læse det igennem) og personen derefter kommer med kritikken her på siden? Eller er det helt udelukket og i uoverenstemmelse med exp's regler?
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Som et absolut minimum må: - alle der beder om det have det tilsendt - de mest relevante pointer posts her med et lille citat og kommentarern så andre kan have nytte af det
Jeg uploader den selvfølgelig riversen :o) Jeg har klippet en masse overfødige (overflødige for sikkerhedsafsnittet ud)screenshots ud. Opgaven ligger nu på www.confunded.dk/TP/opg.zip
--> Arne Jeg glemte så at nævne at der også er en enkelt tabel og at nogle er fodnoter henviser til et fx et bilag eller kommer med en forklaring.
Det er hele vores opgave jeg har oploadet, da jeg er bange for at det går galt med krydshenvisninger osv. hvis jeg bare klippede sikkerhedsafsnittet ud.
Håber det nu er i overenstemmelse med exp regulativer. Ellers kan jeg evt. summere op på det hele til sidst?
Det skal iøvrigt nævnes at ejb ikke er i vores pensum. Vi har blot bevæget os ind på det fordi vi havde fået forståelsen af, at det var smart, og at det kunne bruges med fordel i vores opgave.
Så hvis vi har misforstået noget helt, må i endelig sige til :o)
Jeg er ikke engang kommet til det afsnit du vil have kommentarer til men:
#Enhver computer med Internet adgang skal kunne anvende systemet. Der kræves #dermed platformuafhængighed, og vi foreslår derfor, at systemet programmeres i #Java, som er et platformsuafhængigt programmeringssprog.
Øh ? Ligger der en implicit forudsætnig om fat client ? Med en browser baseret web løsning kan server principielt kodes i asssembler og stadig virke på alle browsere (selvom JSP/servlets + EJB nok ville være nogete smartere) !
#Vi vil anbefale, at KMD baserer systemet på en clustered EJB #applikationsserverteknologi, da denne teknologi overholder ACID kriterierne , #tilbyder en høj horisontal skalerbarhed , og sikrer en høj oppe tid, da der #ikke skal tages højde for den enkelte computer i clusteret.
J2EE clustrere skalerer fremragende horisontalt, men medmindre man bruger det allerdyreste Oracle og DB2 kram så skalerer databasen kun vertikalt, hvilket ofte er flskehals.
#Da vi anbefaler, at systemet skal programmeres i Java, ville det være naturligt #at bruge Javas funktionalitet synchronized til at opnå seriel equivalens og til #at forebygge samtidighedsproblemerne, som kunne opstå i forbindelse med #transaktionerne
server: hvis i bruger J2EE og alle de rigtige patterns så burde det ikke være nødvendigt med synchronized keyword i jeres kode. J2EE containeren vil indeholde en masse synchronized. Hvis I kodede en hel monolitisk server, så ville I med garanti have brug for synchrinized.
--> Arne 18/06-2003 08:50:39 Nej, der ligger ingen implicitte forudsætninger om fat client. Vi har dog aldrig haft med andet at gøre end java på vores studie, deraf konklusionen. Men det du siger er da helt klart noget vi ikke har tænkt over/viste. Er der nogen idag som koder servere i assembler eller lign?
--> Arne 18/06-2003 08:53:35 Forrygende pointe, det viste jeg i hvert fald ikke. Hvordan skalerer man iøvrigt en database horisontalt?
Det med assembler var bare en joke. Selvfølgelig bruger man moderne teknologi. Det var kun logikken i jeres argument jeg anfægtede. Platforms uafhængighed på client og server er to forskellige ting. Platforms uafhængighed på client er "gratis" med en browser løsning.
Database clustering er en kompleks sag. Man skal have 2 database servere som begge har en komplet kopi af alle data. Ændringer skal udføres på begge. Forespørgsler kan load balances. Tænk på det som to RAID 1 hard-diske - det er bare tabeller og record i stedetfor disk blokke. Jeg mener at Oracle og IBM tager 7 cifrede beløb for den slags legetøj (der er også diverse billigere alternativer men ikke nogen der bruges ret meget).
#Et alternativ til KMDs digitale signatur ville være TDCs, men sikkerheden er her #ikke så høj, derfor faldt valget på KMDs. En nærmere diskussion kan ses i Bilag #12
--> Arne 18/06-2003 08:58:30 De 3 comit typer du snakker om, er de alle i forbindelse med nested transactions og er vi inde i noget omkring Atomic commit protocols eller noget two-phase commit protocol? Kan de 3 typer (a,b,c) forklares kort?
--> Arne 18/06-2003 09:13:05 Ja det punkt hænger lidt i vores opg. Men det er set ud fra et rent sikkerheds perspektiv, således at det ikke er "alle og enhver", der kan anmelde et dødsfald. Vi tænker på et ekstrem tilfælde hvor man bestiller en digital signatur hos tdc for en anden uskyldig person (en læge) og modtager hans post ved at stille sig ved hans postkasse. Men ja danmark har valgt.
Nej. A, B og C har noget at gøre med hvorvidt J2EE app-serveren er ene om at bruge databasen. Hvis den ved at den er ene, så kan den cache data. Hvis den ved den ikke er ene om det, så kan den ikek cache, fordi en anden applikation (et gammelt COBOL program) kan have opdaterer data side.
Hvis man sætter den commit option der siger at den er ene og den så ikke er det, så får man store problemer.
Det relaterer sig kun til CMP entity beans.
Og bemærk at en session bean der bruger JDEBC til at opdatere data er faktisk nok til at CMP entity beans ikke kan caches.
#Ved anvendelsen af dette middleware (Java RMI) sikrer man brugen af at-most-one #invocation semantic , og man har mulighed for at nå et højere sikkerhedsniveau, #da man i Java RMI kan sætte en sikkerhedspolitik. Dette bekræfter igen vores #anbefaling omkring EJB, da disse gør brug af RMI .
Jeg ved ikke om jeg vil kalde RMI for middleware. Det er en teknologi til at generere noget kode med (proxy GoF pattern). Det genererede kan muligvis kaldes middleware.
EJB kan bruge RMI, men kan også bruge anden teknologi. EJB er meget interface orienteret og implementationerne kan være meget forskellige.
--> Arne 18/06-2003 09:15:02 (SSL) Ups, ja det er der i hvert fald en fejl. Vores bog (Distributed systems concepts and design, g. coulouris et.al)er lidt uening med dig, da den skriver (s.79)at ssl er præsentation level: --Layer--- --ex-- Application http, ftp, smtp, corba iiop Presentation Secure sockets, Corba, data rep Session Transport TCP, UDP Network IP;ATM virtual circuits Data link ethernet MAC, ATM cell transfer, PPP Physical Ethernet baseband signalling, ISDN
--> Arne 18/06-2003 09:21:56 (UPS) Jep det er vi nu også ret sikre på... det skal jo heller ikke blive for kedeligt at læse ;o)
--> Arne 18/06-2003 09:28:21 (browserløsning) Ja det kan jeg egentlig godt se, vi cykler lidt rundt i det. Det er vel underordnet om browseren understøtter ssl, hvis vi afvikler det i en applet. Men hvis det afvikles via jsp/servets, så skal browseren vel understøtte det?
Hvad lag noget er i OSI modellen (som kun drejer som netværks protokoller) og hvordan det forholder sig i en software arkitektur er to helt forskellige ting.
--> Arne 18/06-2003 09:35:14 (RAID) Ja der laver vi lidt kage i den, for i bilag 8 foreslå vi nemlig at de skal benytte raid 1. Raid 0+1 kender jeg ikke men det kunne jo være jeg skulle kigge lidt på den og fortælle lidt om det i mit forsvar.
--> Arne 18/06-2003 09:43:15 (ren browser vs application) Har lige 2 spørgsmål hertil: Hvad er SOAP over http? Hvad er web service servlet (vs servlet)?
Det er helt klart det punkt jeg vil tage op til mit forsvar så. Anbefalingen må vel være at det bliver: ren browser ----(HTML over HTTP)---- JSP/servlet ---- EJB --- database Da jeg i hvert fald ved at de i forvejen ikke bruger applet og ikke ren application.
Jeg synes i skulle skrive hvorfor i har prioriteret som i har. Hvorfor er "Flytbart" irrelevant (osv..).
Konklusion "Efter vores overbevisning følger vi registerlovens krav til håndteringen af sikkerhed omkring disse data."
Registerloven blev erstattet af persondataloven i 2000 "Efter vores overbevisning" er et uholdbart argument, i fralægger jer ansvaret ved at formulere det sådan. Har i undersøgt området gundigt nok ? Prosa har lavet en pjece om persondataloven: http://www.prosa.dk/persondataloven/
--> soreno 18/06-2003 09:58:16 I opgaveteksten er der henvist til registerloven, så det er egentlig derfor den er med. Jeg viste dog ikke at den er blevet erstattet af persondataloven. Vi skriver godt nok "efter vores overbevisning", og det er tyndt. Men vi skriver så også følgende på side 20: "Et krav til registreringen af persondata er, at den følger registerlovens krav om registrering og sikring af personlige data. Vi har efter en gennemgang af registerloven vurderet, at vores system lever op til disse krav, men før implementeringen vil en gennemgang med en jurakyndig person være på sin plads." Så ja, vi fralægger os ansvaret, men har samtidig kigget loven igennem og henvist til den i et par fodnoter. Men ja det er nok ikke helt godt nok.
En web service er faktisk lidt ligesom RMI, bare: - den bruger HTTP som transport d.v.s. den kan nemmere gå gennem firewalls - den bruger et standard format SOAP d.v.s. at en .NET client kan snakke med en Java server
--> Arne 18/06-2003 09:46:40 (RAID 0+1) Hvis jeg forstår dig ret.... altså der skal være 2 diske (for at vi kan strippe) og så skal der være 2 diske (som mirror). Altså minimum fire diske i alt.
Det er jo forrygende med al den respons, jeg er virkelig taknemmelig :o) Måske jeg skulle hive lidt flere points op af skuffen.
Angående ssl igen.... hvis vi bruger ssl i en java applikation, så befinder vi os vel stadig i præsentations laget og ikke i applikationslaget (ifl osi modellen). Der sammen gælder vel hvis man bruger https? Altså det hele i følge osi modellen.
Så vil jeg gerne sige mange tak for hjælpen, så hvis Søren o lige smider et svar også kan han også få lidt points. Arne jeg har oprettet et spg mere med points til dig http://www.eksperten.dk/spm/366222
Vertikale lag i OSI eller TCP/IP er ikke det samme arkitektur.
Set fra et netværks synpunkt er SSL (HTTPS) et højt niveau i protokol stakken.
Men set fra en arkitektur synsvinkel er SSL (HTTPS) noget transport fordi det er transparent. Afsender kalder en metode med noget ukrypteret. Modtager kalder en metode og får det samme ukrypteret.
Hvordan funktionaliteten fordeler sig mellem SSL librariet, operativ systemets TCP/IP komponent og net kortet er sådan set ligegyldigt.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
