Most recent edit on 2007-11-12 03:58:54 by WebMaster

Additions:
Dette bilag angiver retningslinier for de to anbefalede integrationsformer Link og Iframe. I A.1 fremgår de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Link med single sign on (SSO), og de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Iframe, fremgår af A.2.
Bilagets retningslinier skal ses i sammenhæng med integrationsmodellens generelle afsnit om principper, brugsscenarier og tilhørende processer.
Integrationsmekanismen ”link” er den mest basale integrationsform, hvor portalen blot eksponerer en service via et HTML link. Når linket vælges i brugerens browser, videregives kontrollen til serviceudbyderen og al videre interaktion sker udenfor kontekst af portalen.
Denne type integration giver begrænsede muligheder for sammenspil mellem portalen og servicen, hvorfor retningslinierne er forholdsvist begrænsede.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via link vil optræde i portalen i følgende situationer

• Direkte link via redaktionelt indhold såsom en artikel eller andet.
• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Dødt link / serveren svarer ikke.
• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil der typisk blive åbnet et nyt browser vindue, hvori portalservicen vil blive vist. Dermed bliver portalservicen vist helt uden for portalens kontekst, og portalen har derfor heller ikke mulighed for at styre præsentationen.
Dette betyder at det er portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme. Det er også portalservicen selv der skal varetage adgangskontrol og sikre, at brugeren har de nødvendige rettigheder.
Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.
Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation bør al indhold på en webside benytte samme protokol. En portalservice på en webside, der benytter HTTPS bør derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URL’er
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Al indhold, dvs. alle portalservices og alle ressourcer på en portalside bør refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen blev først anvendt i AppleScript i 1993 og dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.1.2.3. Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Integrationsmodellen stiller ikke krav til hvordan fejlmeddelelser håndteres og præsenteres, når den vises i sit eget vindue.
Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der skal sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.

A.1.2.5. Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jævnfør ”Styling”.

1. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger

1. Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
2. Link til anden side på portalen, f.eks. for at vise relateret indhold.
3. Link, der peger på en side udenfor portalen.

Tips og begrænsninger
Portalen vedligeholder et antal sider der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalen for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2. Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.

Eksternt link, der åbner et nyt vindue

 <a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”> 

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.1.2.10. Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. font typer, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellen indeholder en præcisering af disse klasser i relation til de to portaler Borgerportalen og Virksomhedsportalen. Dette er beskrevet i et separat dokument.

1. Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.

A.1.2.12. Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet

Tips og begrænsninger
Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen kan afhænge af hvilken portal det drejer sig om. For den specifikke anvendelse henvises der til portaldokumentationen.

1. Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.1.2.13. Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles uden for portalen via et link.

A.1.2.14. Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
2. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret skal brugeroplysningerne gøres tilgængelige for de portalservices der udstilles, for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret på brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang.
Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.
Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.
IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservices, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke webservices i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.

Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via iFrame vil optræde i portalen i følgende situationer:

• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
• Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
• Dødt link / serveren svarer ikke.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil den blive vist i et selvstændigt iFrame inde i hovedsiden. Dette iFrame er ikke direkte koblet til hovedvinduet, hvilket betyder at portalen ikke længere styrer præsentationen, men at det er portalservicen selv der bestemmer indholdet. Desuden er det portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme, ligesom den selv skal varetage adgangskontrol og sikre at brugeren har de nødvendige rettigheder (se afsnittene ”Fejlmeddelelser og fejlhåndtering”, samt ”Adgangskontrol” for flere oplysninger).
Når portalservicen er blevet fremvist i dette iFrame, er der ikke længere nogen direkte interaktion med portalindholdet i hovedvinduet. Dette betyder i praksis at portalen ikke som udgangspunkt vil have mulighed for at indstille det øvrige indhold på siden efter hvad der vises i portalservicens undervindue.
Hvis portalservicen ønsker et sådan sammenspil - mellem iFrame indholdet og hovedsidens indhold - kan måden at facilitere dette på være, at iFramet initierer at hele portalsiden reloades gennem brug af alias, target=top samt ekstra parametre som hovedvindue og iFrame kan indstille sig efter. Hvorvidt der på den konkrete portalside er mulighed for at opnå dette sammenspil, afhænger af om portalens øvrige indhold reelt lytter på disse dynamiske parametre. Dette afklares i dialog med portalen.
Der er følgende navigationssituationer i forbindelse med at brugeren aktiverer et link i portalservicens iFrame:

• Portalservicen åbner et nyt vindue (popup) og viser noget indhold.

Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation skal al indhold på en portalside benytte samme protokol. En portalservice på en portalside, der benytter HTTPS må derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP. Portalservicen selv refereres også via samme protokol i sin iFrame.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URLer
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
5. Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
6. Links til sites udenfor portalen skal åbnes i et nyt vindue
7. Al indhold, dvs. alle services og alle ressourcer på en portalside skal refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
Applets udgør en udfordring i forhold til tilgængelighed og kan, hvis de ikke designes korrekt eller hvis der ikke stilles alternativer til rådighed, let forhindre funktionshæmmede brugere i at bruge portalen korrekt. Java applets kan designes med tilgængelighed for øje ved at overholde et sæt standard guidelines.
Teknologien ActiveX tillader kun afvikling på Microsoft platforme og da portalerne som udgangspunkt skal tillade andre operativsystemer end Windows må denne teknologi ikke benyttes. I stedet anbefales det at anvende Java eller Flash for hvilke der findes afviklere til flere platforme.

1. Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
2. ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
3. Java Applets skal kunne afvikles på JDK 1.4.
4. Shockwave Flash Applets skal kunne afvikles på version 8.
5. [TILGÆNGELIG]

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.2.2.3 Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl, der gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Hvis en serviceudbyder derimod ikke er tilgængelig, dvs. ikke giver et meningsfyldt svar tilbage til portalen eller overhovedet et svar, er det portalens opgave at vise en fejlbesked.
Integrationsmodellen definerer et style sheet i [OIMCSS], hvori der indgår en klasse til styling af fejltekster. Portalerne udnytter denne klasse i sammenhæng med andre visuelle retningslinjer til at angive hvordan fejltekster vises. Både portal og serviceudbyder skal overholde de visuelle guidelines for præsentation af fejltekster som defineret i designguiden.

1. Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
2. Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
3. Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
4. Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion

A.2.2.5 Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel skal portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Portalens designguidelines og styling for hjælpetekster skal anvendes.
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger

1. Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
2. Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger
Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
Link til anden side på portalen, f.eks. for at vise relateret indhold.
Link, der peger på en side udenfor portalen.
Tips og begrænsninger
Portalen vedligeholder et antal sider, som der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der pt. viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalejeren for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes, at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.
Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.
Link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”>

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.2.2.10 Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Navigation indenfor en iFrame i portalen, skal ske ved at portalservicen præsenterer sit skiftende indhold inden for samme portalside. Som udgangspunkt bør en portalservice ikke åbne nye vinduer i forbindelse med sit dialogforløb. Undtagelser kan dog fremgå af portalens designguidelines.

1. Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. fonttyper, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellens style sheet klasser [OIMCSS] bliver brugt af de to portaler i implementationen af disses respektive style sheets på en sådan måde at elementer logisk set er ens på tværs. F.eks. vil almindelig tekst i begge portaler styles med klassen ”portlet-font” selv om der måske benyttes forskellige font typer og størrelser. Der henvises til design guides for Borgerportalen og Virksomhedsportalen, samt de respektive CSS filer for yderligere information.
Det er tilladt en serviceudbyder at lave sit eget style sheet som supplement til det der udstilles af Portalen. Dette style sheet må ikke være i konflikt med portalens, men udelukkende definere udseendet af elementer der ikke på forhånd er fastlagt.

1. Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.

Anvendelse af integrationsmodellens style sheet klasse ”portlet-font”

<p style="background: blue; color: white;">Hvid på blå baggrund</p>

A.2.2.12 Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside.
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.

Tips og begrænsninger
Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen vil afhænge af hvilken portal det drejer sig om.
Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.2.2.13 Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles i eget iFrame i portalen.

A.2.2.14 Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder, der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
2. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret med portalen skal brugeroplysningerne gøres tilgængelige for de portalservices, der udstilles for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret på brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.

IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservicer, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke web services i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
   
   Deletions:
   cnomonrelch

Dette bilag angiver retningslinier for de to anbefalede integrationsformer Link og Iframe. I A.1 fremgår de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Link med single sign on (SSO), og de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Iframe, fremgår af A.2.
Bilagets retningslinier skal ses i sammenhæng med integrationsmodellens generelle afsnit om principper, brugsscenarier og tilhørende processer.
Integrationsmekanismen ”link” er den mest basale integrationsform, hvor portalen blot eksponerer en service via et HTML link. Når linket vælges i brugerens browser, videregives kontrollen til serviceudbyderen og al videre interaktion sker udenfor kontekst af portalen.
Denne type integration giver begrænsede muligheder for sammenspil mellem portalen og servicen, hvorfor retningslinierne er forholdsvist begrænsede.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via link vil optræde i portalen i følgende situationer

• Direkte link via redaktionelt indhold sÃ¥som en artikel eller andet.
• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Dødt link / serveren svarer ikke.
• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil der typisk blive åbnet et nyt browser vindue, hvori portalservicen vil blive vist. Dermed bliver portalservicen vist helt uden for portalens kontekst, og portalen har derfor heller ikke mulighed for at styre præsentationen.
Dette betyder at det er portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme. Det er også portalservicen selv der skal varetage adgangskontrol og sikre, at brugeren har de nødvendige rettigheder.
Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.
Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation bør al indhold på en webside benytte samme protokol. En portalservice på en webside, der benytter HTTPS bør derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URL’er
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Al indhold, dvs. alle portalservices og alle ressourcer på en portalside bør refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen blev først anvendt i AppleScript i 1993 og dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.1.2.3. Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Integrationsmodellen stiller ikke krav til hvordan fejlmeddelelser håndteres og præsenteres, når den vises i sit eget vindue.
Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der skal sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.

A.1.2.5. Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jævnfør ”Styling”.

1. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger

1. Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
2. Link til anden side på portalen, f.eks. for at vise relateret indhold.
3. Link, der peger på en side udenfor portalen.

Tips og begrænsninger
Portalen vedligeholder et antal sider der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalen for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2. Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.

Eksternt link, der åbner et nyt vindue

 <a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”> 

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.1.2.10. Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. font typer, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellen indeholder en præcisering af disse klasser i relation til de to portaler Borgerportalen og Virksomhedsportalen. Dette er beskrevet i et separat dokument.

1. Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.

A.1.2.12. Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet

Tips og begrænsninger
NÃ¥r portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen kan afhænge af hvilken portal det drejer sig om. For den specifikke anvendelse henvises der til portaldokumentationen.

1. Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.1.2.13. Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles uden for portalen via et link.

A.1.2.14. Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal ogsÃ¥ være til rÃ¥dighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
2. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret skal brugeroplysningerne gøres tilgængelige for de portalservices der udstilles, for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret pÃ¥ brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet pÃ¥ personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang.
Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.
Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.
IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservices, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke webservices i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.

Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via iFrame vil optræde i portalen i følgende situationer:

• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
• Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
• Dødt link / serveren svarer ikke.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil den blive vist i et selvstændigt iFrame inde i hovedsiden. Dette iFrame er ikke direkte koblet til hovedvinduet, hvilket betyder at portalen ikke længere styrer præsentationen, men at det er portalservicen selv der bestemmer indholdet. Desuden er det portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme, ligesom den selv skal varetage adgangskontrol og sikre at brugeren har de nødvendige rettigheder (se afsnittene ”Fejlmeddelelser og fejlhåndtering”, samt ”Adgangskontrol” for flere oplysninger).
Når portalservicen er blevet fremvist i dette iFrame, er der ikke længere nogen direkte interaktion med portalindholdet i hovedvinduet. Dette betyder i praksis at portalen ikke som udgangspunkt vil have mulighed for at indstille det øvrige indhold på siden efter hvad der vises i portalservicens undervindue.
Hvis portalservicen ønsker et sådan sammenspil - mellem iFrame indholdet og hovedsidens indhold - kan måden at facilitere dette på være, at iFramet initierer at hele portalsiden reloades gennem brug af alias, target=top samt ekstra parametre som hovedvindue og iFrame kan indstille sig efter. Hvorvidt der på den konkrete portalside er mulighed for at opnå dette sammenspil, afhænger af om portalens øvrige indhold reelt lytter på disse dynamiske parametre. Dette afklares i dialog med portalen.
Der er følgende navigationssituationer i forbindelse med at brugeren aktiverer et link i portalservicens iFrame:

