mboost-dp1

PBS A/S

NemID baseret på Javascript på vej

- Via Version2 - , redigeret af Net_Srak

Det kom fornyligt frem, at Digitaliseringsstyrelsen var i gang med at kigge på alternativer til Java som grundlag for NemID.

Nu ser det ud til, at Digitaliseringsstyrelsen ifølge en pressemeddelelse har taget et valg, hvor valget er faldet på Javascript. Digitaliseringsstyrelsen har gennem et længere forløb testet et proof-of-concept med NemID baseret på Javascript. Dette proof-of-concept har nu vist sig at NemID baseret på Javascript kan lade sig gøre. Det skriver Version2.

Charlotte Jacoby, Digitaliseringsstyrelsen skrev:
Vi er blevet enige med DanID og bankerne om at sætte gang i et forprojekt og afdække de sidste udfordringer, og så der kan tages beslutning om et endeligt udviklingsprojekt. Vi har fået lovende resultater i forhold til at bygge NemID-klienten i Javascript, selvom det er en helt anden teknologi end Java.

Det næste trin i processen er at lave et forprojekt med en varighed på fire måneder, hvor NemID med Javascript skal vurderes i forhold til økonomi og økosystemet omkring NemID. Efter forprojektet vil den endelige beslutning blive taget, hvorefter udviklingen af Javascript-løsningen går i gang. Ifølge Charlotte Jacoby vil NemID med Javascript være klar i løbet af 2013 eller i starten af 2014. Dog udtaler Charlotte Jacoby, at tidsplanen er meget usikker, da der endnu er mange udfordringer som skal løses.

Staten har tidligere sat otte millioner kroner af til projektet med at vurdere alternativer til Java i forbindelse med NemID, grundet den store kritik af Java som grundlag for NemID ved lanceringen. De penge er nu brugt, og det er derfor nødvendigt at rejse flere penge til udviklingen af NemID med Javascript.

Ved brugen af Javascript vil NemID også blive tilgængelig på mobile platforme, hvor det ikke tidligere har været muligt at bruge Java.





Gå til bund
Gravatar #51 - Chewy
28. jan. 2013 22:39
@ #50
så måske ville det være en god idé at have et backup login-system som lige kan sættes igang hvis NemID er nede.


Så endnu et projekt, der sideløbende kan overskride tidsgrænse samt budget gentagne gange, for derefter at ende ud med at være mere ustabilt end det system det skal være backup for...
Det lyder som en genial idé ;-)
Gravatar #52 - arne_v
28. jan. 2013 23:14
KILLER_BEE (11) skrev:
Min pointe var netop at det ikke har noget med NemId som sådat at gøre men whatever applikation bruger den.
Og det er vel ikke "generel problem på mobile enheder"..

Men udover det så må de gerne lave det om til JScript for min skyld... men argumentet at det er for at få det til at virke på mobile platforme er forkert...


Givet at de har en anden målsætning om at bruge samme løsning overalt, så betyder support for mobile enhder altså support for browsere på mobile enheder.
Gravatar #53 - arne_v
28. jan. 2013 23:16
gramps (14) skrev:
Hvorfor lave et forprojekt, når man har taget den beslutning, som forprojektet skulle ligge til grund for?


Det giver muligheden for at stoppe og omgøre beslutningen hvis der viser sig problemer.
Gravatar #54 - arne_v
28. jan. 2013 23:18
TrolleRolle (16) skrev:
når det i sin tid lykkedes dem at "opfinde" den tåbelige java-løsning selvom ALLE stod og skreg "Det er en dårlig ide med JAVA til den slags!",


Der blev skreget meget.

Men det var synd at sige at kvaliteten af kritikken var på niveau med volumen.
Gravatar #55 - arne_v
28. jan. 2013 23:19
Grofle (22) skrev:
Taget fra Wiki: "Newer and faster JavaScript VMs and frameworks built upon them (notably Node.js) have also increased the popularity of JavaScript for server-side web applications."


Det er rigtigt, men jeg tror ikke du skal regne med at DanID satser på node.js!
Gravatar #56 - gramps
28. jan. 2013 23:20
#53
Efter agile arbejdsgange, ja, men når man allerede har truffet beslutningen, så minder det som om de stadig benytter sig af vandfaldsmodellen.

Så lang tid burde det ikke tage at lave en god UML-analyse.
Gravatar #57 - arne_v
28. jan. 2013 23:22
gramps (25) skrev:
Ikke i clear-text, men så længe det er forsvarligt hashet og saltet, så gør det vel ikke spor.


Jeg tror at du blander nogle ting sammen.

Password bør gemmes saltet og hashet på server.

Password bør sendes krypteret fra client til server.

Gravatar #58 - arne_v
28. jan. 2013 23:24
brummie (30) skrev:
Ingen Java på mobil telefoner?? Har I hørte om noget der hedder Android? Mener du ikke ingen java på den LUKKET platform, iOS?


