Den Fællesoffentlige Integrationsmodel for Borgerportalen og Virksomhedsportalen

StartSide :: Integrationsmodellen :: Afprøvninger :: Ressourcer :: Kontakt :: Login/Registrering

Teknisk Proof of Concept for Den fællesoffentlige integrationsmodel for borgerportalen og virksomhedsportalen


Offentlig Erfaringsrapport

3 Opsætning, deltagere og cases i PoC


Borger.dk portalsiden: Oracle portal
Sundhed.dk: BMI selv-service
Færdselsstyrelsen: Vognmandstilladelse
KMD: Mit budget
IBM: CVR service
Rødovre Kommune: e-posthus.dk



PoC Oversigt


Indhold
1 Forord og summary
2 Indledning
3 Opsætning, deltagere og cases i PoC <- Du er her!
4 Afprøvning og erfaringer
5 Konklusion


 



Borger.dk portalsiden: Oracle portal


Som udgangspunkt er benyttet samme standard-software til PoC’en, som i borger.dk produktionsmiljøet, nemlig Oracle Application Server 10g (Oracle AS).

For at kunne gennemføre projektet og herunder afprøvning af de valgte standarder, er der installeret yderligere software-komponenter og andre komponenter er blevet opgraderet for at understøtte de valgte standarder i de korrekte versioner. Dette er beskrevet særskilt under afsnittene om hhv. WSRP/JSR168 og IdP.

Borger.dk produktions-miljøet afvikles i et tre-tier server-setup med hhv. database, identity management og portal/web-server på hver sin server, og med separate netværk adskilt af firewalls til hvert tier. Dette viste under opstarten af projektet ikke at være hensigtsmæs-sigt, hvorfor PoC miljøet er afviklet på to virtuelle servere: en til identity management og database samt en til portal/web-serveren. Begge servere ligger i samme netværkssegment og har været placeret i en DMZ for at minimere problemer med netværksadgang til og fra serverne.

Borger.dk WSRP/JSR168 setup

Oracle AS understøtter flere portlet-teknologier, herunder Oracles egen PDK Java specifi-cation og standarderne WSRP og JSR168 (også kendt som Java Portlet Specification, JPS). JSR understøttes dog ikke direkte, men via ”indpakning”, hvorefter de afvikles som WSRP portlets, hvor Oracle Portalen både er producer og consumer.

Oracle Portalen

Ved afvikling af WSRP portlets forbindes til en ekstern portlet producer. De to elementer “WSRP Adapter” og “JPS Portlet Container” er altså placeret hos portlet producer (andre steder omtalt provider) og Oracle Portal kommunikerer direkte med den eksterne producer via HTTP.

Afvikling af JSR168 portlets foregår i Oracle AS ved at deploye portlets i en lokal portlet container, med en tilhørende WSRP Adapter. Oracle Portal afvikler dermed JSR168 port-lets på samme måde som WSRP portlets, blot med den forskel at portlet producer er placeret lokalt.

Benyttet software:

Oracle Application Server 10g version 10.1.2 (som borger.dk):

Borger.dk IdP setup

Borger.dk produktions-miljøet benytter sig af Oracle Identity Management til håndtering af autentifikation og administration af brugere og roller. Autentifikation varetages af Oracle Single-Sign-On (SSO) mens brugere og roller administreres af Oracle Internet Directory, der bl.a. består af Oracles LDAP-server.

Oracle Identity Federation (OIF) er Oracles federation server, der bl.a. supporterer SAML 2.0 og kan optræder som både Service Provider (SP) og Identity Provider (IdP). Da OIF ikke benyttes af borger.dk, har det været nødvendigt at installere OIF og i den forbindelse skulle Oracle Identity Management også opgraderes til en nyere version.

Oracle IdP

1.Brugeren requester en borger.dk side, der er beskyttet af mod_osso.
2.Oracle SSO er konfigureret til at bruge Oracle Identity Federation (OIF) Service Pro-vider (SP) til autentifikation.
3.OIF SP laver SAML SSO med Identity Provider, der prompter brugeren for bruger-navn/password.
4.OIF SP mapper SAML assertion til en lokal bruger og opretter en Oracle SSO session.
5.Der bliver givet adgang til siden af mod_osso.

Benyttet software:

Oracle Application Server 10g version 10.1.2 (som borger.dk):


Sundhed.dk: BMI selv-service


Integrationsform

Integrationsformen der er anvendt er Remote Portlet. Løsningen er baseret på WSRP 1.0 standarden.

Case