• Portalservicen Ã¥bner et nyt vindue (popup) og viser noget indhold.

Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation skal al indhold på en portalside benytte samme protokol. En portalservice på en portalside, der benytter HTTPS må derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP. Portalservicen selv refereres også via samme protokol i sin iFrame.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URLer
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
5. Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
6. Links til sites udenfor portalen skal åbnes i et nyt vindue
7. Al indhold, dvs. alle services og alle ressourcer på en portalside skal refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
Applets udgør en udfordring i forhold til tilgængelighed og kan, hvis de ikke designes korrekt eller hvis der ikke stilles alternativer til rådighed, let forhindre funktionshæmmede brugere i at bruge portalen korrekt. Java applets kan designes med tilgængelighed for øje ved at overholde et sæt standard guidelines.
Teknologien ActiveX tillader kun afvikling på Microsoft platforme og da portalerne som udgangspunkt skal tillade andre operativsystemer end Windows må denne teknologi ikke benyttes. I stedet anbefales det at anvende Java eller Flash for hvilke der findes afviklere til flere platforme.

1. Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
2. ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
3. Java Applets skal kunne afvikles på JDK 1.4.
4. Shockwave Flash Applets skal kunne afvikles på version 8.
5. [TILGÆNGELIG]

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.2.2.3 Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl, der gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Hvis en serviceudbyder derimod ikke er tilgængelig, dvs. ikke giver et meningsfyldt svar tilbage til portalen eller overhovedet et svar, er det portalens opgave at vise en fejlbesked.
Integrationsmodellen definerer et style sheet i [OIMCSS], hvori der indgår en klasse til styling af fejltekster. Portalerne udnytter denne klasse i sammenhæng med andre visuelle retningslinjer til at angive hvordan fejltekster vises. Både portal og serviceudbyder skal overholde de visuelle guidelines for præsentation af fejltekster som defineret i designguiden.

1. Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
2. Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
3. Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
4. Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion

A.2.2.5 Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel skal portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Portalens designguidelines og styling for hjælpetekster skal anvendes.
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger

1. Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
2. Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger
Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
Link til anden side på portalen, f.eks. for at vise relateret indhold.
Link, der peger på en side udenfor portalen.
Tips og begrænsninger
Portalen vedligeholder et antal sider, som der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der pt. viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalejeren for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes, at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.
Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.
Link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”>

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.2.2.10 Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Navigation indenfor en iFrame i portalen, skal ske ved at portalservicen præsenterer sit skiftende indhold inden for samme portalside. Som udgangspunkt bør en portalservice ikke åbne nye vinduer i forbindelse med sit dialogforløb. Undtagelser kan dog fremgå af portalens designguidelines.

1. Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. fonttyper, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellens style sheet klasser [OIMCSS] bliver brugt af de to portaler i implementationen af disses respektive style sheets på en sådan måde at elementer logisk set er ens på tværs. F.eks. vil almindelig tekst i begge portaler styles med klassen ”portlet-font” selv om der måske benyttes forskellige font typer og størrelser. Der henvises til design guides for Borgerportalen og Virksomhedsportalen, samt de respektive CSS filer for yderligere information.
Det er tilladt en serviceudbyder at lave sit eget style sheet som supplement til det der udstilles af Portalen. Dette style sheet må ikke være i konflikt med portalens, men udelukkende definere udseendet af elementer der ikke på forhånd er fastlagt.

1. Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.

Anvendelse af integrationsmodellens style sheet klasse ”portlet-font”

<p style="background: blue; color: white;">Hvid på blå baggrund</p>

A.2.2.12 Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside.
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.

Tips og begrænsninger
NÃ¥r portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen vil afhænge af hvilken portal det drejer sig om.
Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.2.2.13 Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles i eget iFrame i portalen.

A.2.2.14 Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder, der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal ogsÃ¥ være til rÃ¥dighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
2. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret med portalen skal brugeroplysningerne gøres tilgængelige for de portalservices, der udstilles for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret pÃ¥ brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet pÃ¥ personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.

IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservicer, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke web services i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
   
   

   ---

   
   Edited on 2007-11-11 16:37:49 by ChitaDelpa
   
   Additions:
   cnomonrelch

Dette bilag angiver retningslinier for de to anbefalede integrationsformer Link og Iframe. I A.1 fremgår de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Link med single sign on (SSO), og de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Iframe, fremgår af A.2.
Bilagets retningslinier skal ses i sammenhæng med integrationsmodellens generelle afsnit om principper, brugsscenarier og tilhørende processer.
Integrationsmekanismen ”link” er den mest basale integrationsform, hvor portalen blot eksponerer en service via et HTML link. Når linket vælges i brugerens browser, videregives kontrollen til serviceudbyderen og al videre interaktion sker udenfor kontekst af portalen.
Denne type integration giver begrænsede muligheder for sammenspil mellem portalen og servicen, hvorfor retningslinierne er forholdsvist begrænsede.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via link vil optræde i portalen i følgende situationer

• Direkte link via redaktionelt indhold sÃ¥som en artikel eller andet.
• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Dødt link / serveren svarer ikke.
• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil der typisk blive åbnet et nyt browser vindue, hvori portalservicen vil blive vist. Dermed bliver portalservicen vist helt uden for portalens kontekst, og portalen har derfor heller ikke mulighed for at styre præsentationen.
Dette betyder at det er portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme. Det er også portalservicen selv der skal varetage adgangskontrol og sikre, at brugeren har de nødvendige rettigheder.
Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.
Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation bør al indhold på en webside benytte samme protokol. En portalservice på en webside, der benytter HTTPS bør derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URL’er
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Al indhold, dvs. alle portalservices og alle ressourcer på en portalside bør refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen blev først anvendt i AppleScript i 1993 og dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.1.2.3. Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Integrationsmodellen stiller ikke krav til hvordan fejlmeddelelser håndteres og præsenteres, når den vises i sit eget vindue.
Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der skal sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.

A.1.2.5. Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jævnfør ”Styling”.

1. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger

1. Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
2. Link til anden side på portalen, f.eks. for at vise relateret indhold.
3. Link, der peger på en side udenfor portalen.

Tips og begrænsninger
Portalen vedligeholder et antal sider der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalen for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2. Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.

Eksternt link, der åbner et nyt vindue

 <a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”> 

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.1.2.10. Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. font typer, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellen indeholder en præcisering af disse klasser i relation til de to portaler Borgerportalen og Virksomhedsportalen. Dette er beskrevet i et separat dokument.

1. Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.

A.1.2.12. Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet

Tips og begrænsninger
NÃ¥r portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen kan afhænge af hvilken portal det drejer sig om. For den specifikke anvendelse henvises der til portaldokumentationen.

1. Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.1.2.13. Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles uden for portalen via et link.

A.1.2.14. Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal ogsÃ¥ være til rÃ¥dighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
2. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret skal brugeroplysningerne gøres tilgængelige for de portalservices der udstilles, for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret pÃ¥ brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet pÃ¥ personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang.
Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.
Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.
IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservices, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke webservices i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.

Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via iFrame vil optræde i portalen i følgende situationer:

• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
• Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
• Dødt link / serveren svarer ikke.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil den blive vist i et selvstændigt iFrame inde i hovedsiden. Dette iFrame er ikke direkte koblet til hovedvinduet, hvilket betyder at portalen ikke længere styrer præsentationen, men at det er portalservicen selv der bestemmer indholdet. Desuden er det portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme, ligesom den selv skal varetage adgangskontrol og sikre at brugeren har de nødvendige rettigheder (se afsnittene ”Fejlmeddelelser og fejlhåndtering”, samt ”Adgangskontrol” for flere oplysninger).
Når portalservicen er blevet fremvist i dette iFrame, er der ikke længere nogen direkte interaktion med portalindholdet i hovedvinduet. Dette betyder i praksis at portalen ikke som udgangspunkt vil have mulighed for at indstille det øvrige indhold på siden efter hvad der vises i portalservicens undervindue.
Hvis portalservicen ønsker et sådan sammenspil - mellem iFrame indholdet og hovedsidens indhold - kan måden at facilitere dette på være, at iFramet initierer at hele portalsiden reloades gennem brug af alias, target=top samt ekstra parametre som hovedvindue og iFrame kan indstille sig efter. Hvorvidt der på den konkrete portalside er mulighed for at opnå dette sammenspil, afhænger af om portalens øvrige indhold reelt lytter på disse dynamiske parametre. Dette afklares i dialog med portalen.
Der er følgende navigationssituationer i forbindelse med at brugeren aktiverer et link i portalservicens iFrame:

• Portalservicen Ã¥bner et nyt vindue (popup) og viser noget indhold.

Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation skal al indhold på en portalside benytte samme protokol. En portalservice på en portalside, der benytter HTTPS må derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP. Portalservicen selv refereres også via samme protokol i sin iFrame.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URLer
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
5. Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
6. Links til sites udenfor portalen skal åbnes i et nyt vindue
7. Al indhold, dvs. alle services og alle ressourcer på en portalside skal refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
Applets udgør en udfordring i forhold til tilgængelighed og kan, hvis de ikke designes korrekt eller hvis der ikke stilles alternativer til rådighed, let forhindre funktionshæmmede brugere i at bruge portalen korrekt. Java applets kan designes med tilgængelighed for øje ved at overholde et sæt standard guidelines.
Teknologien ActiveX tillader kun afvikling på Microsoft platforme og da portalerne som udgangspunkt skal tillade andre operativsystemer end Windows må denne teknologi ikke benyttes. I stedet anbefales det at anvende Java eller Flash for hvilke der findes afviklere til flere platforme.

1. Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
2. ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
3. Java Applets skal kunne afvikles på JDK 1.4.
4. Shockwave Flash Applets skal kunne afvikles på version 8.
5. [TILGÆNGELIG]

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.2.2.3 Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl, der gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Hvis en serviceudbyder derimod ikke er tilgængelig, dvs. ikke giver et meningsfyldt svar tilbage til portalen eller overhovedet et svar, er det portalens opgave at vise en fejlbesked.
Integrationsmodellen definerer et style sheet i [OIMCSS], hvori der indgår en klasse til styling af fejltekster. Portalerne udnytter denne klasse i sammenhæng med andre visuelle retningslinjer til at angive hvordan fejltekster vises. Både portal og serviceudbyder skal overholde de visuelle guidelines for præsentation af fejltekster som defineret i designguiden.

1. Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
2. Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
3. Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
4. Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion

A.2.2.5 Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel skal portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Portalens designguidelines og styling for hjælpetekster skal anvendes.
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger

1. Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
2. Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger
Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
Link til anden side på portalen, f.eks. for at vise relateret indhold.
Link, der peger på en side udenfor portalen.
Tips og begrænsninger
Portalen vedligeholder et antal sider, som der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der pt. viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalejeren for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes, at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.
Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.
Link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”>

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.2.2.10 Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Navigation indenfor en iFrame i portalen, skal ske ved at portalservicen præsenterer sit skiftende indhold inden for samme portalside. Som udgangspunkt bør en portalservice ikke åbne nye vinduer i forbindelse med sit dialogforløb. Undtagelser kan dog fremgå af portalens designguidelines.

1. Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. fonttyper, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellens style sheet klasser [OIMCSS] bliver brugt af de to portaler i implementationen af disses respektive style sheets på en sådan måde at elementer logisk set er ens på tværs. F.eks. vil almindelig tekst i begge portaler styles med klassen ”portlet-font” selv om der måske benyttes forskellige font typer og størrelser. Der henvises til design guides for Borgerportalen og Virksomhedsportalen, samt de respektive CSS filer for yderligere information.
Det er tilladt en serviceudbyder at lave sit eget style sheet som supplement til det der udstilles af Portalen. Dette style sheet må ikke være i konflikt med portalens, men udelukkende definere udseendet af elementer der ikke på forhånd er fastlagt.

1. Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.

Anvendelse af integrationsmodellens style sheet klasse ”portlet-font”

<p style="background: blue; color: white;">Hvid på blå baggrund</p>

A.2.2.12 Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside.
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.

Tips og begrænsninger
NÃ¥r portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen vil afhænge af hvilken portal det drejer sig om.
Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.2.2.13 Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles i eget iFrame i portalen.

A.2.2.14 Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder, der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal ogsÃ¥ være til rÃ¥dighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
2. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret med portalen skal brugeroplysningerne gøres tilgængelige for de portalservices, der udstilles for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret pÃ¥ brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet pÃ¥ personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.

IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservicer, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke web services i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
   
   Deletions:
   Dette bilag angiver retningslinier for de to anbefalede integrationsformer Link og Iframe. I A.1 fremgår de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Link med single sign on (SSO), og de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Iframe, fremgår af A.2.

Bilagets retningslinier skal ses i sammenhæng med integrationsmodellens generelle afsnit om principper, brugsscenarier og tilhørende processer.
Integrationsmekanismen ”link” er den mest basale integrationsform, hvor portalen blot eksponerer en service via et HTML link. Når linket vælges i brugerens browser, videregives kontrollen til serviceudbyderen og al videre interaktion sker udenfor kontekst af portalen.
Denne type integration giver begrænsede muligheder for sammenspil mellem portalen og servicen, hvorfor retningslinierne er forholdsvist begrænsede.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via link vil optræde i portalen i følgende situationer

