Blogg fra desember, 2020

KS melder at SvarUt har driftsproblemer og er nede p.t. Alle innsendinger til Fellestjenester Bygg blir dermed køet opp og vi starter prosesseringen av disse så fort SvarUt er oppe igjen. Det jobbes nå med å identifisere de innsendingene som har blitt påvirket og vi vil forsøke å få kjørt disse om igjen så fort det lar seg gjøre.

Service desk vil ha lav eller ingen bemanning 21. desember til 4. januar. Det er også frysperiode i produksjonsmiljøet fra og med denne uken (uke 51) til og med uke 1, noe som betyr at vi ikke gjør endringer i produksjon med mindre det er strengt nødvendig.

Skulle det likevel oppstå en alvorlig eller kritisk hendelse i juleferien, ta kontakt med vakttjenesten. Dere finner åpningstider og kontaktinformasjon her: Kontaktkanaler

På vegne av alle oss i Fellestjenester BYGG vil jeg takke for et godt samarbeid i året som har vært, og ønske dere en riktig god jul og et godt nytt år. 🎄🌟

Anbefalingen fra Altinn i 2016 var å bruke «redirect» metoden for innlogging for å bruke REST APIet for sluttbrukersystemer: https://tt02.altinn.no/Pages/ExternalAuthentication/Redirect.aspx?returnUrl=https://fellesbygg.dibk.no/Skjema

Denne metoden er nå “legacy”: https://altinn.github.io/docs/api/rest/kom-i-gang/idporten-legacy/#4-autentisering-ved-integrasjon-i-andre-portaler

Nå anbefaler Altinn å bruke OIDC/OAuth2-basert autentisering:

De fleste nettlesere nå inn kraftig på hvordan tredjepartscookies benyttes, og dette påvirker også den cookie-baserte autentiseringsmekansimen Altinn tilbyr for nettleser-baserte integrasjoner.

Som en konsekvens av dette er nå denne mekanismen ansett som legacy, og vi anbefaler å migrere over på OIDC/OAuth2-basert autentisering med ID-porten. Dette erstatter cookien med et bearer-token, som gjør det mulig å lage både backend- og frontend-baserte integrasjoner som ikke rammes av disse restriksjonene.

Les mer om dette på https://altinn.github.io/docs/api/rest/kom-i-gang/ (under seksjonen "Autentisering med ID-porten"), samt https://altinn.github.io/docs/api/rest/kom-i-gang/scopes/#sluttbruker-api for en liste over hvilke scopes REST-API-et er delt opp i. Dette vil også kreve tilgang til samarbeidsportalen til ID-porten for å opprette disse integrasjonene. Dette er kostnadsfritt. Det vil fortsatt kreves en API-nøkkel utstedt fra Altinn, men dere kan fortsette å bruke den dere bruker i dag.

De fleste scopene som krever en autentisert person innebærer at sluttbrukeren fremvises en dialog hvor han/hun må godkjenne at applikasjonen skal få tilgang. For å lette jobben med å migrere fra legacy-integrasjoner, har vi imidlertid et scope "altinn:endusernoconsent" tilgjengelig for Altinn-tjenesteeiere (som DIBK). Dette gjør det mulig å hente ut et bearer-token uten brukerinteraksjon, slik at dette kan tas i bruk uten at brukerflyten i eksisterende integrasjoner må endres. Man kan fortsatt ksessere Altinn-API-ene fra frontend (nettleser) via en såkalt "public client", se mer om dette på https://difi.github.io/felleslosninger/oidc_auth_spa.html.

Altinn og DiBK anbefaler at stønadssystemene tar en kikk på denne anbefalingen. Det er ikke sikkert at den cookie baserte innloggingen vi bruker i dag vil fungerer smertefritt framover.

Oppdateringer/klareringer:

Sluttbrukersystemene (konsumentene) må selv tegne en avtale med ID-porten/Digdir og få tilgang til Samarbeidsportalen for å opprette sine klienter. Onboardingen for private virksomheter er for ID-porten dessverre ikke helt på plass, men https://samarbeid.digdir.no/id-porten/ta-i-bruk-id-porten/94 har mer informasjon om dette – ellers kan de kontakte servicedesk@digdir.no