Man kan diskutere meget hvorvidt Dalvik er Java eller ej.

Men det kan ikke diskuteres at Android telefoner ikke understøtter Java applets.

Gravatar #59 - arne_v
28. jan. 2013 23:25
LordMike (34) skrev:
Det er så sværere at skjule / obsfuskere noget i JS da browseren nødvendigvist må have det i et parsable format (og ikke bytecode som med Java). Så på den front kan vi se frem til at kunne finde ud af hvordan NemID virker :)


NemID appletten kan godt decompiles, hvis du er meget nysgerrig.
Gravatar #60 - arne_v
28. jan. 2013 23:27
gramps (46) skrev:
Fordi man aldrig nogensinde sender noget som helst, der bruges til validering af en bruger, i cleartext.


Nej, man bruger HTTPS. Og det kræver ikke JavaScript. Så det er ikke forklaringen.
Gravatar #61 - arne_v
28. jan. 2013 23:28
gramps (56) skrev:
Så lang tid burde det ikke tage at lave en god UML-analyse.


Det er nok mere prototyper end UML der skal laves.
Gravatar #62 - gramps
28. jan. 2013 23:28
#57
Vel ikke kun almindeligt krypteret? Så er sikkerheden jo ikke større end ved almindelig opbevaring på serveren (bortset fra at passwordet kun "findes på internettet" i kort tid).
Gravatar #63 - arne_v
28. jan. 2013 23:44
#62

Jo. Det er helt normalt.

Der findes mere avancerede systemer (challenge response etc.).

Men helt banal HTTPS er hvad de fleste bruger til web.
Gravatar #64 - Laziter
29. jan. 2013 00:50
Chewy (51) skrev:
@ #50


Så endnu et projekt, der sideløbende kan overskride tidsgrænse samt budget gentagne gange, for derefter at ende ud med at være mere ustabilt end det system det skal være backup for...
Det lyder som en genial idé ;-)


Hehe kan faktisk godt se at min idé nok ikke lige var den bedste i verden. Nogle gange skal man tænke på samme idé 2 gange inden man lufter den..
Gravatar #65 - php
29. jan. 2013 06:59
hvis https ikke er nok kan man jo altid brug Rabbit i js

javascript er også det sprog vi bruger i fremtiden, alle ny platform have html 5/Ecmascript 5/css 3.
Gravatar #66 - Lowkey
29. jan. 2013 08:08
arne_v (60) skrev:
Nej, man bruger HTTPS. Og det kræver ikke JavaScript. Så det er ikke forklaringen.


Har du så et godt bud på hvorfor man skal bruge en client side teknologi?
Gravatar #67 - CoolMcGrrr
29. jan. 2013 22:23
Lowkey (66) skrev:
Har du så et godt bud på hvorfor man skal bruge en client side teknologi?


En del af pointen med NemID er at et site kan verificere hvem en person er uden at skulle modtage noget input fra den person som "logger ind" (Da disse informationer er fortrolige).

Dette skal hvertfald ikke køres server side da, der jo så ikke er noget der stopper alle de sites som er NemID Tjenesteudbydere (Hvilket de fleste sites kan blive) i at opsnappe information fra brugeren.

Synes man skulle tage et kig på hvordan OpenID/OAuth er implementeret og så lave en løsning der minder om det. Måske endda implementere NemID som OpenID/Oauth provider. (Googles SSO fungerer glimrende)

Så kan man bruge NemID på alle sites som understøtter de standarder. :)
Gravatar #68 - Slettet Bruger [2020942316]
29. jan. 2013 22:26
Lowkey (66) skrev:
Har du så et godt bud på hvorfor man skal bruge en client side teknologi?


Dumt spørgsmål, men kører NemIDs nuværende applet ikke på klienten? Er det så ikke en client-side teknologi?
Gravatar #69 - CoolMcGrrr
29. jan. 2013 22:41
Yvossen (68) skrev:
Dumt spørgsmål, men kører NemIDs nuværende applet ikke på klienten? Er det så ikke en client-side teknologi?


Jo, Java Appletten afvikles på din maskine.
Gravatar #70 - Lowkey
30. jan. 2013 09:10
#67

Men hvis man implementerer en Oauth-løsning, så bliver det da igen server side. Forskellen er dog at det kun er provideren man sender credentials til, men ikke desto mindre kræver det ikke noget særlig scripting på klientsiden.

Som jeg skrev tidligere, så virker Googles 2-factor verification som en ganske fin løsning, da den lige lægger et ekstra lag oven på den eksisterende username/password model. Det er oven i købet open source, så alle og enhver kan implementere det.
Google har så lagt en feature oven i, hvor man kan printe et ark med koder (lidt som den nuværende NemID løsning) eller få koder sendt via sms. På den måde skulle man kunne dække både dem med smartphones og gammeldags mobiltelefoner, samt dem der ikke har nogen af delene.

#68

Jo, både en java applet og javascript (hvis vi ser bort fra node.js osv) kører på klientsiden.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login