• Direkte link via redaktionelt indhold såsom en artikel eller andet.
• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Dødt link / serveren svarer ikke.
• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil der typisk blive åbnet et nyt browser vindue, hvori portalservicen vil blive vist. Dermed bliver portalservicen vist helt uden for portalens kontekst, og portalen har derfor heller ikke mulighed for at styre præsentationen.
Dette betyder at det er portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme. Det er også portalservicen selv der skal varetage adgangskontrol og sikre, at brugeren har de nødvendige rettigheder.
Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.
Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation bør al indhold på en webside benytte samme protokol. En portalservice på en webside, der benytter HTTPS bør derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URL’er
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Al indhold, dvs. alle portalservices og alle ressourcer på en portalside bør refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen blev først anvendt i AppleScript i 1993 og dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.1.2.3. Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Integrationsmodellen stiller ikke krav til hvordan fejlmeddelelser håndteres og præsenteres, når den vises i sit eget vindue.
Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der skal sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.

A.1.2.5. Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jævnfør ”Styling”.

1. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger

1. Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
2. Link til anden side på portalen, f.eks. for at vise relateret indhold.
3. Link, der peger på en side udenfor portalen.

Tips og begrænsninger
Portalen vedligeholder et antal sider der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalen for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2. Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.

Eksternt link, der åbner et nyt vindue

 <a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”> 

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.1.2.10. Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. font typer, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellen indeholder en præcisering af disse klasser i relation til de to portaler Borgerportalen og Virksomhedsportalen. Dette er beskrevet i et separat dokument.

1. Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.

A.1.2.12. Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet

Tips og begrænsninger
Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen kan afhænge af hvilken portal det drejer sig om. For den specifikke anvendelse henvises der til portaldokumentationen.

1. Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.1.2.13. Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles uden for portalen via et link.

A.1.2.14. Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
2. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret skal brugeroplysningerne gøres tilgængelige for de portalservices der udstilles, for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret på brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang.
Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.
Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.
IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservices, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke webservices i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.

Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol
Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.
Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.
Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:
Navn på portalservice</td></tr><tr><td>
Navn på den organisation der ejer servicen</td></tr><tr><td>
Præsentationsnavn</td><td>
Kort præsentationsnavn</td><td>
Til præsentation af søgeresultater</td></tr><tr><td>
Til illustration af afsenderen i forbindelse med præsentation af servicen</td></tr><tr><td>
Præsentation og søgning af service ud fra type</td></tr><tr><td>
Præsentation og søgning af service ud fra kategori</td></tr><tr><td>
Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki</td></tr><tr><td>
Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.</td></tr><tr><td>
Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.</td></tr><tr><td>
URL til fejlside, hvis portalservicen ikke er tilgængelig</td></tr><tr><td>
Titel på side hvor portalservicen indgår</td></tr><tr><td>
Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk</td></tr><tr><td>
Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

En portalservice der er integreret ind i portalen via iFrame vil optræde i portalen i følgende situationer:

• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
• Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
• Dødt link / serveren svarer ikke.

Tips og begrænsninger
I forbindelse med at portalservicen tilgås vil den blive vist i et selvstændigt iFrame inde i hovedsiden. Dette iFrame er ikke direkte koblet til hovedvinduet, hvilket betyder at portalen ikke længere styrer præsentationen, men at det er portalservicen selv der bestemmer indholdet. Desuden er det portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme, ligesom den selv skal varetage adgangskontrol og sikre at brugeren har de nødvendige rettigheder (se afsnittene ”Fejlmeddelelser og fejlhåndtering”, samt ”Adgangskontrol” for flere oplysninger).
Når portalservicen er blevet fremvist i dette iFrame, er der ikke længere nogen direkte interaktion med portalindholdet i hovedvinduet. Dette betyder i praksis at portalen ikke som udgangspunkt vil have mulighed for at indstille det øvrige indhold på siden efter hvad der vises i portalservicens undervindue.
Hvis portalservicen ønsker et sådan sammenspil - mellem iFrame indholdet og hovedsidens indhold - kan måden at facilitere dette på være, at iFramet initierer at hele portalsiden reloades gennem brug af alias, target=top samt ekstra parametre som hovedvindue og iFrame kan indstille sig efter. Hvorvidt der på den konkrete portalside er mulighed for at opnå dette sammenspil, afhænger af om portalens øvrige indhold reelt lytter på disse dynamiske parametre. Dette afklares i dialog med portalen.
Der er følgende navigationssituationer i forbindelse med at brugeren aktiverer et link i portalservicens iFrame:

• Portalservicen åbner et nyt vindue (popup) og viser noget indhold.

Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation skal al indhold på en portalside benytte samme protokol. En portalservice på en portalside, der benytter HTTPS må derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP. Portalservicen selv refereres også via samme protokol i sin iFrame.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URLer
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4. Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
5. Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
6. Links til sites udenfor portalen skal åbnes i et nyt vindue
7. Al indhold, dvs. alle services og alle ressourcer på en portalside skal refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.
Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger
Applets udgør en udfordring i forhold til tilgængelighed og kan, hvis de ikke designes korrekt eller hvis der ikke stilles alternativer til rådighed, let forhindre funktionshæmmede brugere i at bruge portalen korrekt. Java applets kan designes med tilgængelighed for øje ved at overholde et sæt standard guidelines.
Teknologien ActiveX tillader kun afvikling på Microsoft platforme og da portalerne som udgangspunkt skal tillade andre operativsystemer end Windows må denne teknologi ikke benyttes. I stedet anbefales det at anvende Java eller Flash for hvilke der findes afviklere til flere platforme.

1. Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
2. ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
3. Java Applets skal kunne afvikles på JDK 1.4.
4. Shockwave Flash Applets skal kunne afvikles på version 8.
5. [TILGÆNGELIG]

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.
Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger
For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.
En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

A.2.2.3 Fejlmeddelelser og fejlhåndtering

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.
Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.
Tekniske fejl, der gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.
Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger
Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.
Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.
Hvis en serviceudbyder derimod ikke er tilgængelig, dvs. ikke giver et meningsfyldt svar tilbage til portalen eller overhovedet et svar, er det portalens opgave at vise en fejlbesked.
Integrationsmodellen definerer et style sheet i [OIMCSS], hvori der indgår en klasse til styling af fejltekster. Portalerne udnytter denne klasse i sammenhæng med andre visuelle retningslinjer til at angive hvordan fejltekster vises. Både portal og serviceudbyder skal overholde de visuelle guidelines for præsentation af fejltekster som defineret i designguiden.

1. Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
2. Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
3. Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
4. Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.
En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger
Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.
Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion

A.2.2.5 Hjælpetekster – online hjælp

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger
Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.
En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.
Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.
Hvis en portalservice anvender portalens look-and-feel skal portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.

1. Serviceudbyderen bør implementere hjælpesider.
2. Portalens designguidelines og styling for hjælpetekster skal anvendes.
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger

1. Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
2. Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger
Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
Link til anden side på portalen, f.eks. for at vise relateret indhold.
Link, der peger på en side udenfor portalen.
Tips og begrænsninger
Portalen vedligeholder et antal sider, som der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der pt. viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.
Serviceudbyderen kan kontakte portalejeren for at få en komplet liste af alias og information om den konkrete syntaks.
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Det skal bemærkes, at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.
Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.
Link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”>

Eksempler på alias links
http://portal.dk/alias?alias=avanceret_søgning∞

A.2.2.10 Navigation og dialogforløb

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger
Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).
Navigation indenfor en iFrame i portalen, skal ske ved at portalservicen præsenterer sit skiftende indhold inden for samme portalside. Som udgangspunkt bør en portalservice ikke åbne nye vinduer i forbindelse med sit dialogforløb. Undtagelser kan dog fremgå af portalens designguidelines.

1. Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. fonttyper, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger
Integrationsmodellens style sheet klasser [OIMCSS] bliver brugt af de to portaler i implementationen af disses respektive style sheets på en sådan måde at elementer logisk set er ens på tværs. F.eks. vil almindelig tekst i begge portaler styles med klassen ”portlet-font” selv om der måske benyttes forskellige font typer og størrelser. Der henvises til design guides for Borgerportalen og Virksomhedsportalen, samt de respektive CSS filer for yderligere information.
Det er tilladt en serviceudbyder at lave sit eget style sheet som supplement til det der udstilles af Portalen. Dette style sheet må ikke være i konflikt med portalens, men udelukkende definere udseendet af elementer der ikke på forhånd er fastlagt.

1. Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.

Anvendelse af integrationsmodellens style sheet klasse ”portlet-font”

<p style="background: blue; color: white;">Hvid på blå baggrund</p>

A.2.2.12 Søgning

Der er 3 primære navigationsveje til en portalservice via portalen:

1. Dynamisk liste af portalservices angivet på en konkret portalside.
2. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.

Tips og begrænsninger
Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.
Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.
I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.
Den konkrete anvendelse og præsentation af oplysningerne om portalservicen vil afhænge af hvilken portal det drejer sig om.
Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.2.2.13 Tegnsæt

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger
Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles i eget iFrame i portalen.

A.2.2.14 Tilgængelighed

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder, der ikke fandtes på det tidspunkt websitet blev designet.
I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger
IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).
WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.
En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.

1. Portalservices bør levere markup på WAI niveau AA.

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:
Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:
Java Applet, der viser antal udfyldte formularer …
Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

• Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• [TILGÆNGELIG]
• [OIOVÆRKTØJ]

Tips og begrænsninger
Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.
En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.

1. Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
2. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger
Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.
Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.
En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

1. Serviceudbyderen skal selv forestå autorisationscheck decentralt.

Når en bruger er blevet autentificeret med portalen skal brugeroplysningerne gøres tilgængelige for de portalservices, der udstilles for at muliggøre personalisering, revision og rettighedscheck.
Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger
Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

• Certificate Serial Number: Serienummeret på brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.

1. En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.
Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger
Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.

IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservicer, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke web services i første omgang.
Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.
Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger
Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.
Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
   
   

   ---

   
   Edited on 2007-10-17 06:43:00 by KristianHjortMadsen
   
   Additions:
   Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.

Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation bør al indhold på en webside benytte samme protokol. En portalservice på en webside, der benytter HTTPS bør derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URL’er
2. Al indhold, dvs. alle portalservices og alle ressourcer på en portalside bør refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang.
Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.
Browsere vil normalt reagere med en advarsel hvis en HTTPS sikret side refererer en ressource, dvs. en anden HTML side, et billede, etc. over en usikker HTTP forbindelse. For at undgå denne situation skal al indhold på en portalside benytte samme protokol. En portalservice på en portalside, der benytter HTTPS må derfor udelukkende referere ressourcer via HTTP. Tilsvarende overvejelser gælder for portalsider der benytter HTTP. Portalservicen selv refereres også via samme protokol i sin iFrame.

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvendes relative eller absolutte URLer
2. Links til sites udenfor portalen skal åbnes i et nyt vindue
3. Al indhold, dvs. alle services og alle ressourcer på en portalside skal refereres via samme protokol som portalsiden selv, dvs. HTTP eller HTTPS.

Serviceudbydere, der indgår i SSO føderationen skal sikre at logning foretages i overenstemmelse med Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser.
   
   Deletions:
   Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.
2. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvende relative eller absolutte url’s

Serviceudbydere, der indgår i SSO føderationen skal overholde retningslinjerne vedrørende logning fra IT- og Telestyrelsen [LOGNING], der bla baserer sig på Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. [LOGNING] anviser en mulig mekanisme til dette.
Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]..

• [LOGNING]
• Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvende relative eller absolutte url’s
• Links til sites udenfor portalen skal åbnes i et nyt vindue

Serviceudbydere, der indgår i SSO føderationen skal overholde retningslinjerne vedrørende logning fra IT- og Telestyrelsen [LOGNING], der bla baserer sig på Persondataloven [PERSLOV] og DS-484 [DS484].
Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. [LOGNING] anviser en mulig mekanisme til dette.

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]
2. [LOGNING]
   
   

   ---

   
   Edited on 2007-09-03 02:01:57 by KristianHjortMadsen
   
   Additions:
   Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.

Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.

Deletions:
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame og WSRP) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.
Link, iFrame, WSRP</td></tr><tr><td>
Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame og WSRP) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.

---

Edited on 2007-09-03 02:00:19 by KristianHjortMadsen

Additions:
Link, iFrame</td></tr><tr><td>

---

Edited on 2007-09-02 15:50:32 by KristianHjortMadsen

Additions:

A.1.2.9. Markup

A.1.2.10. Navigation og dialogforløb

1. Ingen supplerende retningslinier ud over dem som er indeholdt i [WAI] samt i portalernes design guidelines
2. [WAI]

A.1.2.11. Styling

1. Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.

A.1.2.12. Søgning

1. Links i redaktionelt indhold
2. Dynamisk liste af portalservices angivet på en konkret portalside
3. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet
4. Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.