På sundhedsportalen sundhed.dk stilles en række sundshedsrelevante tjenester til rådghed for brugerne gennem en portletbaseret brugersnitflade. Portalen betjener både professionelle indenfor sundhedssektoren og borgere. De sidste kan f.eks. få adgang til oplysninger om indlæggelser og medicinering via recepter.
Til anvendelse i POC blev en selv-service Body Mass Index (BMI) portlet applikation valgt. Denne eksponeres på borger.dk via WSRP protokollen.

Overordnet arkitektur

Sundhed.dk afvikles på IBM WebSphere Portal Server. Til POC-afprøvningen blev der opsat en test WebShere Portal Server i et et WM-Ware image, som BMI portletapplikationen blev installeret på.

BMI portlet applikationen trækker ikke på data udefra, men ”medbringer” pakket ind i portlet web-applikationen et rammeværk, som anvendes af mange portlets på sundhed.dk.

Sundhedsportalen

Som tegningen indikerer er der tale om en punk-til-punkt integration mellem en WSRP web service consumer og en WSRP web service WSRP provider.

Ved opsætning af WSRP forbindelsen sker følgende:
  1. På WSRP producer siden – sundhed.dk - konfigureres BMI portletten til at være en WSRP producer. Konfiguration foregår i en administrativ portlet via 2-3 museklik.
  2. Herved generes en udefra tilgængelig wsdl hvor de portlets, der er registrerede som producers, indgår (publish).
  3. På WSRP consumer siden – borger.dk - konfigureres en WSRP consumer portlet.
  4. Link addressen til BMI producer wsdl dokumentet indsættes (find og bind).

Benyttet software:

WebSphere Portal Server Version 6

Bemærkninger

Der var ingen problemer med WSRP consumer portletten på borger.dk. På BMI portletten viste det sig, at den anvendte et internt objekt i stedet for portlet standard API. Dette gav en fejl under WSRP sessionen. Det blev rettet og herefter kørte portletten via WSRP, som den skulle.


Færdselsstyrelsen: Vognmandstilladelse


Integrationsform

Integrationsformen der er anvendt er Remote Portlet. Løsningen er baseret på WSRP 1.0 standarden.

Denne case er en slags composite application, men ikke som i rapporten ”Arkitekturen på en borgerportal” en composite, der baseres på installeret JSR168. Applikationen afvikles hos myndigheden og vises via Remote Portlets.

Case

Færdselsstyrelsen er en composite application, der samler en række myndighedsservices i en sammenhængende proces, hvor man kan søge om en vognmandstilladelse. Det involverer bla. servicekald til CPR/CVR, politiet, skat. For brugeren er der tale om én sammenhængende service.

Færdselsstyrelsen
Færdselsstyrelsen

Overordnet arkitektur

FSTYR POC afvikles på IBM WebSphere Portal Serve samt en WebSphere Process Server. Til POC-afprøvningen blev der opsat en test WebShere Portal Server og Process Server i et et WM-Ware image. Vognmands-portletapplikationen blev installeret på Portal serveren og forretningsprocessen (BPEL) blev installeret på Process Server.

Portlet applikationen spiller sammen med BPEL processen på den måde at den dels initierer en BPEL proces instans og dels deltager i nogle af BPEL processens manuelle aktivieter. Disse opleves af brugeren som en sekvens af skærmbilleder i portlet applikationen.

BPEL processen henter oplsyninger fra andre offentlige organisationer (CPR, CVR og Skat). Endelig afsluttes BPEL processen med, at der via et webservice-kald oprettes en sag i et ESDH test system (Scanjour Captia).

Færdselsstyrelsen

Ved opsætning af WSRP forbindelsen sker følgende:
  1. På WSRP producer siden – FSTYRPOC.dk - konfigureres Vognmandsportlet portletten til at være en WSRP producer.
  2. Herved generes en udefra tilgængelig wsdl hvor de portlets, der er registrerede som producers, indgår (publish).
  3. På WSRP consumer siden – borger.dk - konfigureres en WSRP consumer portlet.
  4. Link addressen til portlet producer wsdl dokumentet indsættes (find og bind).

Testen er i denne case kompleks, fordi den samlede applikation er distribueret over en række lag, systemer og organisatoriske domæner: To portaler, en proces server og en række eksterne services.

Benyttet software:


Bemærkninger

Da sikkerhed ikke indgik i POCen var det ikke muligt at identificere ansøgeren. Applikationen har brug for oplysninger om ansøgerens CPR og CVR nummer. Processen der bearbejder og kontrollerer ansøgningen har brug for CPR og CVR numrene for at kalde de underlæggende services fra CPR, CVR og Skat.

I forbindelse med web service sikkerhed på transport niveauet (OWSA Web Service Security Model T), hvor der anvendes SSL til kryptering, kan man evt. vælge at anvende det User objekt der er defineret i WSRP standarden. Dette objekt rummer en række standard brugerinformationer som navn og adresse. For at anvende det, skulle det udvides (er ifølge WSRP tilladt) med CPRNummer og CVRNummer information.