Når tilgang er på plass, må altså konsumenten registrere en klient (herunder konfigurere autentiseringsmetode, f.eks. client_secret, og provisjonere scopes). Les mer om dette på https://difi.github.io/felleslosninger/oidc_func_clientreg.html. Dette gjøres typisk direkte i administrasjonsgrensesnittet i Samarbeidsportalen. Så:

1. Client_secret / client_id blir tildelt ifm opprettelse av klienten. API-key i Altinn er uavhengig av dette.

2. Scopes knyttes til klienten.

Statehåndtering: 

1. Hvis man med «klienten» her mener sluttbrukers nettleser, så ja er det mulig. Dette er da såkalt public klienter i OAuth2, og har en annen trusselmodell en må sette seg inn i. Se mer på https://difi.github.io/felleslosninger/oidc_auth_spa.html

2. Altinn tillater bruk av public klienter for sine API-er.

Merk at scopet «altinn:endusernoconsent» ikke er tilgjengelig for andre enn tjenesteeiere i Altinn, og heller ikke for nye integrasjoner. Dette er kun et scope som tilbys eksisterende legacy cookie-baserte implementasjoner som et hjelpemiddel ifm migrering til OIDC/OAuth2.

Får å få tilgang til dette scopet må søknadsystement få spesiell tilgang fra Altinn sentralforvaltning. Dette starter med en Service Desk sak til DiBK.

Andre relevante lenker:

https://difi.github.io/felleslosninger/oidc_guide_idporten.html

https://difi.github.io/felleslosninger/oidc_auth_spa.html

https://samarbeid.digdir.no/

https://difi.github.io/felleslosninger/oidc_auth_spa.html

Oppdateringer:

Testing av autentisering.

https://docs.digdir.no/idporten_verifikasjonstester.html

Søknadssystemet tester dette selv. Fra DigDir: Testene skal sørge for at innlogging og utlogging fungerer som det skal. Vi sjekker ikke opp om kundene gjør dette.

Oppdateringen ble presentert på dialogmøtet i desember. Blogginnlegget detaljerer forslaget litt mer. Vi ønsker tilbakemeldinger fra søknadssystemene før vi eventuelt legger denne løsningen ut i produksjon etter frys perioden i januar.

Bakgrunn

Datamodellen for erklæring av ansvarsrett skjemaet som blir opprettet i Altinn portalen for ansvarlige foretak gjennom distribusjonstjenesten innholder to felter relatert til Sentral Godkjenning:

• harSentralGodkjenning: indikerer om foretaket er registrert med SG, en variable på foretaksnivå. Påkrevet felt.

• dekkesOmraadeAvSentralGodkjenning: indikerer om det enkelte fagområde er dekket av foretakets sentral godkjenning, et felt per fagområde i erklæringen. Påkrevet felt.

Distribusjonstjenesten som oppretter disse skjemaene, har bare tilgang til å sette harSentralGodkjenning.

Den nåværende tjenesten for erklæringsskjemaet bruker ikke feltet harSentralGodkjenning mens feltet for harSentralGodkjenning er default satt til usann.

Ønsker til forbedring

Vi har mottatt ønsker om oppdatere dagens tjeneste til å indikere på ansvarsrettskjemaet at foretaket har sentral godkjenning og påkreve at bruker tar et aktivt valg om ansvarsområdet er dekket eller ikke.

Løsning

Løsningen vi foreslår er:

• Påkreve at søknadssystemene setter feltet harSentralGodkjenning ved distribusjon.

  • Org nummeret kan sjekkes for SG mot API for Sentral Godkjenning

• Gjøre feltet dekkesOmraadeAvSentralGodkjenning nillable i skjema datamodellen

  • Hvis harSentralGodkjenning er satt false i distribusjonen blir feltet ikke vist i svar skjema

  • Hvis det er satt til true, blir feltet satt till null, og et svar blir påkrevet i skjemaet.

  • Reglene i backend og skjema blir satt opp slik at når XML for svarskjemaet er mottatt av stønadssystem er feltet dekkesOmraadeAvSentralGodkjenning satt til true eller false (aldri null) og de-serialisering blir som før.