A.1.2.13. Tegnsæt

A.1.2.14. Tilgængelighed

1. Portalservices bør levere markup på WAI niveau AA.

 <img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo"> 

<OBJECT classid="java:Counter.class" width="200" height="200">
</OBJECT>

• Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• Header elementer skal bruges til at angive dokumentstrukturen og i overensstemmelse med specifikationen [Prioritet AA (2)]
• [TILGÆNGELIG]
• [WAI]
• [OIOVÆRKTØJ]

A.1.2.15. Upload og download af indhold

1. Serviceudbyder skal selv lagre indhold til upload.
2. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

A.1.3. Sikkerhed

A.1.3.1. Adgangskontrol

1. Portalen skal varetage en overordnet adgangskontrol.
2. Serviceudbyderen skal selv forestå autorisationscheck decentralt.
3. Serviceudbyderen kan benytte attributter fra SAML kuverten med brugeroplysninger til autorisation.
4. Serviceudbyderen kan benytte andre registre til autorisation efter behov.

A.1.3.2.Brugeroplysninger

• Common Name: Navnet den person som certifikatet er udstedt til.
• Certificate Serial Number: Serienummeret på brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• CVR Number: Virksomhedens CVR nummer for medarbejdercertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.
• En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

A.1.3.3. Logning

Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]..
Serviceudbyderen skal sikre loggen mod uautoriseret adgang.

• [LOGNING]
• [PERSLOV]
• [DS484] afsnit 10.10 ff

A.1.3.4. Single Signon (SSO)

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.

A.2 Retningslinier for integrationsformen Iframe

Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.

A.2.1 Integration af service i portalen

A.2.1.1 Registrering af portalservice

1. [DIA]
2. [LTS]
3. [MYNDIGHEDSNET]
4. [OMBORGER]

A.2.1.2. Interaktion med portalen

• Som link i indholdsside, som er tilknyttet nogle emneord der matcher portalservicen.
• Direkte link via redaktionelt indhold f.eks. en artikel.
• Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.
• Portalservicen svarer og alt virker som det skal.
• Portalservicen svarer, men brugeren er ikke logget ind
• Portalservicen linker til ny side i egen portalservice, som vises i eget undervindue.
• Portalservicen åbner et nyt vindue (popup) og viser noget indhold.
• Portalservicen linker til en fil (audio, video, pdf, andet).
• Portalservicen linker til ny side som vises i hovedvinduet.
• Portalservicen reloader aktuelle hovedside med supplerende url parametre
• Portalservicen linker til indhold uden for portalen
• Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
• Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
• Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
• Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
• Links til sites udenfor portalen skal åbnes i et nyt vindue

A.2.2 Visuel Integration

A.2.2.1 Applets

1. Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
2. ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
3. Java Applets skal kunne afvikles på JDK 1.4.
4. Shockwave Flash Applets skal kunne afvikles på version 8.
5. [JAVAACCESS]
6. [TILGÆNGELIG]

A.2.2.2 Cookies

A.2.2.3 Fejlmeddelelser og fejlhåndtering

1. Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
2. Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
3. Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
4. Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.

A.2.2.4. Globalisering: Internationalisering og Lokalisering

1. En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion

A.2.2.5 Hjælpetekster – online hjælp

1. Portalens designguidelines og styling for hjælpetekster skal anvendes.

A.2.2.6. Informative meddelelser

1. Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
2. Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.

A.2.2.7 Javascript

A.2.2.8. Links

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”>

A.2.2.9 Markup

A.2.2.10 Navigation og dialogforløb

1. Navigation indenfor en iFrame portalservice skal ske i rammerne af en specifik portalside der fastholdes.
2. Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades

A.2.2.11 Styling

1. Integrationsmodellens style sheet klasser skal anvendes til styling.
2. Portalens design guidelines for hvordan style sheet klasserne fortolkes skal anvendes
3. Serviceudbyder kan bruge egne style sheets efter aftale med portalen.
4. Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.
5. Serviceudbyderes egne styles skal indlejres direkte i markup og kan ikke linkes eksternt fra.

<div class="portlet-font">Vigtig information</div>

<p style="background: blue; color: white;">Hvid på blå baggrund</p>

• [HTML40] sektion 12.3

A.2.2.12 Søgning

1. Links i redaktionelt indhold.
2. Dynamisk liste af portalservices angivet på en konkret portalside.
3. Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.

A.2.2.13 Tegnsæt

A.2.2.14 Tilgængelighed

1. Portalservices bør levere markup på WAI niveau AA.

<img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo">

<OBJECT classid="java:Counter.class" width="200" height="200">
</OBJECT>

• Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
• Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
• Header elementer skal bruges til at angive dokumentstrukturen og i overensstemmelse med specifikationen [Prioritet AA (2)]
• [TILGÆNGELIG]
• [WAI]
• [OIOVÆRKTØJ]

A.2.2.15 Upload og download af indhold

1. Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
2. Serviceudbyder skal selv lagre indhold til upload.
3. Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
4. Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.

A.2.3 Sikkerhed

A.2.3.1 Adgangskontrol

1. Portalen skal varetage overordnet adgangskontrol.
2. Serviceudbyderen skal selv forestå autorisationscheck decentralt.
3. Serviceudbyderen kan benytte attributter fra SAML kuverten med brugeroplysninger til autorisation.
4. Serviceudbyderen kan benytte andre registre til autorisation efter behov.

A.2.3.2. Brugeroplysninger

• Common Name: Navnet den person som certifikatet er udstedt til.
• Certificate Serial Number: Serienummeret på brugerens certifikat.
• Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
• PID Number: Det unikke løbenummer for personcertifikater.
• CVR Number: Virksomhedens CVR nummer for medarbejdercertifikater.
• RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
• Subject Serial Number: Løbenummer fra certifikatet.
• En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.

A.2.3.3. Logning

1. Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]
2. Serviceudbyderen skal sikre loggen mod uautoriseret adgang.
3. [LOGNING]
4. [PERSLOV]
5. [DS484] afsnit 10.10 ff

A.2.3.4 Single Signon (SSO)

1. Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
   
   Deletions:
   9.Markup

Beskrivelse
1.Ingen retningslinier

10.Navigation og dialogforløb
Beskrivelse
1.Ingen supplerende retningslinier ud over dem som er indeholdt i [WAI] samt i portalernes design guidelines
[WAI]
[MYNDIGHEDSNET]
[OMBORGER]
11.Styling
Beskrivelse
1.Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.
[OIMCSS]
12.Søgning
Beskrivelse
1.Links i redaktionelt indhold
2.Dynamisk liste af portalservices angivet på en konkret portalside
3.Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet
1.Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.
13.Tegnsæt
Beskrivelse
1.Ingen retningslinier
14.Tilgængelighed
Beskrivelse
1.Portalservices bør levere markup på WAI niveau AA.
<img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo">
<OBJECT classid="java:Counter.class" width="200" height="200">
</OBJECT>
Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
Header elementer skal bruges til at angive dokumentstrukturen og i overensstemmelse med specifikationen [Prioritet AA (2)]
[TILGÆNGELIG]
[WAI]
[OIOVÆRKTØJ]
15.Upload og download af indhold
Beskrivelse
1.Serviceudbyder skal selv lagre indhold til upload.
2.Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3.Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.
[OMBORGER]
[MYNDIGHEDSNET]
3Sikkerhed
1.Adgangskontrol
Beskrivelse
1.Portalen skal varetage en overordnet adgangskontrol.
2.Serviceudbyderen skal selv forestå autorisationscheck decentralt.
3.Serviceudbyderen kan benytte attributter fra SAML kuverten med brugeroplysninger til autorisation.
4.Serviceudbyderen kan benytte andre registre til autorisation efter behov.
[DKSAML20]
2.Brugeroplysninger
Beskrivelse
Common Name: Navnet den person som certifikatet er udstedt til.
Certificate Serial Number: Serienummeret på brugerens certifikat.
Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
PID Number: Det unikke løbenummer for personcertifikater.
CVR Number: Virksomhedens CVR nummer for medarbejdercertifikater.
RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
Subject Serial Number: Løbenummer fra certifikatet.
1.En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.
[DKSAML20]
3.Logning
Beskrivelse
1.Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]..
2.Serviceudbyderen skal sikre loggen mod uautoriseret adgang.
[LOGNING]
[PERSLOV]
[DS484] afsnit 10.10 ff
4.Single Signon (SSO)
Beskrivelse
1.Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
[DKSAML20]
A.2 Retningslinier for integrationsformen Iframe
Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.
1Integration af service i portalen
Registrering af portalservice
Beskrivelse
1.Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2.Portalservicen skal være tilgængelig via en statisk URL
3.En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4.Logo skal have en fast størrelse
1.[DIA]
2.[LTS]
3.[MYNDIGHEDSNET]
4.[OMBORGER]
Interaktion med portalen
Beskrivelse
Som link i indholdsside, som er tilknyttet nogle emneord der matcher portalservicen.
Direkte link via redaktionelt indhold f.eks. en artikel.
Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.
Portalservicen svarer og alt virker som det skal.
Portalservicen svarer, men brugeren er ikke logget ind
Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
Portalservicen svarer med en HTTP fejlkode.
Dødt link / serveren svarer ikke.
Portalservicen linker til ny side i egen portalservice, som vises i eget undervindue.
Portalservicen åbner et nyt vindue (popup) og viser noget indhold.
Portalservicen linker til en fil (audio, video, pdf, andet).
Portalservicen linker til ny side som vises i hovedvinduet.
Portalservicen reloader aktuelle hovedside med supplerende url parametre
Portalservicen linker til indhold uden for portalen
1.Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvende relative eller absolutte url’s
2.Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3.Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4.Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
5.Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
6.Links til sites udenfor portalen skal åbnes i et nyt vindue
[MYNDIGHEDSNET]
[OMBORGER]
2Visuel Integration
Applets
Beskrivelse
Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
Java Applets skal kunne afvikles på JDK 1.4.
Shockwave Flash Applets skal kunne afvikles på version 8.
[JAVAACCESS]
[TILGÆNGELIG]
Cookies
Beskrivelse
Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
Serviceudbydere kan frit brug cookies der ikke influerer på SSO.
[DKSAML20]
Fejlmeddelelser og fejlhåndtering
Beskrivelse
Serviceudbydere skal fange applikationsfejl og vise fejltekster.
Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.
[MYNDIGHEDSNET]
[OMBORGER]
[OIMCSS]
Globalisering: Internationalisering og Lokalisering
Beskrivelse
Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion
[W3CI18N]
Hjælpetekster – online hjælp
Beskrivelse
Serviceudbyderen bør implementere hjælpesider.
Portalens designguidelines og styling for hjælpetekster skal anvendes.
Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
Hjælpetekster bør tilbyde kontekstsensitiv information.
Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.
[MYNDIGHEDSNET]
[OMBORGER]
Informative meddelelser
Beskrivelse
Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.
[OIMCSS]
[MYNDIGHEDSNET]
[OMBORGER]
Javascript
Beskrivelse
Ingen retningslinier
Links
Beskrivelse
<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html�∞� target=”_blank”>
Markup
Beskrivelse
Ingen retningslinier

Navigation og dialogforløb
Beskrivelse
Navigation indenfor en iFrame portalservice skal ske i rammerne af en specifik portalside der fastholdes.
Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades
[MYNDIGHEDSNET]
[OMBORGER]
Styling
Beskrivelse
Integrationsmodellens style sheet klasser skal anvendes til styling.
Portalens design guidelines for hvordan style sheet klasserne fortolkes skal anvendes
Serviceudbyder kan bruge egne style sheets efter aftale med portalen.
Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.
Serviceudbyderes egne styles skal indlejres direkte i markup og kan ikke linkes eksternt fra.
<div class="portlet-font">Vigtig information</div>
<p style="background: blue; color: white;">Hvid på blå baggrund</p>
[OIMCSS]
[HTML40] sektion 12.3
[MYNDIGHEDSNET]
[OMBORGER]
Søgning
Beskrivelse
Links i redaktionelt indhold.
Dynamisk liste af portalservices angivet på en konkret portalside.
Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.
Tegnsæt
Beskrivelse
Ingen retningslinier
Tilgængelighed
Beskrivelse
Portalservices bør levere markup på WAI niveau AA.
<img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo">
<OBJECT classid="java:Counter.class" width="200" height="200">
</OBJECT>
Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
Header elementer skal bruges til at angive dokumentstrukturen og i overensstemmelse med specifikationen [Prioritet AA (2)]
[TILGÆNGELIG]
[WAI]
[OIOVÆRKTØJ]
Upload og download af indhold
Beskrivelse
Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
Serviceudbyder skal selv lagre indhold til upload.
Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.
[OMBORGER]
[MYNDIGHEDSNET]
3Sikkerhed
Adgangskontrol
Beskrivelse
1.Portalen skal varetage overordnet adgangskontrol.
2.Serviceudbyderen skal selv forestå autorisationscheck decentralt.
3.Serviceudbyderen kan benytte attributter fra SAML kuverten med brugeroplysninger til autorisation.
4.Serviceudbyderen kan benytte andre registre til autorisation efter behov.
[DKSAML20]
Brugeroplysninger
Beskrivelse
Common Name: Navnet den person som certifikatet er udstedt til.
Certificate Serial Number: Serienummeret på brugerens certifikat.
Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
PID Number: Det unikke løbenummer for personcertifikater.
CVR Number: Virksomhedens CVR nummer for medarbejdercertifikater.
RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
Subject Serial Number: Løbenummer fra certifikatet.
1.En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.
[DKSAML20]
Logning
Beskrivelse
1.Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]
2.Serviceudbyderen skal sikre loggen mod uautoriseret adgang.
[LOGNING]
[PERSLOV]
[DS484] afsnit 10.10 ff
Single Signon (SSO)
Beskrivelse
1.Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
[DKSAML20]