Der var ingen problemer med WSRP consumer portletten på borger.dk.

Service provider applikationen får CVR og CVR nummeret via brugerens login. Hentning af brugerinformation via WSRP web service kaldet kræver derfor en programændring i applikationen. I stedet blev der af hensyn til at kunne gennemføre testen i POCen lavet en stubløsning, som oprettede et test bruger CPR og CVR nummer.


KMD: Mit budget


Integrationsform

Integrationsformen der er anvendt er Remote Portlet. Løsningen er baseret på WSRP 1.0 standarden.

WSRP dannes fra providersiden ved brug af NetUnity som muliggør at Microsoft .NET løsninger udstilles som Remote Portlets. Denne case er altså et væsentligt supplement til de java-orienterede WSRP afprøvninger for at sikre, at WSRP som standard ikke udelukker den store del af markedet, der er Microsoft-orienteret.

Case

Casen tager udgangspunkt i et løsningen ”Mit Budget”, som KMD har udviklet og integreret med Ældresagens hjemmeside. (Ældredagen anvender ikke længere produktet). For at kunne integrere med Ældresagens hjemmeside eller for den sags skyld en kommunes hjemmeside anvendes en KMD fælleskomponent ”Grafisk udrulning”. Denne komponent anvendes af alle KMD’s borgserviceløsninger, så derfor skal det forsøges at kombinere WSRP med denne komponent. Antagelsen er at hvis dette kan lade sig gøre vil det minimere omkostningerne ved at få KMD’s borgerserviceløsninger til at ”tale” WSRP og dermed at kunne integrere på borger.dk.

Den oprindelige løsning kan nås på vedlagte link
http://budgetmodul.netborger.dk/budget/default.aspx?p=bs∞

For at skifte design ændres p-parameteren til noget, der identificerer et layout. Kan eksempelvis prøves med (p=borgerdk, p=aeldresagen eller p=aarhus).

Overordnet arkitektur

Som det fremgår af case-beskrivelsen er det egentlig ikke ”Mit Budget” der skal testes men der imod komponenten ”Grafisk Udrulning”. ”Mit Budget” er valgt da den ikke har bindinger til fagsystemer hvilket bare ville medføre besvær i en testsituation. Som back-end er der dermed kun en MS SQL database som tilgås med ODBC.

Setup’et ser således ud.

KMD

Diagram over den oprindelige løsning og WSRP løsningen

WSRP løsningen udstiller en provider på URL’en
http://minside.test.dk/wsrp/producer1.asmx?Operation=WSDL∞

Servicen er placeret hos KMD og den tilgås via SOAP/HTTP.


IBM: CVR service


Integrationsform

Integrationsformen der er anvendt er Portlets. Løsningen er baseret på JSR168 Portlet.

Der er forsøgt afprøvet en composite application, men erfaringer er primært baseret mere simple applikationer.

Case

Der var oprindeligt tænkt en composite application ved brug af JSR udgave af Færdselsstyrelsen. Det var ikke muligt, da der er anvendt portal-teknologi udover JSR168 standarden i denne implementering.

Derfor blev der i stedet installeret og afprøvet en alternativ portlet, som henter oplysninger om en virksomhed. Portlet applikation er en lille hjælpeservice, hvor man kan søge efter oplysninger om en virksomhed ud fra dens CVR nummer. Det sker med et vist genbrug af løsningsarkitekturen fra Færdselsstyrelsen case’en.

Erfaringer er desuden baseret på en helt simpel JSR168 installation, hvor deployment udfordringer og andet gjorde det umuligt at foretage fuld afprøvning og drage konklusioner på de øvrige nævnte services.

Overordnet arkitektur

Der er udviklet en Portlet efter JSR168 standarden på IBMs Web Sphere platform. Denne portlet er herefter deployet til Oracle Portal, hvor koden afvikles.

IBM

Der er altså tale om afvikling på samme server som portalen og ikke som ved brug af WSRP en remote portlet i et distribueret miljø.

Ved overførsel af en JSR168 potlet sker følgende:

Benyttet software:


Bemærkninger

Det viste sig af Oracle Portal ikke har sin egen JSR168 container. Man er derfor nødt til at pakke den ind som en WSRP provider, før den kan anvendes på Oracle Portal, med den øgede kompleksitet og det performance overhead, som dette medfører.

Testen fejlede fordi WebSphere Portal bruger en open source xerces xml parser fra Apache mens Oracle Portal anvender sin egen xml parser. Begge plaftforme understøtter XML og Web Services, som de skal for at overholde J2EE standarden, men Oracle og IBM har valgte forskellige implementeringer af deres XMl og Web Service runtime miljøer.