Oppsummering:

Eksempel (prototype)

Distribusjon med harSentralGodkjenning = true

Ansvarsrett skjema indikerer at foretaket har sentral godkjenning og innsender må ta et valg om ansvarsområdet dekkes eller ikke.

Distribusjon med harSentralGodkjenning = false

Skjemaet indikerer at foretaket ikke har SG (den gult uthevede teksten kan eventuelt tas helt vekk) og man blir ikke spurt om å ta stilling til om ansvarsområdet dekkes.

Kommentarer på denne implementasjon sendes til Service Desk!!

Vi har fått en melding om at registeret over sentralt godkjente foretak (https://sgregister.dibk.no/) er nede. Vi oppdaterer blogginnlegget når registeret er oppe igjen.

Validerings-APIet er nå oppdatert til den nye versjonen av sjekklistene, i test og produksjon.

Oppgraderingen gjør at vi kan gi en mer presis filtrering av valideringene basert på hvilken tiltakstype som er valgt.

Dokumentasjon for sjekklistene og lenke til API finnes her: Nasjonale sjekklister for byggesak

Nye tiltakstyper

Som følge av endringen, har vi kunnet legge til og validere på to nye tiltakstyper:

• Endring av anlegg

• Riving av anlegg

Bedret validering av nabovarsel

Oppdateringen gjør også at vi har tilpasset reglene for hvilke vedlegg som skal sendes med nabovarsel. Vi spør nå på sjekkliste-APIet for følgende regler i nabovarsel v4:

I forrige versjon av sjekklistene hadde vi ikke egne sjekkpunkter for nabovarsel, noe som førte til at vi måtte bruke sjekklistene for rammesøknad. Dette førte til en for streng validering i noen tilfeller.

SvarUt og SvarInn stenger den første helgen i desember, noe som gjør at vi må stenge Fellestjenester BYGG for alle innsendinger.

Vi stopper prosessen som henter innsendinger fra Altinn hvert 5. minutt fra fredag 4. desember kl. 13:00 og senest til mandag 7. desember kl. 08:00.

Detaljer om stengingen

• Søknader og distribusjoner kan sendes fra søknadssystemet til FtB, men det kommer ikke videre i arbeidsflytfunksjonen

• Status-APIet vil returnere feilkoden 404 for innsendinger som har blitt levert i Altinn men som ikke er behandlet i arbeidsflytfunksjonen ennå

  

• Stengingen gjelder sendinger som går til både SvarUt og Altinn (altså også nabovarsler, ansvarsretter, samsvarserklæringer og kontrollerklæringer)

• Fristene for saksbehandling i kommunen og svar på nabovarsler vil gjelde fra den datoen søknaden/nabovarselet blir sendt fra FtB. Sluttbrukersystemet bør opplyse brukeren om at søknader og varsler må være sendt før fredag kl. 13:00 dersom de vil ha det sendt før helgen.

Detaljer om gjenåpningen

• SvarUt vil prøve å være oppe igjen før mandag. Vi vil derfor følge med på om vi kan åpne for sendinger i løpet av helgen. I “verste fall” kan vi ikke åpne opp igjen før mandag 7. desember kl. 08:00.

• Gjenåpningen kan også ta litt tid etter mandag morgen, siden vi først må teste at alt går bra med utvalgte innsendelser.

• Nabovarsler som sendes til naboer som er reserverte mot digital kommunikasjon kan feile fordi vi ikke har mulighet til “retry” i printtjenesten ved utsendelse av nabovarsel.

Mer om bakgrunnen for stengingen

Grunnen til at vi ønsker å stenge FtB helt i tiden SvarUt er nede, er for å minimere sannsynligheten for mye etterarbeid etter feilede søknader og nabovarsler.

Hele driftsmeldingen fra KS er limt inn under.