---

Edited on 2007-09-02 15:12:33 by KristianHjortMadsen

Additions:

 <a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html” target=”_blank”> 

---

Edited on 2007-09-02 14:49:44 by KristianHjortMadsen

Additions:
Oplysning</td><td>
Anvendelse</td></tr><tr><td>
Retningslinier

1. Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2. Portalservicen skal være tilgængelig via en statisk URL
3. En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4. Logo skal have en fast størrelse

Referencer

• [DIA]
• [LTS]
• [MYNDIGHEDSNET]
• [OMBORGER]

A.1.1.2. Interaktion med portalen

• Som link i indholdsside der er tilknyttet nogle emneord der matcher portalservicen.
• Direkte link via redaktionelt indhold såsom en artikel eller andet.
• Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
• Portalservicen svarer og alt virker som det skal.
• Dødt link / serveren svarer ikke.
• Portalservicen svarer med en HTTP fejlkode.
• Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
• Portalservicen svarer, men brugeren er ikke logget ind.

Retningslinier

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvende relative eller absolutte url’s
2. Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3. Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).

Referencer

• [MYNDIGHEDSNET]
• [OMBORGER]

A.1.2 Visuel Integration

A.1.2.1. Applets

Retningslinier

1. Ingen retningslinier

Referencer

A.1.2.2. Cookies

Retningslinier

1. Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2. Serviceudbydere kan frit brug cookies der ikke influerer på SSO.

Referencer

• [DKSAML20]

A.1.2.3. Fejlmeddelelser og fejlhåndtering

Retningslinier

1. Serviceudbydere skal fange applikationsfejl og vise fejltekster.

Referencer

• [MYNDIGHEDSNET]
• [OMBORGER]
• [OIMCSS]

A.1.2.4. Globalisering: Internationalisering og Lokalisering

1. Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2. En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.

Referencer

• [W3CI18N]

A.1.2.5. Hjælpetekster – online hjælp

Retningslinier

1. Serviceudbyderen bør implementere hjælpesider.
2. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3. Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4. Hjælpetekster bør tilbyde kontekstsensitiv information.
5. Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.

Referencer

• [MYNDIGHEDSNET]
• [OMBORGER]

A.1.2.6. Informative meddelelser

Retningslinier

1. Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].

Referencer

• [OIMCSS]
• [MYNDIGHEDSNET]
• [OMBORGER]

A.1.2.7. Javascript

Retningslinier

1. Ingen retningslinier

Referencer

A.1.2.8. Links

1. Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
2. Link til anden side på portalen, f.eks. for at vise relateret indhold.
3. Link til en specifik portalservice indlejret i en portalside.
4. Link til en artikel eller et dokument.
5. Link, der peger på en side udenfor portalen.

Retningslinier

1. Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2. Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.

Eksempler
Referencer

Deletions:
Oplysning</td><td>
Anvendelse</td></tr><tr><td>
[DIA]
[LTS]
2.Interaktion med portalen
Som link i indholdsside der er tilknyttet nogle emneord der matcher portalservicen.
Direkte link via redaktionelt indhold såsom en artikel eller andet.
Portalservicen svarer og alt virker som det skal.
Portalservicen svarer, men brugeren er ikke logget ind.
2.Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3.Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
1.Applets
2.Cookies
1.Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2.Serviceudbydere kan frit brug cookies der ikke influerer på SSO.
3.Fejlmeddelelser og fejlhåndtering
1.Serviceudbydere skal fange applikationsfejl og vise fejltekster.
4.Globalisering: Internationalisering og Lokalisering
1.Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2.En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.
5.Hjælpetekster – online hjælp
1.Serviceudbyderen bør implementere hjælpesider.
2.Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3.Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4.Hjælpetekster bør tilbyde kontekstsensitiv information.
5.Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.
6.Informative meddelelser
1.Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
7.Javascript
8.Links
1.Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2.Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.

---

Oldest known version of this page was edited on 2007-09-02 14:36:42 by KristianHjortMadsen []

Bilag A Anbefalede integrationsformer

Dette bilag angiver retningslinier for de to anbefalede integrationsformer Link og Iframe. I A.1 fremgår de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Link med single sign on (SSO), og de retningslinier, der gælder for integration af en portalservice ved hjælp af integrationsformen Iframe, fremgår af A.2.

Bilagets retningslinier skal ses i sammenhæng med integrationsmodellens generelle afsnit om principper, brugsscenarier og tilhørende processer.

A.1 Retningslinier for integrationsformen Link

Integrationsmekanismen ”link” er den mest basale integrationsform, hvor portalen blot eksponerer en service via et HTML link. Når linket vælges i brugerens browser, videregives kontrollen til serviceudbyderen og al videre interaktion sker udenfor kontekst af portalen.

Denne type integration giver begrænsede muligheder for sammenspil mellem portalen og servicen, hvorfor retningslinierne er forholdsvist begrænsede.

En portal kan specificere yderligere retningslinjer, der supplerer integrationsmodellens anvisninger og som i givet fald skal overholdes.

A.1.1. Integration af service i portalen

A.1.1.1. Registrering af portalservice

Beskrivelse
Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol

Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.

Tips og begrænsninger
Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.

Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:

Oplysning	Anvendelse
Servicenavn	Navn på portalservice
Ejer	Navn på den organisation der ejer servicen
Kontaktinfo	Kontaktinformation til den organisation der ejer servicen
Beskrivelse	Tekstuel beskrivelse
Aktiv status	Indikation af om portalservicen er aktiv/inaktiv
Præsentationsnavn	Til titel, overskrift, lister osv.
Kort præsentationsnavn	Til alternativ tekst, bla.
Kort beskrivende tekst	Til præsentation af søgeresultater
Afsender logo	Til illustration af afsenderen i forbindelse med præsentation af servicen
Afsender navn	Til alternativ tekst i forbindelse med logo
Type	Typen af service: webside, pdf, doc, etc.
Integrationsmetode	Link, iFrame, WSRP
Emnetype	Præsentation og søgning af service ud fra type
Emnekategori	Præsentation og søgning af service ud fra kategori
Liste af emneord	Fremsøgning med udgangspunkt i specifik emneklassifikation / topic hierarki
Stikord	Understøtter fritekstsøgning, uden at være bundet til en specifik emneklassifikation.
URL	URL til portalservicen
Alternativ URL	Alternativ, direkte link som portalservicen kan nås via f.eks. i forbindelse med fejlhåndtering.
Fejlside URL	URL til fejlside, hvis portalservicen ikke er tilgængelig
Side titel	Titel på side hvor portalservicen indgår
Dynamiske parametre	Markering af om portalservicen kan modtage "dynamiske" parametre, eller om linket altid skal være statisk
Brugergruppe	Adgangskrav - udtrykt i en rolle-klassifikation styret af portalen

Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.
Retningslinier

1.Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2.Portalservicen skal være tilgængelig via en statisk URL
3.En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4.Logo skal have en fast størrelse
Referencer

[DIA]
[LTS]
[MYNDIGHEDSNET]
[OMBORGER]


2.Interaktion med portalen
Beskrivelse

En portalservice der er integreret ind i portalen via link vil optræde i portalen i følgende situationer

Som link i indholdsside der er tilknyttet nogle emneord der matcher portalservicen.
Direkte link via redaktionelt indhold såsom en artikel eller andet.
Fremsøgning ud fra tekst, emneord, kommunekode eller andet.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

Portalservicen svarer og alt virker som det skal.
Dødt link / serveren svarer ikke.
Portalservicen svarer med en HTTP fejlkode.
Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
Portalservicen svarer, men brugeren er ikke logget ind.
Tips og begrænsninger

I forbindelse med at portalservicen tilgås vil der typisk blive åbnet et nyt browser vindue, hvori portalservicen vil blive vist. Dermed bliver portalservicen vist helt uden for portalens kontekst, og portalen har derfor heller ikke mulighed for at styre præsentationen.

Dette betyder at det er portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme. Det er også portalservicen selv der skal varetage adgangskontrol og sikre, at brugeren har de nødvendige rettigheder.

Når portalservicen er blevet fremvist i det nye browser vindue, er der ikke længere nogen interaktion med portalen.
Retningslinier

1.Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvende relative eller absolutte url’s
2.Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3.Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
Referencer

[MYNDIGHEDSNET]
[OMBORGER]

2Visuel Integration

1.Applets
Beskrivelse

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen blev først anvendt i AppleScript i 1993 og dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.

Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.

Tips og begrænsninger

Eftersom portalservicen vises i eget browservindue, stiller integrationsmodellen ingen krav i denne forbindelse.

Retningslinier

1.Ingen retningslinier
Referencer




2.Cookies
Beskrivelse

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.

Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger

For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.

En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.
Retningslinier

1.Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
2.Serviceudbydere kan frit brug cookies der ikke influerer på SSO.
Referencer

[DKSAML20]


3.Fejlmeddelelser og fejlhåndtering
Beskrivelse

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.

Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.

Tekniske fejl gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.

Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger

Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.

Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.

Integrationsmodellen stiller ikke krav til hvordan fejlmeddelelser håndteres og præsenteres, når den vises i sit eget vindue.
Retningslinier

1.Serviceudbydere skal fange applikationsfejl og vise fejltekster.
Referencer

[MYNDIGHEDSNET]
[OMBORGER]
[OIMCSS]


4.Globalisering: Internationalisering og Lokalisering
Beskrivelse

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der skal sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.

En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger

Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.

Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.
Retningslinier

1.Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
2.En portalservice, der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion.
Referencer

[W3CI18N]


5.Hjælpetekster – online hjælp
Beskrivelse

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger

Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.

En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.

Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.

Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.
Retningslinier

1.Serviceudbyderen bør implementere hjælpesider.
2.Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for hjælpetekster anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
3.Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
4.Hjælpetekster bør tilbyde kontekstsensitiv information.
5.Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.
Referencer

[MYNDIGHEDSNET]
[OMBORGER]

6.Informative meddelelser
Beskrivelse

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger

Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.

Hvis en portalservice anvender portalens look-and-feel bør portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jævnfør ”Styling”.
Retningslinier

1.Hvis portalservicen følger portalens design, bør portalens designguidelines og styling for informative meddelelser anvendes, samt Integrationsmodellens CSS klasser defineret i [OIMCSS].
Referencer

[OIMCSS]
[MYNDIGHEDSNET]
[OMBORGER]


7.Javascript
Beskrivelse

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.
Tips og begrænsninger

Integrationsmodellen stiller ingen krav i forhold til anvendelse af javascript for de portalservices som afvikles uden for portalen via et link.
Retningslinier

1.Ingen retningslinier
Referencer




8.Links
Beskrivelse

Portalservices kan anvende links til forskellige former for navigation:

Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
Link til anden side på portalen, f.eks. for at vise relateret indhold.
Link til en specifik portalservice indlejret i en portalside.
Link til en artikel eller et dokument.
Link, der peger på en side udenfor portalen.

Tips og begrænsninger

Portalen vedligeholder et antal sider der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.

Serviceudbyderen kan kontakte portalen for at få en komplet liste af alias og information om den konkrete syntaks.

Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame og WSRP) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.

Det skal bemærkes at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

Serviceudbyderen har ansvaret for at sikre, at links til andre portalsider og eksterne websites er valide.
Retningslinier

1.Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
2.Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.
Eksempler

Eksternt link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html�∞� target=”_blank”>

Eksempler på alias links

http://portal.dk/alias?alias=forside∞
http://portal.dk/alias?alias=myndighedsoversigt∞
http://portal.dk/alias?alias=avanceret_søgning∞
http://portal.dk/alias?alias=vejviser∞
http://portal.dk/artikel?id=123123∞
http://portal.dk/service?id=4719∞
Referencer



9.Markup
Beskrivelse

Integrationsmodellen stiller ingen krav i forhold til anvendelse af HTML, XML og metadata for de portalservices som afvikles uden for portalen via et link.
Retningslinier

1.Ingen retningslinier
Referencer




10.Navigation og dialogforløb
Beskrivelse

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger

Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).


Retningslinier