Løsningen på dette er at tage eventuelle runtime-platform forskelle med i portlet WAR arkivet. I dette tilfælde xerces bilblioteket fra Apache. Dette kan lade sig gøre, men gør dels web applikationen større, øger kompleksiteten og introducerer nye fejlmuligheder.


Rødovre Kommune: e-posthus.dk


Integrationsform

Integrationsformen der er anvendt er Link og iFrame m/Single Sign-on (SSO).

Link og iFrame er under PoC afprøvet samlet, da det teknisk set har de samme udfordringer. Set med informationsarkitekturøjne kan disse være meget forskellige integrationsformer, men det giver ikke mening at afprøve og erfaringsopsamle som om disse var vidt forskellige udfordringer set i forhold til de standarder, der skal afprøves på tværs af tekniske platforme.

Case

e-posthus.dk er en post og kalender portalløsning hos Rødovre Kommune, der med tiden kommer til at favne en række services - såvel kommunale som andre.

Det bør være således at borgeren ikke møder flere logins, når han/hun bevæger sig mellem en Borgerportal og Rødovres e-posthus.dk løsning - uanset hvilken portal denne vælger (først).

Rødovre ønsker en løsning som her og nu giver single sign-on til kommunens interne tjenester, og kan anvendes med eksisterende login metoder som brugernavn/kodeord, borgerens OCES certifikat, og samtid være forberedt til den fremtidige fælles offentlige login service med anvendelse af SAML 2 tokens.

Der blev således testet en række scenarier med kommunens Epost løsning som eksempel på en service provider:

  1. Kommunal single sign-on med brugernavn og kodeord til kommunens e-posthus.dk.
  2. Kommunal singlesign-on med borgerens OCES certifikat til kommunens e-posthus.dk.
  3. Fælles offentlig single sign-on med OCES certifikat via den fælles offentlige loginservice (IDProvider) til kommunens e-posthus.dk med link videre til borger.dk
  4. Fælles offentlig single sign-on med OCES certifikat via den fælles offentlige loginservice (IDProvider) til borger.dk med link videre til kommunens e-posthus.dk

SSO scenarie 4 - detaljeret:
  1. Borgeren kommer til Borgerportalen
    Borgeren anvender en ressource/service, der kræver login
  2. Login rettes mod IDProvideren
  3. ID Provideren returnerer et SAML token til login på Portalen
    Borgeren vises den ønskede (adgangsbegrænsede) side på Borgerportalen
  4. Borgeren klikker på link til Rødovres e-posthus.dk
  5. Sikkerhedskomponenten (TFIM) checker SAML token op mod IDProvideren
  6. Accepten returneres fra IDProvideren
  7. Brugeren får adgang til Rødovres e-posthus.dk

Rødovre

I virkeligheden var der ikke den store forskel på de to fælles offentlige single sign-on scenarier (3 og 4) da borger.dk og Rødovre site principielt har den samme rolle som service provider. Links begge veje lykkedes da af samme grund også.

Overordnet arkitektur


I de to scenarier med fællesoffentlig single sign-on indgik således tre hovedaktøren:

Arkitekturen i Rødovre Kommune:

Det følgende diagram viser sikkerhedsarkitekturen, som den blev afprøvet i denne PoC:

Rødovre

De kommunale services er illustreret med Epost og Bibliotek. ePost indgik i afprøvningen. e-posthus.dk er en Domino Mail Server, som tilgås via http med Domino Web Access.

RK er et LDAP brugerkatalog over Kommunens borgere og personer, som kan tilgå kommunens systemer.

Scenarie 1 og 2 med lokalt login med single sign-on og support for Brugerid/kodeord og OCES certifikat understøttes af IBM Tivoli Access Manager(TAM) med IBM cbt til understøttelse af OCES certifikathåndteringen. I TAM konfigurer man såkaldte “junctions, som sørger for at brugerens login transformeres videre på en for de bagvedliggende systemer forståelig måde.

I scenarie 3 og 4 tilgås de kommunale systemer via en fælles offentlig login service (illustreret med IDProvider) er det IBM Tivoli Federeated Idendity Management (TFIM), der kan modtage det afsendte SAML-token og sammen med TAM omsætte det gennem en junction til et forståeligt login for de bagvedliggende systemer som f.eks. ePost.

Anvendt Software:


Bemærkninger

Det lykkedes at konfigure og teste alle de fire nævnte scenarier med succes.

Der er en kommentar til denne side. [Vis kommentar]

Sidehistorik :: 2007-06-06 05:10:08 XML :: Ejer: WebMaster :: Søg:
Valid XHTML 1.0 Transitional∞ :: Valid CSS∞ :: Powered by Wikka Wakka Wiki 1.1.6.3∞
Page was generated in 0.0566 seconds