1.Ingen supplerende retningslinier ud over dem som er indeholdt i [WAI] samt i portalernes design guidelines
Referencer

[WAI]
[MYNDIGHEDSNET]
[OMBORGER]


11.Styling
Beskrivelse

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. font typer, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.

Tips og begrænsninger

Integrationsmodellen indeholder en præcisering af disse klasser i relation til de to portaler Borgerportalen og Virksomhedsportalen. Dette er beskrevet i et separat dokument.

Hvis en ekstern portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til styling af indhold. Alternativt skal portalens designguidelines og integrationsmodellens styling [OIMCSS] anvendes.
Retningslinier

1.Hvis portalservicen følger portalens design, skal portalens designguidelines og integrationsmodellens styling klasser anvendes.
Referencer

[OIMCSS]

12.Søgning
Beskrivelse

Der er 3 primære navigationsveje til en portalservice via portalen:

1.Links i redaktionelt indhold
2.Dynamisk liste af portalservices angivet på en konkret portalside
3.Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet
Tips og begrænsninger

Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.

Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.

I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.

Den konkrete anvendelse og præsentation af oplysningerne om portalservicen kan afhænge af hvilken portal det drejer sig om. For den specifikke anvendelse henvises der til portaldokumentationen.
Retningslinier

1.Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.
Referencer




13.Tegnsæt
Beskrivelse

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger

Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles uden for portalen via et link.
Retningslinier

1.Ingen retningslinier
Referencer




14.Tilgængelighed
Beskrivelse

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder der ikke fandtes på det tidspunkt websitet blev designet.

I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger

IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).

WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.

En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.
Retningslinier

1.Portalservices bør levere markup på WAI niveau AA.
Eksempler

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:

<img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo">

Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:

<OBJECT classid="java:Counter.class" width="200" height="200">
Java Applet, der viser antal udfyldte formularer …
</OBJECT>

Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
Header elementer skal bruges til at angive dokumentstrukturen og i overensstemmelse med specifikationen [Prioritet AA (2)]
Referencer

[TILGÆNGELIG]
[WAI]
[OIOVÆRKTØJ]


15.Upload og download af indhold
Beskrivelse

En serviceudbyder kan have behov for at afspille film eller lyd for brugeren, modtage filer via upload eller tillade download af dokumenter og lignende.
Tips og begrænsninger

Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.

En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.
Retningslinier

1.Serviceudbyder skal selv lagre indhold til upload.
2.Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
3.Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.
Referencer

[OMBORGER]
[MYNDIGHEDSNET]

3Sikkerhed

1.Adgangskontrol
Beskrivelse

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger

Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.

Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

De roller som brugeren er tildelt i portalen, medsendes ikke til portalservicen. Den adgangsdifferentiering som evt. skal ske i portalservicen, skal ske via portalservicens egne lokale rettighedsoplysninger.
Retningslinier

1.Portalen skal varetage en overordnet adgangskontrol.
2.Serviceudbyderen skal selv forestå autorisationscheck decentralt.
3.Serviceudbyderen kan benytte attributter fra SAML kuverten med brugeroplysninger til autorisation.
4.Serviceudbyderen kan benytte andre registre til autorisation efter behov.
Referencer

[DKSAML20]


2.Brugeroplysninger
Beskrivelse

Når en bruger er blevet autentificeret skal brugeroplysningerne gøres tilgængelige for de portalservices der udstilles, for at muliggøre personalisering, revision og rettighedscheck.

Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger

IT- og Telestyrelsens DK-SAML 2.0 [DKSAML] profil definerer de brugeroplysninger som serviceudbyder har adgang til.

Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

Common Name: Navnet den person som certifikatet er udstedt til.
Certificate Serial Number: Serienummeret på brugerens certifikat.
Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
PID Number: Det unikke løbenummer for personcertifikater.
CVR Number: Virksomhedens CVR nummer for medarbejdercertifikater.
RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.
Retningslinier

1.En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.
Referencer

[DKSAML20]



3.Logning
Beskrivelse

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.

Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger

Serviceudbydere, der indgår i SSO føderationen skal overholde retningslinjerne vedrørende logning fra IT- og Telestyrelsen [LOGNING], der bla baserer sig på Persondataloven [PERSLOV] og DS-484 [DS484].

Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. [LOGNING] anviser en mulig mekanisme til dette.

Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.
Retningslinier

1.Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]..
2.Serviceudbyderen skal sikre loggen mod uautoriseret adgang.
Referencer

[LOGNING]
[PERSLOV]
[DS484] afsnit 10.10 ff


4.Single Signon (SSO)
Beskrivelse

IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservices, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke webservices i første omgang.

Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.

Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger

Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.

Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.
Retningslinier

1.Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
Referencer

[DKSAML20]


A.2 Retningslinier for integrationsformen Iframe
Portalservices, der integreres ind i portalen via iFrame vises i et delområde af det browservindue som udgør portalens hovedvindue. For at brugeren skal opleve portalen som et samlet hele, er det nødvendigt at løsninger der integreres med iFrame så vidt muligt følger portalens regler for design og navigation, til trods for at de reelt er udviklet og drevet af den eksterne serviceudbyder.

Integrationsmodellen definerer retningslinier for brugen af iFrame som integrationsform, og disse retningslinier er beskrevet i dette dokument.

En portal kan specificere yderligere retningslinjer, der supplerer integrationsmodellens anvisninger og som i givet fald skal overholdes.
1Integration af service i portalen

Registrering af portalservice
Beskrivelse

Førend en portalservice kan blive tilgængelig via portalen skal den indregistreres. I forbindelse med denne registrering angives en række informationer, der er afgørende for hvordan portalservicen præsenteres på portalen. Nogle af disse informationer er ligeledes afgørende for hvilke lister og søgninger servicen kan fremfindes under, hvordan servicen håndteres i forbindelse med fejl, samt overordnet adgangskontrol

Hvilke der aktuelt understøttes, afhænger af hvilken portal servicen tilmeldes.

Tips og begrænsninger

Indregistreringen foretages af portalejeren og serviceudbyderen i samarbejde bla. via et specifikt værktøj – for Borgerportalens vedkommende, ”LTS” og for Virksomhedsportalen, ”DIA-tool”.

Hvilke oplysninger der skal angives, og om det er portalejeren eller serviceudbyderen der angiver dem, vil afhænge af portalen. Listen nedenfor indeholder de oplysninger der som minimum er nødvendige:


Hvordan disse oplysninger anvendes i portalen kan serviceudbyder få et overblik over ved at læse den relevante dokumentation fra portalen. Heri vil man også kunne finde oplysninger om hvilke øvrige parametre der evt. skal oplyses ved registreringen, samt hvordan det i praksis foregår.

Retningslinier

1.Portalservicen skal tilmeldes til portalen, førend den bliver tilgængelig
2.Portalservicen skal være tilgængelig via en statisk URL
3.En portalservice der indeholder flere tjenester som relaterer sig til hver sine områder, og dermed forskellige emneord osv., skal tilmeldes flere gange, således at det er muligt ud fra brugernes valg at opbygge det korrekte dybe link til den specifikke tjeneste
4.Logo skal have en fast størrelse
Referencer

1.[DIA]
2.[LTS]
3.[MYNDIGHEDSNET]
4.[OMBORGER]


Interaktion med portalen
Beskrivelse

En portalservice der er integreret ind i portalen via iFrame vil optræde i portalen i følgende situationer:

Som link i indholdsside, som er tilknyttet nogle emneord der matcher portalservicen.
Direkte link via redaktionelt indhold f.eks. en artikel.
Fremsøgning ud fra tekst, emneord, kommunekode eller andet.
Præsentation af portalservicen i sammenhæng med øvrigt portal indhold.

I forbindelse med at brugeren vælger at tilgå portalservicen, vil der kunne opstå følgende situationer:

Portalservicen svarer og alt virker som det skal.
Portalservicen svarer, men brugeren er ikke logget ind
Portalservicen svarer, men brugeren har utilstrækkelige privilegier.
Portalservicen svarer med en HTTP fejlkode.
Dødt link / serveren svarer ikke.

Tips og begrænsninger

I forbindelse med at portalservicen tilgås vil den blive vist i et selvstændigt iFrame inde i hovedsiden. Dette iFrame er ikke direkte koblet til hovedvinduet, hvilket betyder at portalen ikke længere styrer præsentationen, men at det er portalservicen selv der bestemmer indholdet. Desuden er det portalservicen selv der skal håndtere alle de fejlsituationer der kan forekomme, ligesom den selv skal varetage adgangskontrol og sikre at brugeren har de nødvendige rettigheder (se afsnittene ”Fejlmeddelelser og fejlhåndtering”, samt ”Adgangskontrol” for flere oplysninger).

Når portalservicen er blevet fremvist i dette iFrame, er der ikke længere nogen direkte interaktion med portalindholdet i hovedvinduet. Dette betyder i praksis at portalen ikke som udgangspunkt vil have mulighed for at indstille det øvrige indhold på siden efter hvad der vises i portalservicens undervindue.

Hvis portalservicen ønsker et sådan sammenspil - mellem iFrame indholdet og hovedsidens indhold - kan måden at facilitere dette på være, at iFramet initierer at hele portalsiden reloades gennem brug af alias, target=top samt ekstra parametre som hovedvindue og iFrame kan indstille sig efter. Hvorvidt der på den konkrete portalside er mulighed for at opnå dette sammenspil, afhænger af om portalens øvrige indhold reelt lytter på disse dynamiske parametre. Dette afklares i dialog med portalen.

Der er følgende navigationssituationer i forbindelse med at brugeren aktiverer et link i portalservicens iFrame:

Portalservicen linker til ny side i egen portalservice, som vises i eget undervindue.
Portalservicen åbner et nyt vindue (popup) og viser noget indhold.
Portalservicen linker til en fil (audio, video, pdf, andet).
Portalservicen linker til ny side som vises i hovedvinduet.
Portalservicen reloader aktuelle hovedside med supplerende url parametre
Portalservicen linker til indhold uden for portalen

Retningslinier

1.Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Hvis der ikke eksisterer et alias, anvende relative eller absolutte url’s
2.Portalservicen skal selv håndtere fejlsituationer (se afsnittet ”Fejlmeddelelser og fejlhåndering” for yderligere information).
3.Portalservicen skal selv håndtere adgangskontrol (se afsnittet ”Adgangskontrol” for yderligere information).
4.Portalservicen må ikke skifte hovedvinduet væk fra portalen, men må gerne skifte hovedvinduet til en anden portalside
5.Links til andre sider på portalen skal benytte samme browservindue og må ikke åbne et nyt.
6.Links til sites udenfor portalen skal åbnes i et nyt vindue
Referencer

[MYNDIGHEDSNET]
[OMBORGER]


2Visuel Integration

Applets
Beskrivelse

Applets er små applikationer, der kører i kontekst af et andet program, i dette tilfælde en web browser. Termen dækker over en række konkrete teknologier herunder Java Applets, ActiveX kontroller, Flash, mm.

Brugeroplevelsen kan gøres rigere ved anvendelsen af applets, men teknologierne fordrer dog ofte at der downloades et 3.parts plugin til browseren.
Tips og begrænsninger

Applets udgør en udfordring i forhold til tilgængelighed og kan, hvis de ikke designes korrekt eller hvis der ikke stilles alternativer til rådighed, let forhindre funktionshæmmede brugere i at bruge portalen korrekt. Java applets kan designes med tilgængelighed for øje ved at overholde et sæt standard guidelines.

Teknologien ActiveX tillader kun afvikling på Microsoft platforme og da portalerne som udgangspunkt skal tillade andre operativsystemer end Windows må denne teknologi ikke benyttes. I stedet anbefales det at anvende Java eller Flash for hvilke der findes afviklere til flere platforme.
Retningslinier

Applets må ikke anvendes med mindre det eksplicit aftales med portalejeren.
ActiveX kontroller bør ikke anvendes på portalen. Undtagelser aftales med portalejeren.
Java Applets skal kunne afvikles på JDK 1.4.
Shockwave Flash Applets skal kunne afvikles på version 8.
Referencer

[JAVAACCESS]
[TILGÆNGELIG]

Cookies
Beskrivelse

En cookie er en tekststreng, angivet som små nøgle+værdi par, der tillader et website at gemme information lokalt på brugerens maskine, f.eks. ”landekode=dk”. Per konvention vil browseren sende cookies der tilhører et bestemt domæne tilbage til serveren ved hvert request. Cookies der tilhører andre domæner medsendes ikke.

Mekanismen anvendes typisk til at opretholde en brugersession, til load balancering og til at registrere brugeradfærd og er ofte en fundamental præmis for et websites funktion.
Tips og begrænsninger

For at kunne indgå i SSO føderationen er det nødvendigt at service udbyderen kan håndtere en såkaldt ”common domain cookie” (se [DKSAML20] for yderligere information). Det betyder desuden at brugerens browser skal have cookie-understøttelse slået til for at single-signon virker.

En serviceudbyder må bruge cookies efter behov så længe de ikke influerer på SSO føderationens virkemåde.
Retningslinier

Serviceudbydere skal kunne håndtere SSO føderationens behov for cookies.
Serviceudbydere kan frit brug cookies der ikke influerer på SSO.
Referencer

[DKSAML20]

Fejlmeddelelser og fejlhåndtering
Beskrivelse

Under drift af portalen kan der opstå forskellige fejlsituationer: der kan være kommunikationsproblemer, så serviceudbyderens portalservice aldrig bliver kaldt; der kan være interne problemer i portalservicen etc. Der skelnes mellem applikationsfejl og tekniske fejl.

Applikationsfejl skyldes omstændigheder, som applikationen har taget højde for og kan håndtere, f.eks. manglende information, forkert information, manglende forbindelse til services, etc.

Tekniske fejl, der gør en portalservice utilgængelig og kan forekomme på portalen, i netværket mellem portal og serviceudbyder og internt hos serviceudbyderen. I alle tilfælde er slutresultatet at portalservicen ikke kan vises korrekt.

Fejl kan opstå hos både serviceudbyder og portal og slutbrugeren har i begge tilfælde brug for at opdage det og kunne reagere fornuftigt på situationen.
Tips og begrænsninger

Når der opstår fejl er det vigtigt at brugeren får så præcis information som muligt, dvs. at der er opstået en fejl, hvilke konsekvenser fejlen har og hvordan fejlen kan eller vil blive udbedret. Dette er dels en tekstuel formidlingsopgave, hvor der skal laves tekster for hver af disse egenskaber per fejltype, dels en visuel formidlingsopgave, som fordrer ensartethed i præsentationen af fejl. Slutbrugeren må under ingen omstændigheder udsættes for interne detaljer om fejlen, f.eks. tekniske koder, stack traces og lignende.

Ved applikationsfejl, skal serviceudbyderen selv sørge for at fange fejlen og vise en meningsfyldt fejltekst for slutbrugeren.

Hvis en serviceudbyder derimod ikke er tilgængelig, dvs. ikke giver et meningsfyldt svar tilbage til portalen eller overhovedet et svar, er det portalens opgave at vise en fejlbesked.

Integrationsmodellen definerer et style sheet i [OIMCSS], hvori der indgår en klasse til styling af fejltekster. Portalerne udnytter denne klasse i sammenhæng med andre visuelle retningslinjer til at angive hvordan fejltekster vises. Både portal og serviceudbyder skal overholde de visuelle guidelines for præsentation af fejltekster som defineret i designguiden.
Retningslinier

Serviceudbydere skal fange applikationsfejl og vise fejltekster.
Fejltekster skal være læselige af slutbrugere, dvs. de må ikke indeholde tekniske koder, stack traces, etc.
Fejltekster bør angive information om årsagen til fejlen, konsekvenser, samt hvordan eller hvornår fejlen udbedres.
Fejltekster skal overholde portalernes styling guidelines fra designguiden vedr. præsentation af fejl.
Portalen bør håndtere fejl der opstår i forbindelse med at en portalservice ikke er tilgængelig.
Referencer

[MYNDIGHEDSNET]
[OMBORGER]
[OIMCSS]


Globalisering: Internationalisering og Lokalisering
Beskrivelse

Globalisering er en betegnelse for det at udvikle et softwaresystem, der er et tænkt til verdensomspændende distribution. Termen kombinerer to aspekter af dette arbejde: internationalisering (ofte forkortet i18n), der sikrer at systemet bygges uden sprog- eller kulturbarrierer, samt lokalisering, hvori systemet oversættes og designes til at håndtere en specifik lokalitet.

En lokalitet er det største geografiske område, der dækker samme sæt af kulturelle præferencer og er typisk karakteriseret ved et bestemt sprog, møntfod, tegnsæt, måleenheder, mm.
Tips og begrænsninger

Portalen designes ud fra i18n principper, så de i princippet vil kunne understøtte flere lokaliteter. I gældende version understøttes dog udelukkende lokaliteten da-DK, dvs. sproget dansk, dansk møntfod, dansk tegnsæt og danske måleenheder.

Det er ikke et krav at serviceudbydere laver understøttelse af i18n, men W3Cs retningslinier for i18n [W3CI18N] bør følges hvis understøttelse implementeres.
Retningslinier

Serviceudbydere kan udvikle iframede løsninger med support for i18n, men portalen tilbyder kun da-DK som understøttet lokalitet
En portalservice der understøtter flere forskellige sprogversioner, skal tilmeldes én gang pr. sprogversion
Referencer

[W3CI18N]


Hjælpetekster – online hjælp
Beskrivelse

En bruger kan have behov for at søge hjælp til anvendelsen af en portalservice.
Tips og begrænsninger

Serviceudbydere er selv ansvarlige for at stille sider til rådighed, der beskriver eller demonstrerer hvordan portalservicen skal bruges.

En evt vejledning skal som minimum give brugeren information om hvad portalservicens formål er, samt en kort introduktion til hvordan den anvendes. Det anbefales at hjælpeteksten giver så præcis information i brugskonteksten som muligt.

Hvis en portalservice er implementeret med eget look-and-feel indeholder integrationsmodellen ingen retningslinier i forhold til etablering af hjælpetekster.

Hvis en portalservice anvender portalens look-and-feel skal portalens designguidelines og styling [OIMCSS] for hjælpetekster anvendes jf ”Styling”.
Retningslinier

Serviceudbyderen bør implementere hjælpesider.
Portalens designguidelines og styling for hjælpetekster skal anvendes.
Hjælpetekster skal som minimum beskrive portalservicens formål og give en kort introduktion til dens virkemåde.
Hjælpetekster bør tilbyde kontekstsensitiv information.
Hjælpetekster kan være så omfattende som serviceudbyderen ønsker.
Referencer

[MYNDIGHEDSNET]
[OMBORGER]

Informative meddelelser
Beskrivelse

En portalservice har ind i mellem brug for at vise en informativ besked til brugeren, f.eks. ”vent et øjeblik” eller ”formularen er nu oprettet og sendt til kommunen”. For at sikre genkendeligheden på tværs af portalservices og dermed en bedre brugeroplevelse, ensretter Integrationsmodellen udseendet af disse beskeder.
Tips og begrænsninger

Hvis en portalservice har brug for at vise en informativ tekst til slutbrugeren, er det portalservicen selv der danner markup. Integrationsmodellen definerer i [OIMCSS] CSS klasser til brug ved rendering af informativ tekst, som bruges i disse situationer efter portalens designguidelines.
Retningslinier

Serviceudbyder skal følge Integrationsmodellens CSS klasser defineret i [OIMCSS] for rendering af informative beskeder
Serviceudbyder skal følge portalens designguidelines for rendering af informative beskeder.
Referencer

[OIMCSS]
[MYNDIGHEDSNET]
[OMBORGER]


Javascript
Beskrivelse

Moderne websites benytter sig i stigende omfang af client-side scripting faciliteter til at berige brugerens oplevelse og gøre grænsefladen mere interaktiv. Javascript er en af kerneteknologierne i denne bevægelse.

Tips og begrænsninger

Integrationsmodellen stiller ingen krav i forhold til anvendelse af javascript for de portalservices som afvikles i eget iFrame i browseren.
Retningslinier

Ingen retningslinier
Referencer




Links
Beskrivelse

Portalservices kan anvende links til forskellige former for navigation:

Link, der peger tilbage på portalservicen selv med en evt. tilstandsændring, f.eks. ”næste side”.
Link til anden side på portalen, f.eks. for at vise relateret indhold.
Link til en specifik portalservice indlejret i en portalside.
Link til en artikel eller et dokument.
Link, der peger på en side udenfor portalen.

Tips og begrænsninger

Portalen vedligeholder et antal sider, som der potentielt kan være interesse i at linke til fra en portalservice. For at forebygge at ”døde” links opstår i takt med at portalens indhold ændrer sig, er det nødvendigt med et niveau af afkobling. En portalservice linker derfor ikke til en specifik URL, men til et alias. Portalen fanger forespørgslen på aliaset og stiller brugeren om til den faktiske side, der pt. viser det pågældende indhold. Dermed kan portalen frit bytte om på strukturen så længe alias ikke slettes og stadig har samme logiske indhold.

Serviceudbyderen kan kontakte portalejeren for at få en komplet liste af alias og information om den konkrete syntaks.

Supplerende parametre som angives i alias linket overføres til den konkrete portalside som aliasbrokeren stiller videre til. De portalservices der befinder sig på denne portalside (iFrame og WSRP) og som har markeret understøttelse for dynamiske parametre, vil også modtage disse supplerende parametre.

Hvis alias anvendes til at linke videre til en portalservice som i portalen er registreret som ekstern, vil portalservicen blive vist i det aktuelle browser vindue.

Det skal bemærkes, at alias kan anvendes såvel inde fra portalen – fra én portal side til en anden portal side – samt fra et eksternt site og ind til en specifik kontekst i portalen.

Serviceudbyderen har ansvaret for at sikre, at links til andre portalsider og websites er valide.
Retningslinier

Links til sider på portalen skal benytte portalens alias mekanisme, hvis der eksisterer et alias til det aktuelle indhold. Alternativt kan serviceudbyderen bede portalejeren oprette et.
Hvis der angives et alias som ikke er gyldigt, skal portalen præsentere en passende fejlside.
Eksempler

Link, der åbner et nyt vindue

<a href=”http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-01.html�∞� target=”_blank”>

Eksempler på alias links

http://portal.dk/alias?alias=forside∞
http://portal.dk/alias?alias=myndighedsoversigt∞
http://portal.dk/alias?alias=avanceret_søgning∞
http://portal.dk/alias?alias=vejviser∞
http://portal.dk/artikel?id=123123∞
http://portal.dk/service?id=4719∞
Referencer



Markup
Beskrivelse

Integrationsmodellen stiller ingen krav i forhold til anvendelse af HTML, XML og metadata for de portalservices som afvikles i eget iFrame i portalen.
Retningslinier

Ingen retningslinier
Referencer




Navigation og dialogforløb
Beskrivelse

Portalen består af en række portalsider i en fast menustruktur, men hvor indholdet kan være dynamisk. Endvidere indeholder portalen en række sider, som anvendes til at præsentere dynamisk indhold såsom søgeresultater, printvenligt indhold samt de tilmeldte portalservices.
Tips og begrænsninger

Link til indhold på portalen bør så vidt det er muligt ske ved anvendelse af alias (se afsnittet om ”Links”).

Navigation indenfor en iFrame i portalen, skal ske ved at portalservicen præsenterer sit skiftende indhold inden for samme portalside. Som udgangspunkt bør en portalservice ikke åbne nye vinduer i forbindelse med sit dialogforløb. Undtagelser kan dog fremgå af portalens designguidelines.
Retningslinier

Navigation indenfor en iFrame portalservice skal ske i rammerne af en specifik portalside der fastholdes.
Dialogforløb i en iFramet portalservice bør ske uden at åbne ekstra vinduer. Hvis sådanne alligevel anvendes, skal de være modale således at alle ekstra vinduer fjernes igen, inden portalservicen forlades
Referencer

[MYNDIGHEDSNET]
[OMBORGER]


Styling
Beskrivelse

Cascading Style Sheets (CSS) giver mulighed for at adskille indholdet af en webside fra den måde indholdet præsenteres på. Med teknologien kan man definere et layout, dvs. fonttyper, størrelser, farver, mm. i en ekstern fil og lægge dette ned over et antal websider på en gang. Dette gøres enten implicit ved at definere at bestemte elementtyper skal se ud på bestemte måder eller eksplicit ved at definere ”klasser” og derpå koble disse til elementer i markup.
Tips og begrænsninger

Integrationsmodellens style sheet klasser [OIMCSS] bliver brugt af de to portaler i implementationen af disses respektive style sheets på en sådan måde at elementer logisk set er ens på tværs. F.eks. vil almindelig tekst i begge portaler styles med klassen ”portlet-font” selv om der måske benyttes forskellige font typer og størrelser. Der henvises til design guides for Borgerportalen og Virksomhedsportalen, samt de respektive CSS filer for yderligere information.

Det er tilladt en serviceudbyder at lave sit eget style sheet som supplement til det der udstilles af Portalen. Dette style sheet må ikke være i konflikt med portalens, men udelukkende definere udseendet af elementer der ikke på forhånd er fastlagt.
Retningslinier

Integrationsmodellens style sheet klasser skal anvendes til styling.
Portalens design guidelines for hvordan style sheet klasserne fortolkes skal anvendes
Serviceudbyder kan bruge egne style sheets efter aftale med portalen.
Serviceudbyderes egne style sheets må ikke være i konflikt med portalens style sheets.
Serviceudbyderes egne styles skal indlejres direkte i markup og kan ikke linkes eksternt fra.
Eksempler

Anvendelse af integrationsmodellens style sheet klasse ”portlet-font”

<div class="portlet-font">Vigtig information</div>

Inlining af eget style sheet i HTML

<p style="background: blue; color: white;">Hvid på blå baggrund</p>
Referencer

[OIMCSS]
[HTML40] sektion 12.3
[MYNDIGHEDSNET]
[OMBORGER]


Søgning
Beskrivelse

Der er 3 primære navigationsveje til en portalservice via portalen:

Links i redaktionelt indhold.
Dynamisk liste af portalservices angivet på en konkret portalside.
Søgeresultater fremkommet med udgangspunkt i nogle stikord som brugeren har indtastet.
Tips og begrænsninger

Når portalen skal vise en liste af relevante portalservices i situation (1) og (2), sker det med udgangspunkt i et opslag i de oplysninger som blev angivet om portalservicen da den blev indregistreret.

Den dynamiske liste af portalservices opbygges med udgangspunkt i type, emnetype og –kategori, samt emneord, hvilket betyder at en portalservice indgår i søgning med udgangspunkt i de oplysninger som blev angivet i forbindelse med registreringen af den.

I forbindelse med søgning anvendes udover ovennævnte ligeledes de tekstuelle oplysninger i beskrivelses- og stikordsfelterne.

Den konkrete anvendelse og præsentation af oplysningerne om portalservicen vil afhænge af hvilken portal det drejer sig om.
Retningslinier

Portalservices der giver adgang til flere forskellige tjenester, skal tilmeldes flere gange; en gang for hver tjeneste, med angivelse af relevante data om den konkrete tjeneste. Dette er med til at sikre at denne portalservice fremkommer alle de steder på portalen hvor den har relevans.
Referencer






Tegnsæt
Beskrivelse

Websiders markup repræsenteres i et givet tegnsæt, som fortolkes af browseren. For at sikre at brugeren kan anvende indholdet af siden er det væsentligt at browseren understøtter det angivne tegnsæt.
Tips og begrænsninger

Integrationsmodellen stiller ingen krav i forhold til anvendelse af tegnsæt for de portalservices som afvikles i eget iFrame i portalen.
Retningslinier

Ingen retningslinier
Referencer




Tilgængelighed
Beskrivelse

Visse brugergrupper med funktionsnedsættelse kræver særlige hjælpemidler, f.eks. skærmlæsere og lupfunktioner, for at kunne benytte websider. Andre brugere anvender måske ældre software eller enheder, der ikke fandtes på det tidspunkt websitet blev designet.

I alle tilfælde vil et omhyggeligt og hensigtsmæssigt applikationsdesign i bredeste forstand kunne gøre websitet tilgængeligt.
Tips og begrænsninger

IT- og Telestyrelsens retningslinier for ”Hjemmesiders tilgængelighed” [TILGÆNGELIG] er toneangivende for hvordan offentlige websites designes for at sikre tilgængelighed for funktionsnedsatte brugere. Retningslinierne er publiceret på Netsteder.dk og baserer sig på W3Cs Web Content Accessibility Guidelines 1.0 (WAI).

WAI definerer en lang række egenskaber og klassificerer disse i 3 kategorier. WAI niveau A er egenskaber der skal opfyldes, WAI niveau AA er egenskaber der bør medtages og WAI niveau AAA er egenskaber der kan opfyldes. Niveauerne er kumulative, så en portalservice på niveau AA f.eks. også overholder niveau A egenskaber.

En serviceudbyder, der skal til at designe en kravsspecifikation til et website kan med fordel benytte IT- og Telestyrelsens online værktøjskasse [OIOVÆRKTØJ], der via en række baggrundsspørgsmål genererer en liste over de WAI krav der skal være opfyldt.
Retningslinier

Portalservices bør levere markup på WAI niveau AA.
Eksempler

Et af WAI niveau AA kravene dikterer at billeder skal forsynes med en alternativ tekst til enheder der ikke kan vise grafik. Eksemplet nedenfor viser et HTML IMG tag med en sådan alternativ tekst på:

<img src="pics/logo.jpg" width="100" height="100" alt="Kommunens Logo">

Et WAI niveau A krav er at Applets skal være forsynet med en alternativ tekst til enheder der ikke kan køre Java. Eksemplet viser en sådan Applet med alternativ tekst:

<OBJECT classid="java:Counter.class" width="200" height="200">
Java Applet, der viser antal udfyldte formularer …
</OBJECT>

Nedenfor er givet en række eksempler på WAI krav på forskellige niveauer, som skal overholdes. Listen er ikke udtømmende og der henvises til W3Cs retningslinier for en komplet liste.

Al information der er vist via farver skal også være til rådighed uden farver, for eksempel via konteksten eller via markup [Prioritet A (1)]
Style sheets skal bruges til at kontrollere layout og præsentation [Prioritet AA (2)]
Header elementer skal bruges til at angive dokumentstrukturen og i overensstemmelse med specifikationen [Prioritet AA (2)]
Referencer

[TILGÆNGELIG]
[WAI]
[OIOVÆRKTØJ]


Upload og download af indhold
Beskrivelse

En serviceudbyder kan have behov for at afspille film eller lyd for brugeren, modtage filer via upload eller tillade download af dokumenter og lignende.
Tips og begrænsninger

Portalen tilbyder ikke nogen specielle faciliteter til at håndtere download af indhold og modtagelse af filer fra slutbrugeren. Det er op til serviceudbyderen selv at implementere disse faciliteter, at håndtere modtagne filer, etc.

En serviceudbyder, der ønsker at levere en film eller lyd til en slutbruger, er selv ansvarlig for at lagre filmen og sætte det nødvendige markup op til browseren.
Retningslinier

Serviceudbyder skal overholde portalens design retningslinier for hvornår multimedia indhold må afspilles.
Serviceudbyder skal selv lagre indhold til upload.
Serviceudbyder skal selv håndtere at kunne modtage filer fra slutbrugeren.
Serviceudbyder skal selv sætte markup op til afspilning af multimedia indhold.
Referencer

[OMBORGER]
[MYNDIGHEDSNET]

3Sikkerhed

Adgangskontrol
Beskrivelse

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil.
Tips og begrænsninger

Portalen varetager en overordnet adgangskontrol, med det formål at afgøre om den aktuelle bruger må få adgang til den konkrete portalservice. Dette check foretages med udgangspunkt i de adgangskrav som angives i forbindelse med at portalservicen registreres. Hvis brugeren ikke har adgang til portalservicen, vil den ikke blive vist i lister og søgeresultater. Portalen kan dog ikke forhindre at der bliver vist links til portalservicen i redaktionelt indhold, samt fra andre portalservices.

Hvis brugeren har de fornødne rettigheder, præsenteres brugeren for et link til portalservicen.

En serviceudbyder kan have behov for at adgangsbegrænse visse dele af en portalservice på baggrund af en brugers profil. Denne adgangskontrol skal portalservicen selv håndhæve. Det er op til serviceudbyderen selv at foretage evt. begrænsninger i brugerens adgang til information på baggrund af den profilinformation der findes i SAML kuverten, som er tilgængelig via den fællesoffentlige føderation. Serviceudbyderen kan i den forbindelse selv benytte andre registre efter behov, hvilket er portalen uvedkommende.

De roller som brugeren er tildelt i portalen, medsendes ikke til portalservicen. Den adgangsdifferentiering som evt. skal ske i portalservicen, skal ske via portalservicens egne lokale rettighedsoplysninger.
Retningslinier

1.Portalen skal varetage overordnet adgangskontrol.
2.Serviceudbyderen skal selv forestå autorisationscheck decentralt.
3.Serviceudbyderen kan benytte attributter fra SAML kuverten med brugeroplysninger til autorisation.
4.Serviceudbyderen kan benytte andre registre til autorisation efter behov.
Referencer

[DKSAML20]


Brugeroplysninger
Beskrivelse

Når en bruger er blevet autentificeret med portalen skal brugeroplysningerne gøres tilgængelige for de portalservices, der udstilles for at muliggøre personalisering, revision og rettighedscheck.

Den fællesoffentlige føderation definerer en mængde information om slutbrugeren, der kommunikeres i en SAML assertion. Oplysningerne sendes med tilbage til serviceudbyderen fra føderationens identity provider når brugeren logges på.
Tips og begrænsninger

IT- og Telestyrelsens DK-SAML 2.0 [DKSAML] profil definerer de brugeroplysninger som serviceudbyder har adgang til.

Følgende information er altid tilgængelig for samtlige parter i føderationen via en SAML kuvert:

Common Name: Navnet den person som certifikatet er udstedt til.
Certificate Serial Number: Serienummeret på brugerens certifikat.
Organisationsnavn: For medarbejdercertifikater rummer feltet navnet på personens organisation. For personcertifikater findes attributten ikke.
PID Number: Det unikke løbenummer for personcertifikater.
CVR Number: Virksomhedens CVR nummer for medarbejdercertifikater.
RID Number: Løbenummer for virksomhedens medarbejdercertifikater. Kombinationen CVR-RID er unik.
Subject Serial Number: Løbenummer fra certifikatet.

Oplysningerne medsendes fra SSO føderationens identity provider. Se i øvrigt afsnittet om ”Single Signon (SSO)” for en diskussion af hvordan en serviceudbyder får adgang til disse oplysninger.
Retningslinier

1.En portalservice der har brug for at begrænse adgangen afhængig af hvem brugeren er, skal kunne modtage brugeroplysninger via den fællesoffentlige føderation [DKSAML20]. Portalen sender ingen information om brugeren til portalservicen.
Referencer

[DKSAML20]



Logning
Beskrivelse

Et logspor over hændelser fortaget i et it-system er nødvendigt for at kunne påvise at et evt. misbrug har fundet sted, herunder hvem der har foretaget hvilke handlinger med hvilken information og hvornår.

Logning kan desuden anvendes i forbindelse med bl.a. fejlsøgning og overvågning.
Tips og begrænsninger

Serviceudbydere, der indgår i SSO føderationen skal overholde retningslinjerne vedrørende logning fra IT- og Telestyrelsen [LOGNING], der bla baserer sig på Persondataloven [PERSLOV] og DS-484 [DS484].

Logsporet kan indeholde personfølsomme oplysninger og skal beskyttes behørigt mod uvedkommendes adgang. [LOGNING] anviser en mulig mekanisme til dette.

Portalen udstiller ikke nogen logningsservice der kan anvendes af serviceudbyderen. Det er alene serviceudbyderens ansvar at sikre loggen på forsvarlig vis, f.eks. vha. fysiske foranstaltninger, segmenterede netværk, procedurer og kryptografiske algoritmer.
Retningslinier

1.Serviceudbyderen skal logge brugeraktiviteter, afvigelser og sikkerhedshændelser i overensstemmelse med [LOGNING]
2.Serviceudbyderen skal sikre loggen mod uautoriseret adgang.
Referencer

[LOGNING]
[PERSLOV]
[DS484] afsnit 10.10 ff



Single Signon (SSO)
Beskrivelse

IT- og Telestyrelsen definerer rammerne for en fællesoffentlig føderation af portalservicer, der anvender Single Signon (SSO) via SAML standarden i DK-SAML profilen. Føderationen sigter på visuel integration med browserteknologier, dvs. ikke web services i første omgang.

Portalen indgår som en part i SSO føderationen og er derfor i stand til at håndtere protokollen for - og de data formater, der indgår i – SAML standarden som præciseret i DK-SAML profilen.

Profilen anvender digitale certifikater til både signering og kryptering af data, samt SSL/TLS til kryptering af transportlaget. Dette sikrer autenticiteten af afsenderen, integriteten af data og konfidentialiteten idet kryptering med modtagerens offentlige nøgle betyder at det kun er denne der kan læse informationen.
Tips og begrænsninger

Alle portalservices, der har brug for at kende identiteten af portalens bruger, f.eks. for at kunne autorisere brugeren til konkret indhold, for at kunne hente oplysninger om brugeren, etc. indgår i føderationen og benytter dennes infrastruktur til at få brugeridentiteten. Det betyder konkret, at Serviceudbyderen skal kunne håndtere SAML profilens forskellige facetter herunder Single Signoff for at kunne logge af føderationen.

Virksomhedsportalen Virk.dk implementerer sin egen SSO løsning, der også er baseret på DK-SAML. Virk.dks model konvergerer på sigt med den offentlige SSO model, så serviceudbydere kun skal kunne håndtere et sæt. Indtil dette arbejde er på plads kan en serviceudbyder blive nødt til at implementere en Virk.dk specifik løsning.
Retningslinier

1.Hvis en portalservice har brug for brugerens identitet, skal Serviceudbyderen indgå i SSO føderationen og derigennem få adgang til denne information.
Referencer

[DKSAML20]