Utökad funktionalitet

Anpassning — Logotyp

Det är möjligt att byta den logotyp som visas på ett par ställen i flexiteCLIENT samt flexiteWEB. Detta möjliggör att exempelvis visa det egna organisationsnamnet istället för standardlogotypen för flexite.

Anpassa logotyp i flexiteCLIENT

Det är möjligt att byta ut den logotyp som visas på inloggningssidan i flexiteCLIENT.

• Sökväg: C:\flexite\flexiteCLIENT\
• Standard-fil: logo150x23.png
• Format på filnamn: logo*.BMP, logo*.GIF, logo*.JPG, logo*.PNG
• Stöd för bildformat: BMP, GIF, JPG, PNG
• Maximal bredd: 281 pixlar

Prioriteringsordning

I det fall det finns flera filer som matchar formaten som stöds väljer den första matchande filen enligt stigande alfanumerisk ordning.

Exempel

Fig.17: Exempel på inloggningssida i flexiteCLIENT med standardlogotyp.Fig.18: Exempel på inloggningssida i flexiteCLIENT med anpassad logotyp.

Rekommendationer

Det är rekommenderat att använda sig av en anpassad logotyp-fil med unikt filnamn istället för att skriva över standard-filen (logo150x23.png). Detta för att undvika att den anpassade filen skrivs över vid framtida uppgraderingar.

Anpassa logotyp i flexiteWEB

Det är möjligt att byta ut den logotyp som visas på inloggningssidan respektive den som visas i huvudmenyn i flexiteWEB.

När anpassade logotyper saknas faller flexiteWEB tillbaka till att nyttja standardlogotyperna.

Logotyp på inloggningssida

• Sökväg: C:\tomcat\webapps\flexite\customer\
• Filnamn: logotype_login.PNG
• Bildformat: PNG
• Maximal storlek: 240x40 pixlar

Exempel

Fig.19: Exempel på inloggningssida med standardlogotyp.Fig.20: Exempel på inloggningssida med anpassad logotyp.

Logotyp i huvudmeny

För logotypen i huvudmenyn är det möjligt att nyttja individuella bilder för flexiteWEB och SmoothForms genom att nyttja de individuella prioritetsordningarna.

Huvudmeny i flexiteWEB

• Sökväg: C:\tomcat\webapps\flexite\customer\
• Filnamn: logotype_menu.PNG, logotype_menu.SVG
• Bildformat: PNG, SVG
• Maximal bredd: 190 pixlar

Prioritetsordning

flexiteWEB prioriterar filer för logotyp i följande ordning:

1. logotype_menu.PNG
2. logotype_menu.SVG

Exempel

Fig.21: Exempel på huvudmeny i flexiteWEB med standardlogotyp.Fig.22: Exempel på huvudmeny i flexiteWEB med anpassad logotyp.

Huvudmeny i SmoothForms

• Sökväg: C:\tomcat\webapps\flexite\customer\
• Filnamn: logotype_menu.SVG, logotype_menu.PNG
• Bildformat: SVG, PNG
• Maximal storlek: 189x29 pixlar

Prioritetsordning

SmoothForms prioriterar filer för logotyp i följande ordning:

1. logotype_menu.SVG
2. logotype_menu.PNG

Exempel

Fig.23: Exempel på huvudmeny i SmoothForms med standardlogotyp.Fig.24: Exempel på huvudmeny i SmoothForms med anpassad logotyp.

Anpassning — Språktermer

Det är möjligt att skräddarsy de textsträngar som visas i flexiteWEB och flexiteAdmin efter egna önskemål.

Anpassa språktermer i flexiteWEB

I flexiteWEB anges anpassade textsträngar per språk och fungerar som komplement till ordinarie språkfiler.

Ordinarie språkfiler

Ordinarie språkfiler ligger i katalogen C:\tomcat\webapps\flexite\WEB-INF\classes\language:

• ResBundle_en.properties — Engelska
• ResBundle_se.properties — Svenska

Anpassade språkfiler

Anpassade språkfiler placeras i katalogen C:\tomcat\webapps\flexite\WEB-INF\classes\language\customer. flexiteWEB stödjer en fil per språk, med samma namn som den fil den ska agera komplement till.

Hur flexiteWEB väljer textsträngar

flexiteWEB nyttjar variabler för att ange vilka textsträngar som ska visas i gränssnittet. Variabeln är densamma oavsett visningsspråk, och de faktiska textsträngarna hämtas från de individuella språkfilerna, baserat på valt språk.

Förlopp

Som exempel på förlopp kan vi ta textsträngen för menyalternativet 'Registrera' i huvudmenyn på språket Svenska. Variabeln för denna sträng är MainMenu.Initiate.Caption.

1. flexiteWEB inleder med att ta reda på huruvida det existerar en anpassad språkfil för aktuellt språk; C:\tomcat\webapps\flexite\WEB-INF\classes\language\customer\ResBundle_se.properties.
   Om en anpassad språkfil existerar, gå till punkt 2.
   Om en anpassad språkfil INTE existerar, gå till punkt 3.
2. flexiteWEB söker efter strängen för MainMenu.Initiate.Caption i den anpassade språkfilen.
   Om strängen existerar i den anpassade språkfilen hämtas den och visas i gränssnittet.
   Om strängen inte existerar i den anpassade språkfilen, gå till punkt 3.
3. flexiteWEB söker efter strängen för MainMenu.Initiate.Caption i standard-språkfilen (C:\tomcat\webapps\flexite\WEB-INF\classes\language\ResBundle_se.properties) och visar den i gränssnittet.

Tillvägagångssätt för att ange egna termer

Språkfilerna i flexiteWEB är uppbyggda med key-value pairs i följande format:

nyckel=värde

• nyckel — Unikt ID för textsträngen. Denna nyckel används i flexiteWEB för att ange var textsträngen ska nyttjas. Denna nyckel FÅR INTE ändras.
• värde — Den textsträng som visas i gränssnittet. Det är detta värde som kan anpassas med egna termer.

Procedur

Proceduren för att ange skräddarsydda strängar för Svenska ser ut på följande vis:

1. Skapa en fil med samma namn som den fil den ska agera komplement till, ResBundle_se.properties, under katalogen C:\tomcat\webapps\flexite\WEB-INF\classes\language\customer.

2. Redigera den nya ..\language\customer\ResBundle_se.properties och lägg till de strängar som ska ändras. Det enklaste förfarandet är att söka upp strängarna i standard-språkfilen, kopiera in dem i den nya filen, och där utföra önskade ändringar.

   Notera att varje sträng anges på endast en rad. För att infoga en ny rad inuti en sträng används uttrycket /r. Exempel:

   example.string=Information på rad ett./rInformation på rad två.

   Detta ger följande utseende i gränssnittet:

   Information på rad ett.
   Information på rad två.

Anpassa språktermer i flexiteAdmin

I flexiteAdmin anges anpassade textsträngar per språk och fungerar som komplement till ordinarie språkfiler.

Ordinarie språkfiler

Ordinarie språkfiler ligger i katalogen C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\languages:

• en.lang.ini — Engelska
• sv.lang.ini — Svenska

Anpassade språkfiler

Anpassade språkfiler placeras i katalogen C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\languages\custom.

flexiteAdmin stödjer flera språkfiler per språk, där filerna måste namnges efter följande format:

{valfritt namn}.{språk}.lang.ini

Exempel för språkfil på svenska:

mycustomfile.sv.lang.ini

Filerna läses i alfanumerisk ordning, där den senast lästa filen har företräde.

Hur flexiteAdmin väljer textsträngar

flexiteAdmin nyttjar variabler för att ange vilka textsträngar som ska visas i gränssnittet. Variabeln är densamma oavsett visningsspråk, och de faktiska textsträngarna hämtas från de individuella språkfilerna, baserat på valt språk.

Förlopp

Som exempel på förlopp kan vi ta textsträngen för menyalternativet 'Startsida' i huvudmenyn på språket Svenska. Variabeln för denna sträng är main.menu.home.caption.

1. flexiteAdmin inleder med att ta reda på huruvida det existerar anpassade språkfiler för aktuellt språk; C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\languages\custom\*.sv.lang.ini.
   Om anpassade språkfiler existerar, gå till punkt 2.
   Om anpassade språkfiler INTE existerar, gå till punkt 3.
2. flexiteAdmin söker efter strängen för main.menu.home.caption i de anpassade språkfilerna.
   Om strängen existerar i en av de anpassade språkfilerna hämtas den och visas i gränssnittet.
   Om strängen existerar i flera av de anpassade språkfilerna hämtas den från den sista filen, enligt alfanumerisk ordning, och visas i gränssnittet.
   Om strängen inte existerar i de anpassade språkfilerna, gå till punkt 3.
3. flexiteAdmin söker efter strängen för main.menu.home.caption i standard-språkfilen (C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\languages\sv.lang.ini) och visar den i gränssnittet.

Tillvägagångssätt för att ange egna termer

Språkfilerna i flexiteAdmin är uppbyggda med key-value pairs i följande format:

nyckel=värde

• nyckel — Unikt ID för textsträngen. Denna nyckel används i flexiteAdmin för att ange var textsträngen ska nyttjas. Denna nyckel FÅR INTE ändras.
• värde — Den textsträng som visas i gränssnittet. Det är detta värde som kan anpassas med egna termer.

Procedur

Proceduren för att ange skräddarsydda strängar för Svenska ser ut på följande vis:

1. Skapa en fil enligt formatet för den fil den ska agera komplement till, exempelvis mycustomfile.sv.lang.ini, under katalogen C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\languages\custom.

2. Redigera den nya ..\languages\custom\mycustomfile.sv.lang.ini och lägg till de strängar som ska ändras. Det enklaste förfarandet är att söka upp strängarna i standard-språkfilen, kopiera in dem i den nya filen, och där utföra önskade ändringar.

   Notera att varje sträng anges på endast en rad. För att infoga en ny rad inuti en sträng används uttrycket /r. Exempel:

   example.string=Information på rad ett./rInformation på rad två.

   Detta ger följande utseende i gränssnittet:

   Information på rad ett.
   Information på rad två.

Begränsningar och rekommendationer

När nya textsträngar författas måste följande punkter beaktas:

• Den nya textsträngen BÖR INTE överskrida antalet tecken i den befintliga textsträngen. En textsträng som är för lång kan förstöra både layout och funktionalitet. För textsträngar för knappar är detta kritiskt.
• Den nya textsträngen BÖR avslutas på samma vis som den befintliga. Om den befintliga textsträngen exempelvis avslutas med ett kolon ('😂 så bör även den nya göra det. Detta för att behålla konsekvent formatering.
• Ha i åtanke att en och samma textsträng kan nyttjas på flera ställen i applikationerna.

Vid frågor gällande författande av textsträngar, vänligen kontakta Flexite AB Helpdesk.

Ansvar vid uppgradering och hotfix-patchning

Vid uppgradering och hotfix-patchning kan det ske förändringar kring nyttjande och utformning av textsträngar. Det är därför kritiskt att efter varje uppgradering och hotfix-patchning som innefattat förändringar av språkfiler gå igenom samtliga anpassade termer och jämföra dem med de nya språkfilerna.

För information om ansvarsfrågan gällande anpassade språktermer i språkfiler, vänligen kontakta Flexite AB Helpdesk.

Certifikathantering

Certifikat nyttjas för att säkra upp anslutningar mellan klient och server eller mellan två servrar och möjliggör validering av identiteten av motparten.

I en standardinstallation där Microsoft IIS nyttjas som webbserver nyttjar IIS Microsoft Windows Certificate Store som källa för HTTPS-certifikat.

flexiteCLIENT och flexiteProcessEngine nyttjar Microsoft Windows Certificate Store för att verifiera certifikat medan flexiteWEB och flexiteAdmin nyttjar Javas keystore belägen i Tomcat-paketet.

I det fall systemet ansluter till exempelvis en e-postserver över krypterat protokoll så måste rotcertifikatet för den Certificate Authority som utfärdat det certifikat som e-postservern nyttjar finnas installerat i både Windows Certificate Store och Javas keystore.

Certifikat för flexiteCLIENT och flexiteProcessEngine

flexiteCLIENT har behov av att verifiera certifikat vid krypterad kommunikation med exempelvis databasserver och SMTP-server.

flexiteProcessEngine har behov av att verifiera certifikat vid krypterad kommunikation med exempelvis databasserver, SMTP-server samt integrationer med externa system.

Både flexiteCLIENT och flexiteProcessEngine nyttjar Microsoft Windows Certificate Store (Local Computer) för att verifiera dessa certifikat.

För certifikat utfärdade av stora publika aktörer innebär detta sällan någon extra administration eftersom rotcertifikat för dessa utfärdare tillhandahålls och uppdateras av Microsoft. Uppdatering av dessa certifikat hanteras som standard utav Windows Update.

För certifikat utfärdade av en privat Certificate Authority (CA) kan certifikatet eller certifikatkedjan för denna CA behöva importeras manuellt i 'Trusted Root Certification Authorities' i Windows Certificate Store för 'Local Computer'.

Importera CA-certifikat i Windows Certificate Store

För information om installation av rotcertifikat, se dokumentation från Microsoft:

https://learn.microsoft.com/en-us/windows-hardware/drivers/install/trusted-root-certification-authorities-certificate-store

Certifikat för flexiteWEB och flexiteAdmin

flexiteWEB och flexiteAdmin har behov av att verifiera certifikat vid krypterad kommunikation med exempelvis databasserver, SMTP-server samt LDAP-server.

flexiteWEB och flexiteAdmin nyttjar Javas keystore 'cacerts', belägen i Tomcat-paketet, för att verifiera certifikat som nyttjas av extern server för att kryptera anslutningar. Sökvägen för denna keystore ser ut på följande vis i en standardinstallation:

C:\tomcat\jdk\lib\security\cacerts

I likhet med Windows Certificate Store innehåller denna Java keystore som standard certifikat för de stora publika aktörerna, varpå ett publikt utfärdat certifikat sällan kräver någon extra administration. Till skillnad från Windows Certificate Store, som uppdateras via Windows Update, uppdateras dessa Java keystores enbart manuellt vid uppdatering/installation av ny Java.

För certifikat utfärdade av en privat Certificate Authority (CA) måste certifikatet, alternativt certifikatkedjan, för denna CA manuellt importeras i Javas keystore.

Undantag

Certifikat för Identity Provider för SAML installeras i en separat keystore. För information om SAML, se avsnitt Single Sign-On — SAML.

Importera CA-certifikat i Java keystore

För att importera certifikat i Java keystore använder vi oss av verktyget 'keytool' som levereras med JDK. Information om detta verktyg finns att läsa hos Oracle:

https://docs.oracle.com/en/java/javase/11/tools/keytool.html

Mellanslag och CMD

I CMD och Powershell nyttjas mellanslag som ett skiljetecken mellan kommandon. Filer och sökvägar som innehåller mellanslag måste därmed inneslutas i citationstecken.

Visa befintliga certifikat

Det är möjligt att exportera information om befintliga certifikat i aktuell Java keystore.

1. Öppna en kommandotolk och navigera till C:\tomcat\jdk\bin.

2. Kör följande kommando:

   keytool.exe -list -v -cacerts -storepass changeit > cacerts.txt

   Detta exporterar detaljerad information om samtliga certifikat i installerad Java keystore 'cacerts' till den lokala filen cacerts.txt.

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • cacerts — Alias för aktuell, installerad, Java keystore 'cacerts'.
   • storepass {lösenord} — Lösenordet för aktuell keystore. Standard för keystore 'cacerts' är 'changeit'.
   • > {filnamn} — CMD-kommando för att ange att resultatet av föregående kommando ska skrivas till fil istället för konsol. Filnamn anges med fullständig sökväg. I detta exempel har vi valt att skriva till en fil i den lokala katalogen; 'cacerts.txt'.

Exempel

Exempel på information som visas för varje certifikat med keytool.exe -list -v:

Alias name: certificate_name
Creation date: 14 maj 2024
Entry type: trustedCertEntry
Owner: CN=ca.company.com
Issuer: CN=ca.company.com
Serial number: 0123456789abcdef
Valid from: Tue Apr 04 02:00:00 CEST 2023 until: Mon Apr 04 02:00:00 CEST 2033
Certificate fingerprints:
         SHA1: 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33
         SHA256: 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:
77:88:99:AA:BB:CC:DD:EE:FF
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Importera certifikat

1. Erhåll rotcertifikat, alternativt certifikatkedja, från Certificate Authority.

2. Öppna en kommandotolk och navigera till C:\tomcat\jdk\bin.

3. För att importera ett certifikat till aktuell Java keystore 'cacerts', kör följande kommando:

   keytool.exe -importcert -cacerts -storepass changeit -alias flexite_MyCACert -file "C:\temp\mycacert.cer"

   • importcert — Kommando för att importera certifikat i angiven keystore.
   • cacerts — Alias för aktuell, installerad, Java keystore 'cacerts'.
   • storepass {lösenord} — Lösenordet för aktuell keystore.
     Standard för keystore 'cacerts' är 'changeit'.
   • alias {namn} — Unikt namn som representerar certifikatet. Används för att identifiera certifikatet i keystore. I detta exempel: 'flexite_MyCACert'
     Det är rekommenderat att följa samma namngivningsschema för samtliga certifikat som importeras för att underlätta framtida administration. Exempelvis 'flexite_smtp', 'flexite_sql'.
   • file {sökväg} — Fullständig sökväg till det certifikat som ska importeras. I detta exempel: 'C:\temp\mycacert.cer'

4. För att verifiera att ett certifikat importerats, kör följande kommando:

   keytool.exe -list -v -cacerts -storepass changeit -alias flexite_MyCACert

   Detta skriver ut detaljerad information om certifikatet med angivet alias till konsolen.

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • cacerts — Alias för aktuell, installerad, Java keystore 'cacerts'.
   • storepass {lösenord} — Lösenordet för aktuell keystore.
     Standard för keystore 'cacerts' är 'changeit'.
   • alias {namn} — Det alias som angavs för certifikatet vid import. I detta exempel: 'flexite_MyCACert'

Certifikat för flexitePortal

flexitePortal har behov av att verifiera certifikat vid krypterad kommunikation med flexiteWEB.

flexitePortal nyttjar, i likhet med flexiteWEB och flexiteAdmin, Javas keystore 'cacerts', belägen i Tomcat-paketet, för att verifiera certifikat som nyttjas av extern server för att kryptera anslutningar. Sökvägen för denna keystore ser ut på följande vis i en standardinstallation:

C:\tomcat\jdk\lib\security\cacerts

För information om hantering av certifikat i 'cacerts', se Certifikat för flexiteWEB och flexiteAdmin.

Undantag

Certifikat för Identity Provider för SAML installeras i en separat keystore. För information om SAML, se avsnitt Single Sign-On — SAML.

Uppgradering av Apache Tomcat/Java

Java keystore är inkluderat i installationspaketet för Apache Tomcat och Java och ersätts därmed som standard vid uppgradering. Eventuella certifikat som installerats manuellt måste därmed vid uppgradering importeras i den nya Java keystore. Det är således kritiskt att vid uppgradering av Java alltid kontrollera förekomsten av manuellt installerade certifikat i keystore 'cacerts' innan uppgradering genomförs.

Det är även tekniskt möjligt att ersätta den nya Java keystore med den gamla efter uppgradering, men detta är inte rekommenderat då det medför en risk att standardcertifikat inte erhåller nödvändiga uppdateringar.

Exportera certifikat från befintlig Java keystore

I det fall de certifikat som är installerade i Java keystore inte finns tillgängliga från annan källa kan de exporteras från befintlig keystore.

För att exportera korrekt certifikat är det kritiskt att veta vilka alias som tilldelats certifikaten när de importerats.

Identifiera manuellt installerade certifikat

Känd namngivning

I det fall ett särskilt namngivningsschema följts är det möjligt att nyttja CMD's kommando findstr för att filtrera innehållet i en keystore och enbart lista de certifikat vars alias innehåller en specifik fras:

keytool.exe -list -cacerts -storepass changeit | findstr {sökfras}

• list — Kommando för att visa information om innehåll i angiven keystore.
• cacerts — Alias för aktuell, installerad, Java keystore 'cacerts'.
• storepass {lösenord} — Lösenordet för aktuell keystore.
  Standard för keystore 'cacerts' är 'changeit'.
• | findstr {sökfras} — CMD-kommando för att ange att från resultatet av föregående kommando ska enbart rader som innehåller angiven sökfras visas.

Exempel

I detta exempel har vi filtrerat innehållet i vår installerade cacerts keystore på frasen ' flexite' vilket resulterat i två sökträffar med alias ' flexite_smtp' respektive ' flexite_sql'.

keytool.exe -list -cacerts -storepass changeit | findstr flexite
flexite_smtp, 1 juni 2023, trustedCertEntry,
flexite_sql, 1 juni 2023, trustedCertEntry,

Den information som visas för varje certifikat är:

• Alias name — Certifikatets alias i Java keystore.
• Creation date — Datum då certifikatet importerades i Java keystore.
• Entry type — Anger typ av objekt. För betrodda certifikat är typen 'trustedCertEntry'.

Okänd namngivning

Om namngivningen av alias för importerade certifikat är okänd är det möjligt att utesluta ordinarie inkluderade certifikat genom att manuellt jämföra befintlig, installerad, keystore med den som levererades i installationspaketet för befintlig version.

Standard Java keystore

Export av en komprimerad lista över samtliga certifikat i installerad Java keystore 'cacerts' kan utföras med följande kommando:

keytool.exe -list -cacerts -storepass changeit > cacerts.txt

Detta exporterar kortfattad information om samtliga certifikat i installerad Java keystore 'cacerts' till den lokala filen cacerts.txt.

• list — Kommando för att visa information om certifikat från angiven keystore.
• cacerts — Alias för aktuell, installerad, Java keystore 'cacerts'.
• storepass {lösenord} — Lösenordet för aktuell keystore.
  Standard för keystore 'cacerts' är 'changeit'.
• > {filnamn} — CMD-kommando för att ange att resultatet av föregående kommando ska skrivas till fil istället för konsol. Filnamn anges med fullständig sökväg. I detta exempel har vi valt att skriva till en fil i den lokala katalogen; 'cacerts.txt'.

Manuellt angiven Java keystore

Export av en komprimerad lista över samtliga certifikat i en manuellt angiven Java keystore till en lokal fil kan utföras med följande kommando:

keytool.exe -list -keystore "C:\temp\tomcat\jdk\lib\security\cacerts" -storepass changeit > cacerts.txt

Detta exporterar kortfattad information om samtliga certifikat i en manuellt angiven Java keystore till den lokala filen cacerts.txt.

• list — Kommando för att visa information om innehåll i angiven keystore.
• keystore — Fullständig sökväg till Java keystore. I detta exempel: 'C:\temp\tomcat\jdk\lib\security\cacerts'
• storepass {lösenord} — Lösenordet för aktuell keystore.
  Standard för keystore 'cacerts' är 'changeit'.
• > {filnamn} — CMD-kommando för att ange att resultatet av föregående kommando ska skrivas till fil istället för konsol. Filnamn anges med fullständig sökväg. I detta exempel har vi valt att skriva till en fil i den lokala katalogen; 'cacerts.txt'.

Exportera certifikat

Med certifikatens alias identifierade är det möjligt att exportera certifikaten till fil i förberedelse för import i den nya Java keystore.

För att exportera ett certifikat från Java keystore 'cacerts', kör följande kommando:

keytool.exe -exportcert -cacerts -storepass changeit -alias flexite_MyCACert -file "C:\temp\mycacert.cer"

• exportcert — Kommando för att exportera angivna certifikat från angiven keystore.
• cacerts — Alias för aktuell, installerad, Java keystore 'cacerts'.
• storepass {lösenord} — Lösenordet för aktuell keystore.
  Standard för keystore 'cacerts' är 'changeit'.
• alias {namn} — Det alias som är angivet för certifikatet som ska exporteras. I detta exempel: 'flexite_MyCACert'.
• file {sökväg} — Fullständig sökväg till den fil dit certifikatet ska exporteras. I detta exempel: 'C:\temp\mycacert.cer'.

Importera certifikat

Med certifikaten exporterade från befintlig Java keystore är det dags att importera dem i den nya Java keystore. För information om import av certifikat, se avsnitt Importera CA-certifikat i Java keystore.

Migrering

Vid migrering av en flexite-installation från en server till en annan måste även eventuella manuellt installerade certifikat migreras. Det är således kritiskt att vid migrering alltid kontrollera förekomsten av manuellt installerade certifikat innan migrering genomförs.

Certifikat för flexiteCLIENT och flexiteProcessEngine

I det fall de certifikat som är manuellt installerade i Windows Certificate Store inte finns tillgängliga från annan källa kan de exporteras från befintlig certificate store.

Certifikat som nyttjas av flexite, och Microsoft IIS, för att identifiera lokal server återfinns som standard under 'Personal' i Windows Certificate Store för 'Local Computer'.

Certifikat som nyttjas för att verifiera certifikat hos en fjärrserver återfinns som standard under 'Trusted Root Certification Authorities' i Windows Certificate Store för 'Local Computer'.

Certifikat för flexiteWEB och flexiteAdmin

I det fall samma version av Apache Tomcat och Java ska köras på den nya servern är det rekommenderade förfarandet att kopiera befintlig Java keystore 'cacerts' från den gamla servern till den nya.

Sökväg för Java keystore 'cacerts' i en standardinstallation är: C:\tomcat\jdk\lib\security\cacerts.

I det fall en uppgradering av Apache Tomcat och Java utförs i samband med migrering är förfarandet detsamma som vid en normal uppgradering; Uppgradering av Apache Tomcat/Java.

E-ID för identifiering och signering

Det är möjligt att nyttja e-legitimation för autentisering och signering i flexite.

flexiteWEB

I flexiteWEB är autentisering via E-ID exempelvis användbart när åtkomst behöver ges till utomstående personer och det inte är rimligt att skapa enskilda användarkonton.

flexitePortal

flexitePortal är en webbapplikation där användare utan personligt flexite-konto, såsom exempelvis medborgare, kan logga in och hantera sina personliga ärenden i flexite.

Autentisering av dessa användare kan antingen genomföras med E-ID eller med SAML (Single Sign-On — SAML).

För nya användare skapas en unik Identitet i flexite vid inloggning, och det är till denna Identitet som ärenden kommer att kopplas.

För återvändande användare sker inloggning med den Identitet som tidigare skapats i flexite.

Licens och nycklar från Svensk e-identitet

Denna funktionalitet kräver en tilläggslicens för flexite samt konto och nycklar från Svensk e-identitet. Det är generellt sett två typer av nycklar som krävs:

• En nyckel för Svensk e-identitets API; GrandID.
• En uppsättning nycklar för varje leverantör som ska nyttjas.

Aktivering av e-legitimation för autentisering i processer konfigureras per process i flexiteCLIENT, se flexiteCLIENT Metodisk Manual.

Besök Svensk e-identitet för mer information om deras tjänster:

https://e-identitet.se/

Konfiguration av flexiteWEB

API-nycklar från Svensk e-identitet levereras i form av textsträngar. För att kunna aktivera nyttjande av E-ID måste dessa nycklar först läggas till i konfigurationsfilen C:\tomcat\webapps\flexite\WEB-INF\classes\integration\eid\ext-verification.conf:

• Ange vilka leverantörer som ska presenteras som tillgängliga i flexiteCLIENT, separerade med mellanslag. Notera att det inte är möjligt att lägga till fler leverantörer än de som finns som standard (BankID Telia Google eIDAS)

  Providers=BankID Telia Google eIDAS

• Ange API-nyckel:

  # API KEY
  GrandID.apiKey=

• Ange nycklar för de individuella leverantörerna:

  # BANKID
  BankID.Version=30
  GrandID.BankID.auth=
  GrandID.BankID.sign=
  # BANKIDPHONE
  GrandID.BankIDPhone.auth=
  # TELIA
  GrandID.Telia.auth=
  GrandID.Telia.sign=
  # GOOGLE
  GrandID.Google.auth=
  # EIDAS
  GrandID.eIDAS.auth=

BankID

flexite stödjer GrandID BankID API samt GrandID BankID Phone API. Dessa två API-lösningar kräver i dagsläget individuella licenser och nycklar.

GrandID BankID API

GrandID BankID API används för situationer där den utomstående personen själv initierar autentisering via BankID, exempelvis vid kvittering av en publik e-service. Personen kan då välja att använda BankID på samma eller annan enhet för autentisering.

flexite har stöd för GrandID BankID API version 3.x (BankID.Version= 30) och nyttjar samma nyckel för auth och sign.

# BANKID
BankID.Version=30
GrandID.BankID.auth=
GrandID.BankID.sign=

GrandID BankID Phone API

GrandID BankID Phone API används i situationer där en handläggare initierar autentisering via BankID för en utomstående person, exempelvis vid arbete över telefon i en kundtjänst. I dessa fall får personen en notifikation från sin BankID-applikation om att en autentisering begärts utav kundtjänsten i fråga, och personen kan då identifiera sig i den aktuella BankID-applikationen.

# BANKIDPHONE

GrandID.BankIDPhone.auth=

Konfiguration av flexitePortal

flexitePortal är en webbapplikation som är avsedd att användas som en webbportal där medborgare kan logga in och hantera sina personliga ärenden i flexite.

API-nycklar från Svensk e-identitet levereras i form av textsträngar. För att kunna aktivera nyttjande av E-ID måste dessa nycklar först läggas till i konfigurationsfilen C:\tomcat\webapps\flexitePortal\WEB-INF\classes\grandId.json:

{
  "url": "https://client.grandid.com/json1.1/",
  "apiKey": "",
  "providers": {}
}

• Ange GrandID API-nyckel:

  "apiKey": "{YOUR_API_KEY}",

• Ange nycklar för de individuella leverantörerna:

  "providers": {
    "bankid": {
      "serviceKey": "{YOUR_BANKID_KEY}"
    }

E-postserver — Google Gmail

flexiteCLIENT > Inställningar > Processmotor > Mail

flexite har stöd för att nyttja Google Gmail som e-postserver för utgående e-post via Google Gmail API. Observera att denna typ av lösning kräver tillgång till tjänster från Google och att det är Googles licensvillkor som gäller.

För information om Gmail API, se dokumentation från Google:

https://developers.google.com/gmail/api/guides

Konfiguration av inställningar för e-postserver för utgående e-post utförs i flexiteCLIENT.

Fig.25: flexiteCLIENT > Inställningar > Processmotor > Mail. Inställningar för protokollet 'Gmail API'.

• Protokoll — Det protokoll som ska nyttjas för kommunikation med e-postservern. Val av protokoll påverkar övriga inställningar. Tillgängliga protokoll:
  • SMTP — Anslut till e-postserver via protokollet 'SMTP'.
  • Gmail API — Nyttja Google Gmail som e-postserver via API.
  • Microsoft Graph API — Nyttja Microsoft 365 som e-postserver via Graph API.
• Klient ID — Motsvarar 'Client ID' som tillhandahålles av Google.
• Klientkod — Motsvarar 'Client secret' som tillhandahålles av Google.
• Uppdatera token — Motsvarar 'Refresh token' som tillhandahålles av Google.

Avsändare

Med Google Gmail API som e-postserver för utgående e-post tillhandahålles avsändarnamn och avsändaradress via det Google-konto som är knutet till tjänsten.

På grund av detta ignoreras samtliga avsändarnamn och avsändaradresser som konfigurerats i flexite.

E-postserver — Individuell autentisering av e-postavsändare

Det finns scenarion där en e-postserver som nyttjar protokollet SMTP kan kräva individuell autentisering för varje avsändaradress som används för att skicka e-post. För att möta detta krav måste varje individuell avsändaradress som nyttjas i flexite konfigureras med tillhörande användarnamn och lösenord.

Konfiguration av avsändare utförs i flexiteCLIENT.

E-postservrar som nyttjar protokollet 'Gmail API' alternativt 'Microsoft Graph API' hanterar utökade avsändare på annat vis. För information om dessa protokoll, se följande kapitel:

• E-postserver — Google Gmail
• E-postserver — Microsoft 365

Avsändaradresser för globala avsändare

flexiteCLIENT > Inställningar > E-posthantering > Globala avsändare

Globala avsändare är de avsändaradresser som nyttjas av flexites systemtjänster. Avsändare är unika för varje språk, och adresser måste konfigureras för varje aktivt språk.

När e-postservern kräver individuell autentisering är det rekommenderat att för 'Avsändaradress för e-post' inaktivera 'Använd personlig e-post som avsändare' och istället nyttja en statisk avsändaradress.

För mer information om avsändare och språk, se ' flexiteCLIENT Metodisk Manual'.

Avsändaradresser för anpassade avsändare

flexiteCLIENT > Inställningar > E-posthantering > Anpassade avsändare

Utöver globala avsändare är det möjligt att ange anpassade avsändare för flertalet processrelaterade funktioner. Dessa avsändare konfigureras manuellt i varje individuell process samt Periodisk Statistik.

Under 'Anpassade avsändare' presenteras en lista över samtliga anpassade avsändaradresser i systemet och var de är angivna.

För mer information om detta verktyg samt konfiguration av processer och Periodisk Statistik, se ' flexiteCLIENT Metodisk Manual'.

Autentiseringsuppgifter för avsändaradresser

flexiteCLIENT > Inställningar > Processmotor > Mail

Åtminstone ett konto måste finnas angivet för att e-post ska kunna skickas från systemet.

Genom att aktivera inställningen 'Aktivera ytterligare avsändare' ges möjligheten att konfigurera multipla avsändaradresser med individuella kontouppgifter.

Om en avsändaradress misslyckas med autentisering mot e-postserver kommer istället systemkontot nyttjas som avsändare.

E-postserver — Microsoft 365

flexiteCLIENT > Inställningar > Processmotor > Mail

flexite har stöd för att nyttja Microsoft 365 som e-postserver för utgående e-post via Microsoft Graph API. Observera att denna typ av lösning kräver tillgång till tjänster från Microsoft och att det är Microsofts licensvillkor som gäller.

För information om Graph API, se dokumentation från Microsoft:

https://learn.microsoft.com/en-us/graph/auth/auth-concepts

Konfiguration av inställningar för e-postserver för utgående e-post utförs i flexiteCLIENT.

Fig.26: flexiteCLIENT > Inställningar > Processmotor > Mail. Inställningar för protokollet 'Microsoft Graph API'.

• Protokoll — Det protokoll som ska nyttjas för kommunikation med e-postservern. Val av protokoll påverkar övriga inställningar. Tillgängliga protokoll:
  • SMTP — Anslut till e-postserver via protokollet 'SMTP'.
  • Gmail API — Nyttja Google Gmail som e-postserver via API.
  • Microsoft Graph API — Nyttja Microsoft 365 som e-postserver via Graph API.
• Avsändarnamn — Visar angivet namn på avsändare för systemteknisk e-post. Ignoreras av Graph API som istället hämtar avsändarnamn från angivet konto för 'Avsändaradress'.
• Avsändaradress — E-postadress för avsändare av systemteknisk e-post, även betecknat systemkonto. Används också som avsändare i det fall ordinarie avsändare saknar e-postadress eller misslyckas med autentisering mot e-postserver. Måste bestå av en adress som existerar i aktuell 'Tenant ID' hos Microsoft.
• Tenant ID — Motsvarar 'Tenant ID' (även kallat 'Directory ID') som tillhandahålles av Microsoft.
• Application ID — Motsvarar 'Application ID' (även kallat 'Client ID') som tillhandahålles av Microsoft.
• Client secret — Motsvarar 'Client secret' som tillhandahålles av Microsoft.

Avsändare

Med Microsoft Graph API som e-postserver för utgående e-post måste samtliga konfigurerade avsändaradresser i flexite finnas tillgängliga i aktuell 'Tenant ID' hos Microsoft.

Eventuella avsändarnamn i flexite ignoreras, istället hämtas avsändarnamn från kontot för den aktuella e-postadressen hos Microsoft.

I det fall en avsändaradress i flexite inte existerar hos Microsoft faller flexite tillbaka på att skicka e-postmeddelandet med systemkontot som avsändare.

E-postintegrationer

Med Microsoft Graph API som e-postserver för utgående e-post är det möjligt att nyttja de befintliga systeminställningarna för autentisering vid konfiguration av e-postintegrationerna 'Uppgift för meddelandelåda' samt 'ExtSysMailBox'. E-postadress för den e-postlåda som ska läsas måste anges separat.

Detta underlättar exempelvis arbetet vid uppdatering av 'Client secret'.

flexite — Flera instanser på samma server

Det är möjligt att köra multipla instanser av flexite på samma applikationsserver. I detta kapitel beskriver vi två lösningar:

• Multipla unika installationer — Varje instans av flexite nyttjar en unik installation av samtliga applikationer. Detta är den rekommenderade lösningen.
• Multipla databaser i samma installation — En gemensam installation av flexiteProcessEngine och flexiteWEB nyttjas av multipla databaser. Unika installationer av flexiteCLIENT och flexiteAdmin nyttjas för att administrera de individuella databaserna.

Det är kritiskt att de individuella instanserna använder sig av unika kommunikationsportar för samtliga systemtjänster.

Multipla unika installationer

Den rekommenderade lösningen för att köra multipla instanser av flexite på samma applikationsserver är att nyttja multipla unika installationer av samtliga applikationer. Detta säkerställer att instanserna är fristående och inte påverkar varandra.

Databas

När multipla system ska köras på samma databasserver krävs det att databaserna utöver unika namn använder unika filnamn. Denna namngivning sker enklast under installationsprocessen:

1. Välj databas för återställning och ange önskat, unikt, databasnamn.
2. Navigera till 'Files' och se till att filnamnen för samtliga filer under 'Restore As' är unika.
3. Slutför återställning samt konfiguration av databas i enlighet med instruktionerna för en standardinstallation (Installera standarddatabas).

flexiteProcessEngine

Den vanligaste lösningen för multipla instanser av flexiteProcessEngine är att köra flera unika installationer på samma applikationsserver. Detta kräver att en ny instans av flexiteProcessEngine installeras i en unik katalog; 'C:\tomcat\flexite\{flexiteProcessEngine}'. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteProcessEngine), men unika namn, sökvägar och portar måste nyttjas för varje instans.

Ange unikt namn samt unika portar för samtliga instanser av flexiteProcessEngine i C:\tomcat\flexite\{flexiteProcessEngine}\flexiteProcessEngine.ini:

• Ange unikt namn:

  [Service]
  Name=flexiteProcessEngine {processName}
  DisplayName={displayName} %version

  'Name' måste inledas med ' flexiteProcessEngine', och följas av en unik benämning. 'DisplayName' är det namn som visas i 'Services'.

• Ange unika kommunikationsportar:

  [ExternalData]
  DLLInfoPort={dllInfoPort} (default: 25020)
  DLLDataPort={dllDataPort} (default: 35020)

Bibliotek för att skicka och hämta e-post

Biblioteken för att skicka och hämta e-post, EASendMailObj.dll respektive EAGetMailObj.dll, registreras globalt för varje server i Windows register. Detta betyder att samtliga flexite-applikationer på servern nyttjar samma bibliotek. Om sökvägen för det registrerade biblioteket ändras måste det registreras på nytt.

Detta har som effekt att uppdateringar till det registrerade biblioteket påverkar samtliga flexite-applikationer på samma server. På samma vis betyder det även att uppdateringar till bibliotek som inte är registrerade inte har någon inverkan på någon flexite-applikation.

Kontrollera registrerade sökvägar

Det är möjligt att ta reda på sökvägarna för nuvarande registrerade bibliotek med följande CMD-kommandon:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\" /f EASendMailObj.dll /d /s
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\" /f EAGetMailObj.dll /d /s

Dessa kommandon returnerar en lista med nycklar för respektive DLL där den fullständiga sökvägen går att utläsa.

flexiteWEB

Den vanligaste lösningen för multipla instanser av flexiteWEB är, precis som för flexiteProcessEngine, att köra flera unika installationer på samma applikationsserver. Detta kräver att en ny instans av flexiteWEB installeras i en unik katalog; C:\tomcat\webapps\{flexiteWEB}. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteWEB), men unika sökvägar måste nyttjas för varje instans.

1. Ange unika sökvägar för samtliga instanser av flexiteWEB:

   • C:\tomcat\webapps\{flexiteWEB}\WEB-INF\classes\settings\flexite.conf

     ### Tomcat settings
     base-dir=/{flexiteWEB}/
     mobile-dir=/{flexiteWEB}/m/
     log-file=c:/tomcat/flexite/log/{flexiteWEB}/flexite.log
     ...
     theme-dir=/{flexiteWEB}/theme/modern/

   • C:\tomcat\webapps\{flexiteWEB}\WEB-INF\classes\settings\pool.conf

     logfile=c:/tomcat/flexite/log/{flexiteWEB}/pool.log

2. Skapa den katalog för som angivits för log-file:

   C:\tomcat\flexite\log\{flexiteWEB}

flexiteAdmin

Till skillnad från flexiteWEB stödjer flexiteAdmin enbart en databaskoppling per installation. Detta betyder att en ny instans av flexiteAdmin måste installeras i en ny katalog; C:\tomcat\webapps\{flexiteAdmin}. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteAdmin), men unika sökvägar måste nyttjas för varje instans.

1. Ange unika sökvägar för samtliga instanser av flexiteAdmin:

   • C:\tomcat\webapps\{flexiteAdmin}\WEB-INF\classes\settings\flexiteAdmin.conf

     base-dir=/{flexiteAdmin}/
     log-file=c:/tomcat/flexite/log/{flexiteAdmin}/flexiteAdmin.log

2. Skapa den katalog för som angivits för log-file:

   C:\tomcat\flexite\log\{flexiteAdmin}

flexiteCLIENT

Det är tekniskt möjligt att nyttja en och samma flexiteCLIENT-installation till att administrera två flexite-system, designerade 'Skarp' respektive 'Test' under konfiguration av databaskopplingar. Det är dock starkt rekommenderat att undvika detta eftersom det kräver att båda systemen alltid kör samma version, inklusive hotfix-version.

Det rekommenderade förfarandet är att installera och nyttja individuella flexiteCLIENT för varje flexite-system. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteCLIENT).

I flexiteCLIENT måste konfiguration utföras för att matcha inställningarna gjorda i flexiteWEB och flexiteProcessEngine. För att komma åt inställningarna för 'Processmotor' krävs att flexiteCLIENT körs med kommandot flexite.exe /services.

1. Navigera till 'Inställningar > Webbinställningar > Länkar' och ange unika sökvägar:

   • flexiteWEB — URL för flexiteWEB.
     Exempel: https://flexite.company.com/{flexiteWEB}/
   • flexiteWEB Webservice — URL för flexiteWEB Web Service. Placerad under 'services' i webbapplikationen. Exempel: https://flexite.company.com/{flexiteWEB}/services/
   • flexiteAdmin URL — URL för flexiteAdmin.
     Exempel: https://flexite.company.com/{flexiteAdmin}/
   • Extern URL — URL för flexiteWEB i e-post till externa mottagare. Enbart tillgänglig om 'Extern server' är aktiverad.
     Exempel: https://ext.company.com/{flexiteWEB}/
   • URL för manual / URL för metodisk manual — URL för flexiteWEB respektive flexiteCLIENT manual. Som standard är de placerade under 'manual' i webbapplikationen.
     Exempel: https://flexite.company.com/{flexiteWEB}/manual/flexiteWEB_manual_sve.pdf
   • URL för flexiteAdmin manual — URL för flexiteAdmin manual.
     Exempel: https://flexite.company.com/{flexiteAdmin}/res/manual/flexiteAdmin_manual.html

2. Navigera till 'Inställningar > Processmotor > flexiteProcessEngine' och ange unika kommunikationsportar samt sökvägar:

   • Extern data, Kontroll port: {dllInfoPort}
   • Extern data, Data port: {dllDataPort}
   • Webservice, Port: {webservicePort}

   'Kontroll' och 'Data' måste stämma överens med portarna angivna i flexiteProcessEngine.ini.

Integration med Microsoft IIS

Om integration med IIS nyttjas (se avsnitt Microsoft IIS som webbserver) måste en pekare läggas till för de nya webbapplikationerna i ISAPI-integrationen:

Öppna filen C:\tomcat\conf\uriworkermap.properties, och ange sökvägar för de nya webbapplikationerna enligt följande format:

/{webappName}/*=ajp13
/{webappName}/servlet/*=ajp13

Multipla databaser i samma installation

Det är möjligt att koppla multipla databaser till en och samma installation av flexiteProcessEngine och flexiteWEB. Denna typ av lösning är mindre resurskrävande än multipla individuella installationer, men kan leda till ökade svarstider för tjänster eftersom de multipla databaskopplingarna hanteras seriellt av flexiteProcessEngine. Denna lösning rekommenderas därmed enbart för mindre, icke-kritiska, miljöer.

Ett exempel på användningsområde är en utbildningsmiljö som regelbundet behöver underhållas i form av nollställning av databaser och rensning av temporära filer. I detta fall kan tidsåtgången för det återkommande underhållet premieras framför prestanda och svarstider.

I detta exempel använder vi standardkonfigurationen avseende kommunikationsportar och sökvägar för flexiteProcessEngine och flexiteWEB.

flexiteCLIENT och flexiteAdmin

flexiteCLIENT och flexiteAdmin stödjer inte multipla databaser och kräver därmed individuella installationer per databas.

Databas

När multipla system ska köras på samma databasserver krävs det att databaserna utöver unika namn använder unika filnamn. Denna namngivning utförs enklast under installationsprocessen:

1. Välj databas för återställning och ange önskat, unikt, databasnamn ({dbName}).
2. Navigera till 'Files' och se till att filnamnen för samtliga filer under 'Restore As' är unika.
3. Slutför återställning samt konfiguration av databas i enlighet med instruktionerna för en standardinstallation (Installera standarddatabas).

flexiteProcessEngine

För denna lösning används en instans av flexiteProcessEngine för multipla databaser. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteProcessEngine), men unika uppgifter måste anges för varje databas.

Ange databaskopplingar i C:\tomcat\flexite\flexiteProcessEngine\flexiteProcessEngine.ini. Konfiguration för databasanslutning anges under sektionerna [Database.X], där 'X' är en nummerserie med start på 0.

Exempel: [Database.0]; [Database.1]; [Database.2] ...

[Database.0]
ConnectServerType=SQLServerOLE
ConnectDatabaseName={dbServer}:{dbName.001}
ConnectUserName={dbUserName.001}
ConnectUserPassword={dbUserPassword.001}
OnHoldSvc=1
AlarmSvc=1
StatisticsSvc=1
DBLinkSvc=1
LeadTimesSvc=1
SubstituteSvc=1
MailSvc=1
[Database.1]
ConnectServerType=SQLServerOLE
ConnectDatabaseName={dbServer}:{dbName.002}
ConnectUserName={dbUserName.002}
ConnectUserPassword={dbUserPassword.002}
OnHoldSvc=1
AlarmSvc=1
StatisticsSvc=1
DBLinkSvc=1
LeadTimesSvc=1
SubstituteSvc=1
MailSvc=1
...

Här är det även möjligt att per databas styra vilka tjänster som hanteras av aktuell flexiteProcessEngine.

flexiteWEB

För denna lösning används en instans av flexiteWEB som webbapplikation för multipla databaser. Varje individuell databaskoppling konfigureras som ett individuellt Projekt i webbapplikationen. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteWEB), men unika databaskopplingar och sökvägar måste anges för varje Projekt.

1. Navigera till C:\tomcat\webapps\flexite\.

   • Kopiera index.jsp till en ny fil för varje databas som ska kopplas. Det är via anrop mot dessa filer som inkommande trafik dirigeras till de individuella Projekten. Filnamnen MÅSTE följa formatet index*.jsp, och det är rekommenderat att de enbart innehåller gemener. För att förenkla underhåll kan det vara en god idé att döpa filerna efter respektive databas.
     Exempel: indexdbname.jsp

   • Ange Projektnamn individuellt för varje kopia av index.jsp. För att förenkla underhåll kan det vara en god idé att döpa projekten till samma namn som respektive databas.

     String ProjectID = "{dbName}";

2. Navigera till C:\tomcat\webapps\flexite\WEB-INF\classes\settings\.

   • Kopiera flexite.conf till en ny fil för varje databas som ska kopplas. Dessa filer utgör konfigurationsfilerna för de individuella Projekten. Filnamnen för dessa filer måste motsvara det individuella Projektnamnet angivet i respektive kopia av index.jsp.
     Exempel: {dbName}.conf

   • Ange sökvägar för logg- och tempfiler samt databaskoppling individuellt för varje kopia av flexite.conf (varje Projekt).

     ### Tomcat settings
     log-file=c:/tomcat/flexite/log/{dbName}.log
     ### Database settings
     db-service-name={dbServer}:{dbName}
     db-user-name={dbUserName}
     db-user-password={dbUserPassword}
     db-server-url=jdbc:sqlserver://{dbServer}:{dbPort};databaseName={dbName}

   • Ange samtliga aktiva projekt för webbapplikationen i pool.conf. I denna fil anges namnen på projekt-filerna i formatet {PROJEKT_I_VERSALER}.conf={projekt_i_gemener}.conf
     Exempel: DBNAME.conf=dbname.conf

     # Configuration file that contains additional project parameters.
     {DBNAME}.conf={dbname}.conf

Hantering av ordinarie 'index.jsp'

Ordinarie index.jsp pekar mot projektet ' flexite', och därmed via pool.conf mot filen flexite.conf med dess databaskoppling. Utöver att svara på anrop direkt mot filen svarar denna fil även på anrop mot rotkatalogen för flexiteWEB.

Om det inte finns något behov av att nå flexiteWEB direkt via rotkatalogen är rekommendationen att ta bort ordinarie index.jsp.

En annan möjlighet är att konfigurera och nyttja index.jsp och flexite.conf till ett utav de aktuella Projekten.

flexiteCLIENT

För denna lösning krävs en unik installation av flexiteCLIENT för varje databas. Den grundläggande installationsproceduren är densamma som för en standardinstallation (Installera flexiteCLIENT).

I varje individuell flexiteCLIENT måste konfiguration utföras för att matcha inställningarna gjorda i flexiteWEB och flexiteProcessEngine. För att komma åt inställningarna för 'Processmotor' krävs att flexiteCLIENT körs med kommandot flexite.exe /services.

• Navigera till 'Inställningar > Webbinställningar > Länkar' och ange unika sökvägar för flexiteWEB:
  • flexiteWEB — URL för flexiteWEB.
    Exempel: https://flexite.company.com/flexite/indexdbname.jsp
• Navigera till 'Inställningar > Processmotor'. Det är rekommenderat att Periodiciteten för de individuella tjänsterna är densamma för varje databas. Därtill bör nästa körning beräknas utifrån de individuella tjänsternas sluttid.

flexiteAdmin

För denna lösning krävs en unik installation av flexiteAdmin för varje databas. Den grundläggande installationen är densamma som för en standardinstallation (Installera flexiteAdmin).

Rekommendationer

För att underlätta administration är det rekommenderat att nyttja individuella kataloger för resurser för varje databas.

flexiteWEB

• Skapa individuella kataloger för resurser som ska vara tillgängliga direkt på webbservern. Detta innefattar exempelvis filer som ska nyttjas som 'Slut URL' i E-services samt 'Informationssida' på första formuläret i flexiteWEB.
  Exempel: C:\tomcat\webapps\flexite\customer\{dbName}
• Skapa individuella kataloger för publicering av Periodisk Statistik.
  Exempel: C:\tomcat\webapps\flexite\customer\{dbName}\ps

flexiteCLIENT

• I flexiteCLIENT, navigera till 'Inställningar > Processmotor/ Statistik' och ange individuella sökvägar för Periodisk Statistik:
  • Använd URL från globala inställningar — Måste vara inaktiv.
  • Mapp för publicering — Lokal sökväg för publicerad statistik. Måste matcha sökvägen till den katalog som skapats för Periodisk Statistik i flexiteWEB.
    Exempel: C:\tomcat\webapps\flexite\customer\{dbName}\ps
  • URL till mapp för publicering — URL för publicerad statistik. Måste matcha sökvägen till den katalog som skapats för Periodisk Statistik i flexiteWEB.
    Exempel: https://flexite.company.com/flexite/customer/{dbName}/ps

Uppgradering och patchning

För ett system kopplat mot multipla databaser är det kritiskt att de kopierade filerna jämförs med ordinarie filer efter varje utförd uppgradering och patchning. Detta för att säkerställa att uppdateringar även överförs till kopiorna.

flexiteWEB

• \index.jsp Jämför med kopior belägna i rotkatalogen.
• \WEB-INF\default_conf\flexite.conf Jämför med kopior belägna i \WEB-INF\classes\settings\.

flexite — Komponenten Identitet och flexitePortal

Komponenten Identitet används för att koppla en ny eller befintlig identitet till en registrering, exempelvis i form av ett personnummer.

flexitePortal är en webbapplikation där användare utan personligt flexite-konto, såsom exempelvis medborgare, kan logga in och hantera sina personliga ärenden i flexite. Här visas då de registreringar som via komponenten Identitet kopplats till den individuelle medborgarens personnummer. flexitePortal har ingen egen databasanslutning, utan all kommunikation sker via flexiteWEB API.

För information konfiguration av användarkonton, rättigheter och processer, se flexiteCLIENT Metodisk Manual.

Inloggning i flexitePortal

Inloggning i flexitePortal kräver autentisering mot en extern källa. Här finns två alternativ att välja på:

• E-ID — Se avsnitt E-ID för identifiering och signering.
• SAML — Se avsnitt Single Sign-On — SAML.

Använd identitet från flexitePortal för E-service E-ID

I flexitePortal skapas nya registreringar via publika E-services som hämtas från flexiteWEB API. I dessa E-services används komponenten Identitet för att knyta den individuelle medborgaren till registreringen.

Som standard kräver komponenten Identitet att medborgaren manuellt bekräftar sin identitet via BankID.

För att förenkla flödet för medborgaren är det möjligt att använda den redan autentiserade identiteten från aktuell session i flexitePortal. Detta uppnås genom att aktivera krav på identifiering via E-ID vid öppnande av E-service samt konfigurera nycklar i flexiteWEB och flexitePortal. På detta vis behöver medborgaren själv inte manuellt identifiera sig igen för att knyta sin identitet till registreringen.

Fallback

Vid felaktig eller utebliven konfiguration faller flexite tillbaka till att kräva manuell identifiering via E-ID.

Konfigurera flexiteWEB

I flexiteWEB anges vilka flexitePortal-installationer som ska tillåtas kringgå E-ID för E-service samt en hemlig nyckel som dessa installationer måste inneha.

Konfiguration utförs i C:\tomcat\webapps\{flexiteWEB}\WEB-INF\classes\settings\flexite.conf:

• Ange vilka flexitePortal-installationer som ska tillåtas kringgå E-ID vid öppnande av E-service. Anges i formatet fullständig URL för webbapplikationen. Detta är den publika URL som används av medborgare för att nå applikationen. Multipla URL separeras med mellanslag.

  portal-initialize-hosts=

  Exempel:

  portal-initialize-hosts=https://flexite.company.com/flexitePortal/

• Ange hemlig nyckel som flexitePortal måste presentera för att E-ID ska kunna kringgås.

  portal-initialize-secret-key=

Konfigurera flexitePortal

I flexitePortal anges den hemliga nyckel som ska presenteras till flexiteWEB.

Konfiguration utförs i C:\tomcat\webapps\{flexitePortal}\WEB-INF\classes\settings\flexitePortal.conf:

• Ange hemlig nyckel som flexitePortal ska presentera för flexiteWEB för att E-ID ska kunna kringgås. Denna nyckel måste matcha den nyckel som angivits i flexiteWEB.

  flexite-initialize-secret-key=

Verifiera i flexitePortal

1. Logga in i flexitePortal och öppna en E-service som kräver E-ID vid öppning.
2. Du ska nu inte behöva identifiera dig manuellt eftersom det hanteras av flexitePortal.

Utkast för flexitePortal

Utkast är en funktion i flexite där påbörjat arbete med en registrering sparas till ett personligt utkast. Detta utkast kan nyttjas för att fortsätta ett tidigare påbörjat arbete som av någon orsak avbrutits.

Utkast inte tillgängligt för publik E-service

I flexitePortal skapas nya registreringar via publika E-services. En publik E-service stödjer av säkerhetsskäl inte utkast eftersom alla registreringar då kopplas till det enskilda användarkonto som är angivet för E-servicen i fråga. Detta skulle medföra att samtliga utkast skulle vara tillgängliga för samtliga slutanvändare (exempelvis medborgare).

Möjligt att knyta utkast till Identitet med flexitePortal

I flexitePortal måste en användare identifiera sig med E-ID för att kunna logga in, vilket sparas som en unik Identitet i flexite. Det är möjligt att knyta ett utkast till denna Identitet när en publik E-service öppnas via flexitePortal.

Krav

För att utkast ska kunna knytas till en Identitet krävs det att flexiteWEB och flexitePortal är konfigurerade att använda identiteten från flexitePortal för E-service E-ID (Använd identitet från flexitePortal för E-service E-ID).

Utkastet knyts till den Identitet som skickas till flexiteWEB av flexitePortal.

Konfigurera flexite

Aktivering av utkast för flexitePortal utförs genom att köra ett databasskript. Detta kräver ett användarkonto med åtkomst till flexite databas.

Aktivera utkast

Aktivering av utkast för flexitePortal sker med följande SQL-skript:

INSERT INTO PROCESS_SETTINGS (REGISTRATION_ID, SKEY, SVALUE)
VALUES ({YOUR_REGISTRATION_ID}, 'Portal.Visitor.Drafts', 'Y')

• {YOUR_REGISTRATION_ID} — Det unika ID:t för den process där utkast ska aktiveras. Kan utläsas i kolumnen REGISTRATION_ID i tabellen REGISTRATION.

Se nuvarande konfiguration av utkast

Huruvida utkast för flexitePortal är aktiverat eller ej går att utläsa med följande SQL-skript:

SELECT *
FROM   PROCESS_SETTINGS
WHERE  SKEY = 'Portal.Visitor.Drafts';

Detta resulterar i en lista med samtliga processer (REGISTRATION_ID) där Portal.Visitor.Drafts har konfigurerats:

• SVALUE = Y — Utkast för flexitePortal är aktiverat.
• SVALUE = N — Utkast för flexitePortal är inaktiverat.
• Värde saknas — Utkast för flexitePortal är inaktiverat.

Modifiera konfiguration av utkast

Förändring av befintlig konfiguration av utkast för flexitePortal kan utföras med följande SQL-skript:

UPDATE PROCESS_SETTINGS
SET    SVALUE = '{Y/N}'
WHERE  REGISTRATION_ID = {YOUR_REGISTRATION_ID}
       AND SKEY = 'Portal.Visitor.Drafts';

• {Y/N} — Ange huruvida utkast för flexitePortal ska aktivera eller inaktiveras:
  • Y — Aktivera utkast för flexitePortal.
  • N — Inaktivera utkast för flexitePortal.
• {YOUR_REGISTRATION_ID} — Det unika ID:t för den process där utkast ska modifieras. Kan utläsas i kolumnen REGISTRATION_ID i tabellen REGISTRATION.

Verifiera i flexitePortal

1. Logga in i flexitePortal och öppna en E-service.
2. Fyll i ett par fält och stäng ner E-service.
3. Öppna samma E-service igen. Du ska nu kunna välja att fortsätta ditt föregående arbete från ett utkast.

Radering av utkast

Utkast för flexitePortal följer samma funktionalitet som automatiska utkast för ordinarie användare och behålls som standard tills dess att de kvitteras eller raderas av användaren. Det är även möjligt att aktivera automatisk radering av utkast efter angiven tid.

För mer information om hantering av utkast, se flexiteCLIENT Metodisk Manual.

flexite — Produktions- och Testdatabas

flexite stödjer att köras i antingen produktionsläge eller testläge. Vilket läge som ska nyttjas anges per databas, och appliceras således per flexite-installation.

Som standard opererar flexite i produktionsläget, vilket innebär full funktionalitet för samtliga tjänster (i enlighet med avtal).

Testläget innebär full funktionalitet för samtliga tjänster med begränsningen att e-post enbart skickas för utvalda registreringar till utvalda mottagare.

Konfiguration

Konfiguration av huruvida en flexite-installation ska befinna sig i produktions- eller testläge utförs i flexiteCLIENT under 'Inställningar > Webbinställningar > Länkar'. Notera att förändringar inte träder i kraft förrän ändringarna sparas.

• Produktionsdatabas — Systemet placeras i produktionsläge och fungerar utan funktionell begränsning. (Standard)
• Testdatabas — Systemet placeras i testläge där full funktionalitet erhålls, med begränsningen att e-post enbart skickas för utvalda registreringar och till utvalda mottagaradresser. Utgående e-post som inte är knuten till registreringar inaktiveras. En visuell indikator visas i flexiteWEB.
  • Skicka e-post enbart till dessa e-postadresser – Skicka enbart e-post där mottagaradressen matchar någon av de angivna e-postadresserna. Detta gäller enbart e-post knuten till registreringar, övrig e-post är inaktiverad. Multipla e-postadresser separeras med semikolon. För att en användare ska kunna ta emot e-post måste e-postadressen på användarkortet matcha en adress angiven i detta fält. Enbart tillgänglig med Testdatabas aktiv.
  • Utplåna all registreringsdata – Utplånar samtliga registreringar i databasen, inkluderat information knuten till registreringar, såsom ärende- och e-postloggar. Enbart tillgänglig med Testdatabas aktiv.

Växla från Produktionsdatabas till Testdatabas

När databas växlas från Produktionsdatabas till Testdatabas sker följande:

• All e-post som ligger i kö för att skickas utplånas.
• All utgående e-post som inte är knuten till registreringar inaktiveras.
• Med e-postadress angiven för 'Skicka e-post enbart till dessa e-postadresser' hanteras utgående e-post knuten till registreringar på följande vis:
  • För befintliga registreringar inaktiveras utgående e-post som standard. Det är möjligt att kontrollera utgående e-post för individuella registreringar i flexiteWEB med menyalternativet 'Operation > Inaktivera e-post'. Med detta val inaktiverat skickas e-post till mottagare som matchar angivna e-postadresser i 'Skicka e-post enbart till dessa e-postadresser'.
  • Nya registreringar skapade efter aktivering av Testdatabas anses vara testregistreringar, och för dessa skickas e-post till mottagare som matchar angivna e-postadresser i 'Skicka e-post enbart till dessa e-postadresser'.
• Om ingen e-postadress anges för 'Skicka e-post enbart till dessa e-postadresser' inaktiveras all utgående e-post från systemet.
• Åtkomst till 'Utplåna all registreringsdata' aktiveras.

Växla från Testdatabas till Produktionsdatabas

När databas växlas från Testdatabas till Produktionsdatabas sker följande:

• All e-post som ligger i kö för att skickas utplånas.
• Utgående e-post för samtliga registreringar och tjänster återaktiveras. De registreringar som registrerades när Testdatabas var aktiv hanteras nu som ordinarie registreringar.
• Åtkomst till 'Utplåna all registreringsdata' inaktiveras.

Rekommendationer

Det är kritiskt att nyttja unika URL för produktions- respektive testsystem för att säkerställa att exempelvis länkar i e-post och för E-services leder till korrekt system.

Det är starkt rekommenderat att nyttja separata installationer av flexiteCLIENT, flexiteProcessEngine samt flexiteWEB för produktions- respektive testsystem. Detta för att undvika konflikter med exempelvis integrationer.

flexiteWEB — Extern server

I det fall flexite behöver vara tillgängligt både internt och externt (publikt) är det rekommenderat att nyttja separata applikationsservrar för intern respektive extern åtkomst. Detta ger en ökad driftsäkerhet och möjliggör att i flexite skräddarsy vilka tjänster som ska finnas tillgängliga på den interna respektive externa servern.

Rekommendationer och krav

Ur ett säkerhetsperspektiv är det rekommenderat att belägga den externa applikationsservern med så hårda restriktioner som den tilltänkta användningen tillåter. Generellt sett bör samtliga systemtjänster och integrationer köras på interna servrar medan externa servrar bör köra minimalt med tjänster för att användarinteraktion och formulärfunktioner ska fungera.

Det är rekommenderat att enbart köra administrationsapplikationen flexiteAdmin på interna servrar.

För enkelhetens skull förutsätter vi i följande rekommendationer ett upplägg med en intern server och en extern server.

flexiteCLIENT

Det är rekommenderat att installera flexiteCLIENT enbart på den interna applikationsservern.

Konfiguration av vissa systemintegrationer kräver åtkomst till filer för integrationen, och bör därmed enbart utföras via flexiteCLIENT belägen på samma applikationsserver som integrationen i fråga. Det är starkt rekommenderat att köra kritiska systemintegrationer enbart på den interna applikationsservern.

Samtliga installationer av flexiteCLIENT kräver åtkomst till flexite databas samt konfigurerad SMTP-server.

Apache Tomcat och Microsoft IIS

Apache Tomcat måste installeras på både den interna och den externa applikationsservern. Det är rekommenderat att nyttja samma kommunikationsportar för samtliga installationer av Tomcat.

Det är starkt rekommenderat att installera och nyttja Microsoft IIS som webbserver på samtliga applikationsservrar.

flexiteProcessEngine

flexiteProcessEngine måste installeras på både den interna och den externa applikationsservern. Samtliga installationer av flexiteProcessEngine måste nyttja samma kommunikationsportar och samma sträng för databasanslutning (ConnectDatabaseName).

Det är starkt rekommenderat att förlägga samtliga systemtjänster och systemintegrationer till den interna servern och registrera denna som huvudserver för tjänsterna.

Samtliga installationer av flexiteProcessEngine kräver åtkomst till flexite databas samt konfigurerad SMTP-server.

Formulärintegrationer

Formulärintegrationer i form av DLL-filer för komponenten 'Extern Data' (belägna i katalogen ExtData som standard) synkroniseras till databasen från huvudservern för flexiteProcessEngine.

När dessa integrationer används på andra applikationsservrar anslutna till samma databas utförs en kontroll av lokala ExtData-filer kontra de som finns registrerade i databasen. Om de lokala filerna saknas eller skiljer sig från de i databasen laddas filerna ner från databasen.

Detta medför att konfiguration av ExtData-integrationer enbart kan utföras på huvudservern för flexiteProcessEngine.

URL för flexiteWEB Web Services

Ett par av flexiteProcessEngines tjänster har behov av åtkomst till flexiteWEB Web Services. Som standard beräknas den globala URL'en för flexiteWEB Web Service utifrån intern flexiteWEB URL, men de flesta tjänster har stöd för individuell konfiguration.

I en miljö med intern och extern server är det ur säkerhetssynpunkt starkt rekommenderat att minimera åtkomst från extern applikationsserver till intern applikationsserver.

För tjänster och integrationer som körs på en individuell server är det starkt rekommenderat att konfigurera dem att ansluta till flexiteWEB på den lokala servern.

För tjänster och integrationer som simultant körs på både intern och extern server, såsom ExtData, är det starkt rekommenderat att konfigurera dem att ansluta till flexiteWEB via localhost (127.0.0.1). Denna konfiguration resulterar i att samtliga flexiteProcessEngine ansluter till den lokala flexiteWEB på sin respektive server.

Tjänster med behov av åtkomst till flexiteWEB Web Services

I flexite har följande tjänster i flexiteProcessEngine behov av åtkomst till flexiteWEB Web Services:

• Alarm — Nyttjar ' flexiteWEB Webservice' URL från 'Webbinställningar' som standard. Har stöd för manuell konfiguration.
• DB-link — Nyttjar ' flexiteWEB Webservice' URL från 'Webbinställningar' som standard. Har stöd för manuell konfiguration.
• Systemintegrationer — Utförs av DB-link.
• Extern Data-integrationer på formulär — URL anges individuellt i konfigurationsfiler på disk som synkroniseras mellan samtliga flexiteProcessEngine. För integrationer som nyttjas i processer som är tillgängliga på både intern och extern server är det starkt rekommenderat att nyttja en URL baserad på localhost.

URL vid nyttjande av SSO via Microsoft IIS

I det fall systemet nyttjar Single Sign-On via Microsoft IIS måste anslutningar till flexiteWEB Web Services konfigureras mot en annan URL än flexiteWEB URL.

I detta fall finns två huvudsakliga lösningar:

• Anslut mot en parallell Website i Microsoft IIS, utan SSO, som pekar mot samma Apache Tomcat. Detta möjliggör stöd för krypterad https-trafik och är den rekommenderade lösningen för både intern och extern åtkomst.
• Anslut direkt mot Apache Tomcats lyssningsport; som standard '8080'. Denna lösning innebär som standard okrypterad http-trafik, och det är starkt rekommenderat att enbart nyttja den för kommunikation inom samma server.

flexiteWEB

flexiteWEB måste installeras på både den interna och den externa applikationsservern. Samtliga installationer av flexiteWEB måste nyttja samma kommunikationsportar.

Samtliga installationer av flexiteWEB kräver åtkomst till flexite databas samt konfigurerad SMTP-server.

Begränsningar

flexiteWEB på externa servrar tillåter enbart åtkomst via åtgärdslänkar i e-post samt publicerade resurser såsom e-services, bevakningar samt diagram.

Det är således inte möjligt att direkt logga in i flexiteWEB på en extern server.

Installation och konfiguration

Det är starkt rekommenderat att utföra den initiala installationen och konfigurationen på de interna servrarna i och med att det är dessa som ska husera systemtjänster och systemintegrationer.

I detta konfigurationsexempel utgår vi från en standardinstallation med IIS som webbserver i ett scenario med en intern och en extern server. Den interna servern nyttjas av interna användare med personliga konton i flexite för administration av ärenden. Den externa servern nyttjas av externa användare utan personliga konton i flexite för att registrera och ta del av information kring ärenden.

I vårt exempel har vi inget behov av systemintegrationer på den externa servern, varvid samtliga systemtjänster körs på den interna servern.

Intern server

• Datornamn — FLEXINT01
• IP — 192.168.0.10
• FQDN Web — flexite.company.com
• FQDN Web Service — int.company.com

Extern server

• Datornamn — FLEXEXT01
• FQDN — ext.company.com

Databasserver

• FQDN — sql.company.com
• Databas — flexite

Intern server

Installation

På den interna applikationsservern måste samtliga applikationer installeras:

• Microsoft IIS
• Apache Tomcat
• flexiteCLIENT
• flexiteProcessEngine
• flexiteWEB

Applikationerna installeras enligt standardförfarande, se kapitel Installation.

Konfiguration — Apache Tomcat

För Apache Tomcat finns inget behov av förändringar från en standardinstallation.

Konfiguration — flexiteProcessEngine

På vår interna applikationsserver, som ska köra samtliga tjänster, behöver vi inte göra några förändringar av flexiteProcessEngine från en standardinstallation. Säkerställ att samtliga tjänster är aktiva för den aktuella databasen så att applikationsservern registreras för dessa tjänster.

[Database.0]
ConnectServerType=SQLServerOLE
ConnectDatabaseName=sql.company.com:flexite
ConnectUserName=flexitedbuser
ConnectUserPassword=ABCDEFGH12345678
OnHoldSvc=1
AlarmSvc=1
StatisticsSvc=1
DBLinkSvc=1
LeadTimesSvc=1
SubstituteSvc=1
MailSvc=1

Konfiguration — flexiteWEB

För flexiteWEB finns inget behov av förändringar från en standardinstallation.

Installation — Microsoft IIS

Vårt behov av att kunna begränsa åtkomst till en IIS Website baserat på avsändarens IP-adress kräver att vi frångår standardförfarandet för installation av IIS, dokumenterat i avsnitt Microsoft IIS som webbserver.

1. Öppna 'Server Manager'.
2. Navigera till 'Manage > Add Roles and Features'.
3. Välj rollen 'Web Server (IIS)', och se till att följande roller är valda utöver standard:
   • Web Server > Common HTTP Features
     • HTTP Redirect
   • Web Server > Security
     • Basic Authentication
     • IP and Domain Restrictions
     • Windows Authentication
   • Web Server > Application Development
     • CGI
     • ISAPI Extensions
     • ISAPI Filters

Konfiguration — Microsoft IIS

För att möjliggöra individuell kontroll av åtkomst till flexiteWEB respektive flexiteWEB Web Services nyttjar vi på vår interna applikationsserver två parallella Websites i Microsoft IIS som båda integrerar med samma Apache Tomcat.

Dessa separata Websites öppnar även upp för att i framtiden införa autentisering via IIS för användare, utan att påverka befintlig konfiguration för flexiteWEB Web Services.

Den grundläggande installationen och konfigurationen av dessa två Websites följer båda standardförfarandet; se avsnitt Microsoft IIS som webbserver.

Website för användarbaserad åtkomst

Våra interna användare ska nå flexiteWEB via FQDN flexite.company.com. För användarbaserad åtkomst finns det i dagsläget inget behov av att införa några begränsningar avseende avsändar-IP.

Site Bindings

Website > Bindings...

Den Website som är avsedd för användarbaserad åtkomst ska enbart svara på anrop till FQDN flexite.company.com, och enbart via det krypterade protokollet https.

Vi börjar med att radera eventuella befintliga Site Bindings för denna Website. Därefter skapar vi en Site Binding av typen 'https', anger Host Name flexite.company.com och väljer ett matchande certifikat.

Fig.27: IIS. Site Bindings för Website för användarbaserad åtkomst.

Website för åtkomst till flexiteWEB Web Services

Åtkomst till flexiteWEB Web Services sker via FQDN int.company.com. I förberedande syfte vill vi begränsa åtkomst till denna Website till enbart utvalda avsändar-IP.

Application Pool

Website > Basic Settings...

I och med att vi ansluter två Websites till samma Apache Tomcat är det rekommenderat att även hanteringen av resurser i Microsoft IIS delas mellan dessa Websites. Detta uppnår vi genom att nyttja samma Application Pool för båda våra Websites.

Som standard skapas en individuell Application Pool för varje Website som skapas, med samma namn som Website. Det är möjligt att vid skapande av en Website välja att nyttja en befintlig Application Pool istället.

För befintliga Websites är det möjligt att via Edit Site ange vilken Application Pool som ska nyttjas.

Fig.28: IIS. Konfiguration av Application Pool i Edit Site.

Site Bindings

Website > Bindings...

Den Website som är avsedd för åtkomst till flexiteWEB Web Services ska enbart svara på anrop till FQDN int.company.com, och enbart via det krypterade protokollet https.

Vi börjar med att radera eventuella befintliga Site Bindings för denna Website. Därefter skapar vi en Site Binding av typen 'https', anger Host Name int.company.com och väljer ett matchande certifikat.

Fig.29: Site Bindings för webbapplikaiton för flexiteWEB Web Service.

IP Address and Domain Restrictions

Website > IP Address and Domain Restrictions

I förebyggande syfte vill vi begränsa åtkomst till den Website som ska nyttjas för flexiteWEB Web Services.

I dagsläget innebär detta ingen verklig begränsning i och med att flexiteWEB Web Services går att nå obegränsat via vår Website för användare. Men om vi i framtiden väljer att införa autentisering via IIS på den Website vi avsett för användare så säkerställer denna begränsning att det inte är möjligt för gemene användare att kringgå IIS autentisering genom att nyttja denna Website istället.

Vi vill begränsa åtkomsten till vår Website så att enbart trafik från explicit utvalda adresser tillåts. För att åstadkomma detta börjar vi med att konfigurera standardbeteendet under 'Edit Feature Settings...'. Där anger vi 'Access for unspecified clients' till 'Deny'.

Fig.30: Ange standardbeteende för ej specificerade adresser.

Därefter är det dags att ange vilka IP-adresser som ska tillåtas ansluta till vår Website med 'Add Allow Entry...'. I vårt fall har vi enbart behov av att tillåta trafik från vår huvudserver, vilket ger oss IP-adresserna 127.0.0.1 (localhost, för loopback) och 192.168.0.10.

Fig.31: IP-adresser som tillåts ansluta till vår Website.

Konfiguration — flexiteCLIENT

I en standardinstallation konfigureras flexite att nyttja en och samma applikationsserver för samtliga tjänster och integrationer. Det behöver således inte utföras några konfigurationsförändringar för att de ska fortsätta köras enbart på den interna servern.

Däremot krävs det ett par förändringar för att introducera den separata externa servern.

Webbinställningar

Inställningar > Webbinställningar

Under Webbinställningar i flexiteCLIENT anger vi URL och servernamn för intern respektive extern server samt vilka tjänster som ska vara direkt tillgängliga på den externa servern.

Fig.32: Exempel på konfiguration av intern och extern server under Webbinställningar.

Huvudsaklig/Intern server

Dessa utgör konfigurationen för vår interna server. I och med att samtliga systemtjänster körs på vår interna server

• flexiteWEB URL — https://flexite.company.com/flexite/. Detta är den URL som används som grund för att skapa länkar åt våra interna användare.
• flexiteWEB Webservice — https://int.company.com/flexite/services/. Detta är den URL som används som standard av flexiteProcessEngines tjänster för åtkomst till flexiteWEB Web Services.
• Interna servernamn — FLEXINT01 Detta är datornamnet på den server huserar vår interna applikationsserver.

Extern server

• Extern URL — https://ext.company.com/flexite/. Detta är den URL som används som grund för att skapa länkar i e-post åt våra externa användare.
• Tillåt åtkomst till
  • Länkar i e-post — Våra externa användare har behov av att kunna logga in och ta del av information kring ärenden i flexite via länkar i e-post.
  • E-service för registrering — Våra externa användare har behov av att kunna registrera ärenden i flexite.
• Externa servernamn — FLEXEXT01 Detta är datornamnet på den server huserar vår externa applikationsserver.

Övriga inställningar

Tillåt enbart åtkomst via angivna URL — Denna måste lämnas inaktiv för att möjliggöra åtkomst till e-service på extern server.

Processmotor

Inställningar > Processmotor

I och med att vi i enlighet med standardförfarande installerat och startat vår interna flexiteProcessEngine med samtliga tjänster aktiverade har vår interna applikationsserver registrerats för samtliga tjänster. Likaså har vi under 'Webbinställningar' angivit en URL för ' flexiteWEB Webservices' som kan nyttjas av samtliga tjänster.

Vi behöver således inte utföra många anpassningar av flexiteProcessEngine.

Alarm

I och med att Alarm körs på den interna applikationsservern kan vi nyttja den globala konfigurationen för flexiteWEB Web Services.

Fig.33: Konfiguration av Alarm.

DB-link

I och med att DB-link körs på den interna applikationsservern kan vi nyttja den globala konfigurationen för flexiteWEB Web Services.

Fig.34: Konfiguration av DB-link.

Statistik

Statistik körs på den interna applikationsservern och vi måste därmed ange sökväg och URL för den interna servern.

Fig.35: Konfiguration av Statistik.

Extern server

Installation

På den externa applikationsservern måste följande applikationer installeras:

• Microsoft IIS
• Apache Tomcat
• flexiteProcessEngine
• flexiteWEB

Det finns inget behov av att installera flexiteCLIENT på den externa applikationsservern i och med att vår externa server inte nyttjas för några tjänster som kräver direkt åtkomst från flexiteCLIENT.

Merparten av applikationerna installeras enligt standardförfarande, se kapitel Installation, med undantag för flexiteProcessEngine som kräver anpassning för att inaktivera samtliga systemtjänster.

Konfiguration — Apache Tomcat

För Apache Tomcat finns inget behov av förändringar från en standardinstallation. Det är starkt rekommenderat att nyttja samma kommunikationsportar som på den interna applikationsservern.

Konfiguration — flexiteProcessEngine

På vår externa applikationsserver, som inte ska köra någon systemtjänst, måste vi inaktivera samtliga tjänster för aktuell databas innan uppstart.

I och med att radering av loggar i databasen utförs av vår interna applikationsserver, och är beroende av tjänster som inaktiverats på denna externa server, så kan vi även inaktivera DeleteLogsChunkSize.

[Database.0]
ConnectServerType=SQLServerOLE
ConnectDatabaseName=sql.company.com:flexite
ConnectUserName=flexitedbuser
ConnectUserPassword=ABCDEFGH12345678
OnHoldSvc=0
AlarmSvc=0
StatisticsSvc=0
DBLinkSvc=0
LeadTimesSvc=0
SubstituteSvc=0
MailSvc=0
DeleteLogsChunkSize=disabled

Formulärintegrationer

Formulärintegrationer i form av Extern Data i kombination med ExtData-DLL'er synkroniseras till databasen av huvudservern för flexiteProcessEngine, vilket i vårt fall är den interna servern.

När integrationen nyttjas på vår externa server utförs en kontroll av lokala ExtData-filer kontra de som finns registrerade i databasen. Om de lokala filerna saknas eller skiljer sig från de i databasen laddas filerna ner från databasen.

Konfiguration — flexiteWEB

För flexiteWEB finns inget behov av förändringar från en standardinstallation.

Konfiguration — Microsoft IIS

På vår externa applikationsserver, som enbart ska nyttjas för användarbaserad åtkomst, har vi enbart behov av en Website. Den grundläggande installationen av denna Website följer standardförfarandet; se avsnitt Microsoft IIS som webbserver.

Site Bindings

Website > Bindings...

Vår Website på vår externa applikationsserver ska enbart svara på anrop till FQDN ext.company.com, och enbart via det krypterade protokollet https.

Vi börjar med att radera eventuella befintliga Site Bindings för denna Website. Därefter skapar vi en Site Binding av typen 'https', anger Host Name ext.company.com och väljer ett matchande certifikat.

Fig.36: Site Bindings för extern Website.

flexiteWEB — Kakhantering

I och med ändring i webbläsares hantering av kakor, med hänsyn till säkerhet, har det gjorts ändringar gällande användningen av tredje-parts kakor, exempelvis vid nyttjandet av IFrames. Denna ändring innebär att kakor som standard inte kan skapas om domänen för kakan i IFrame skiljer sig från domänen för huvudsidan.

SameSite=None

För att kakor ska kunna användas mellan olika domäner måste kakorna konfigureras med parametern SameSite=None. Detta kräver även att både sidan i IFrame och huvudsidan använder sig av protokollet HTTPS.

SameSite=Lax, SameSite=Strict

SameSite kan dessutom sättas till 'Lax' eller 'Strict'.

SameSite=Lax används på kakor som man enbart vill ska fungera om domänerna mellan sidorna överensstämmer med varandra. 'Lax' sätts som standard om SameSite inte är angiven på en kaka.

SameSite=Strict används på kakor som enbart skickas i ett förstapartssammanhang och skickas inte tillsammans med förfrågningar initierade av tredje parts webbplatser.

Publicera flexite inuti IFrame

Det är möjligt att publicera flexiteWEB E-services inuti en IFrame på en annan webbsida, vilket får som effekt att kakor för flexite skapas i tredjepartssammanhang. För att säkerställa att denna implementation fungerar i moderna webbläsare krävs det att följande kriterier uppfylls:

• Både flexite och huvudsidan måste använda protokollet HTTPS.
• Om flexite och huvudsidan inte befinner sig på samma domän (exempelvis flexite.company.com respektive www.external.com) måste kakorna för flexiteWEB konfigureras med SameSite=None.

För att möta ovan behov finns två alternativ på lösningar i flexiteWEB:

• Alternativ 1 — Samtliga kakor i flexiteWEB nyttjar SameSite=None.
• Alternativ 2 — Möjliggör att per länk ange huruvida kakor ska nyttja SameSite=None via URL-parametrar.

Alternativ 1 — Samtliga kakor

Konfigurera SameSite=None för samtliga kakor i flexiteWEB.

Konfigurera Apache Tomcat

1. Stoppa webbapplikationen för aktuell flexiteWEB.
2. Navigera till C:\tomcat\webapps\flexite\META-INF.
3. Döp om filen context.xml till exempelvis context_original.xml.bak.
4. Döp om filen context_iframe_domain_9.0.31.xml till context.xml.
5. Ta bort samtliga filer och kataloger i C:\tomcat\work\Catalina\localhost\flexite.
6. Starta upp webbapplikationen för aktuell flexiteWEB.

Alternativ 2 — URL-parameter

Konfigurera för möjligheten att använda URL-parameter för att ange vilka specifika länkar som ska nyttja SameSite=None.

Konfigurera Apache Tomcat

1. Stoppa webbapplikationen för aktuell flexiteWEB.
2. Navigera till C:\tomcat\webapps\flexite\META-INF.
3. Döp om filen context.xml till exempelvis context_original.xml.bak.
4. Döp om filen context_iframe_domain_9.0.35.xml till context.xml.
5. Ta bort samtliga filer och kataloger i C:\tomcat\work\Catalina\localhost\flexite.
6. Starta upp webbapplikationen för aktuell flexiteWEB.

Konfigurera länkar med URL-parameter

Individuella länkar kan nu konfigureras att nyttja SameSite=None via URL-parametern iframe_domain=1.

Exempel

Exempel på standardlänk till e-service:

https://flexite.company.com/flexite/service.jsp?s=ABCDEFGH12345678

Exempel på samma länk med URL-parametern iframe_domain=1:

https://flexite.company.com/flexite/service.jsp?s=ABCDEFGH12345678&iframe_domain=1

Kombination av alternativ 1 och 2

Konfiguration av SameSite anges individuellt för varje installation av Flexites webbapplikationer (flexiteFormAssist, flexitePages, flexiteWEB). Det är därför möjligt att kombinera alternativ ett och två mellan webbapplikationer på samma server.

flexiteWEB — REST API

flexite har stöd för att via ett REST API i flexiteWEB hantera registreringar utifrån anrop från externa system.

För information om REST API, vänligen kontakta Flexite AB.

Konfigurera tillgänglighet

flexiteCLIENT > Inställningar > Webbinställningar > REST API tillgänglighet

Åtkomst till flexite REST API sker via flexiteWEB. Som standard är all åtkomst blockerad, med möjligheten att öppna upp åtkomst från samtliga källor alternativt utvalda IP-adresser.

Tillgänglighet av REST API konfigureras i flexiteCLIENT och anges individuellt för intern respektive extern server.

Fig.37: Exempel där åtkomst till REST API på intern server tillåts från utvalda IP-adresser.

Intern server

Ange tillgänglighet av REST API på intern server.

• Blockera alla anrop – Blockera samtliga anrop till REST API på intern server. Aktiverad som standard.
• Tillåt alla anrop – Tillåt anrop till REST API på intern server från samtliga källor.
• Tillåt anrop enbart från angivna IP-adresser – Tillåt anrop till REST API på intern server enbart från angivna IP-adresser. Multipla IP-adresser separeras med semikolon.

Extern server

Ange tillgänglighet av REST API på extern server. Enbart tillgänglig med extern server aktiverad. Inställningarna fungerar på samma vis som för intern server.

flexiteWEB — Systeminställningar som kräver omstart

Vissa systeminställningar kräver omstart av flexiteWEB för att träda i kraft. Vid förändring av dessa inställningar ges möjligheten att starta om flexiteWEB direkt från flexiteCLIENT.

Inställningar som kräver omstart

Följande inställningar kräver omstart för att träda i kraft och ger användaren valmöjligheten att direkt starta om flexiteWEB:

• Inställningar > Tillgängliga språk
  • Förändring av inställningar för 'Tillgängliga språk'.
• Inställningar > Standard för meddelanden > Webbinställningar
  • Förändring av Meddelanden i fliken 'All information'.
  • Förändring av Meddelandevy i fliken 'All information'.
  • Förändring av inställningar för 'Liten förhandsgranskning'.
  • Förändring av inställningar för 'Nytt meddelande'.
• Inställningar > Webbinställningar > Länkar
  • Förändring av inställningar för 'Huvudsaklig/Intern server'.
  • Förändring av inställningar för 'Extern server'.
  • Växla mellan 'Produktionsdatabas' och 'Testdatabas'.
  • Förändring av inställning 'Stäng webbläsaren vid utloggning och inaktivera lösenordspåminnelse'.
  • Förändring av inställning 'Tillåt enbart åtkomst via angivna URL'.
• Inställningar > Webbinställningar > Första formulär
  • Förändring av inställning 'Visa pop-up fönster med "Att-göra lista" efter inloggning'.
• Inställningar > Webbinställningar > Trafikljus
  • Förändring av inställningar för Trafikjus.
• Inställningar > Webbinställningar > Gränssnitt
  • Förändring av inställningar för 'Tabellvy i Mitt ansvar'.
  • Förändring av inställningar för 'Placering för navigator för Nästa/Föregående'.
  • Förändring av inställningar för 'Dölj flexite logga'.
  • Förändring av inställningar för 'Visa nollor som standard'.
  • Förändring av inställningar för 'Statistiktabeller'.
• Inställningar > Systeminformation
  • Förändring av 'Licensierad till organisation', 'Licensansvarig namn', 'Licensansvarig e-post' samt 'E-postmottagare för tekniska systemmeddelanden'.
• Inställningar > Processmotor > flexiteProcessEngine
  • Förändring av 'IP address'.
  • Förändring av inställningar för 'Extern data'.
• Inställningar > Processmotor > Mail
  • Förändring av 'Inställningar för e-postserver'.

Starta om flexiteWEB från flexiteCLIENT

Vissa systeminställningar kräver omstart av flexiteWEB för att träda i kraft. Vid förändring av någon av dessa inställningar presenteras en möjlighet att starta om flexiteWEB direkt från flexiteCLIENT.

Omstarten av flexiteWEB initieras genom att flexiteCLIENT skickar ett anrop till de adresser som är angivna för ' flexiteWEB URL' respektive 'Extern URL' (Inställningar > Webbinställningar > Länkar).

Vid denna omstart initierad av flexiteCLIENT avslutas samtliga aktiva sessioner i aktuell instans av flexiteWEB, på både intern och extern server, vilket betyder att alla användare kommer att loggas ut och eventuellt arbete som inte sparats kommer att gå förlorat.

Fig.38: Dialogruta för att tvinga omstart av flexiteWEB.

Hantering vid lastbalansering

I system som nyttjar lastbalansering, exempelvis i form av proxy för flexiteWEB och/eller multipla flexiteProcessEngine, kommer detta anrop inte nödvändigtvis att anlända till samtliga flexiteWEB. I dessa fall är det kritiskt att samtliga flexiteWEB startas om manuellt för att säkerställa problemfri drift.

Loggning — Radering och export

Systemloggar för flexite lagras i databasen och går att läsa i flexiteCLIENT under 'System > Loggar'. Loggar för arbete med registreringar går även att läsa för de individuella registreringarna i flexiteWEB. För information om applikationerna flexiteCLIENT och flexiteWEB, se manualerna ' flexiteCLIENT Metodisk Manual' respektive ' flexiteWEB Manual'.

Loggar för flexiteProcessEngine lagras på disk.

Dessa loggar lagras som standard för evigt med möjlighet att per loggtyp ange hur länge de ska behållas.

Det är även möjligt att per loggtyp ange huruvida de ska exporteras till textfiler samt hur länge de exporterade loggarna ska behållas.

Loggtyper

• ProcessEngine och DLL loggar — flexiteProcessEngine, flexites systemtjänster samt standard-DLL och systemspecifika integrationer skriver loggar direkt till disk.
• Användarsessioner och säkerhetshändelser — Loggar användares in- och utloggning i flexiteCLIENT samt flexiteWEB samt säkerhetsaktioner kopplade till användarkonton. Ålder på sessioner räknas från tidpunkt för inloggning. Detta kan i extrema fall resultera i att loggposten för en pågående session raderas om den aktuella sessionen är aktiv längre än angivet antal dagar för 'Radera loggar efter … dagar'. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Åtkomstloggar > Användarsessioner'. 'System > Loggar > Åtkomstloggar > Säkerhet'.
• Registreringar — Loggar aktiviteter som sker i och med en registrering i flexiteWEB. Dessa loggar raderas aldrig. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Händelseloggar > Arbete'. Loggar för individuella registreringar kan även läsas i detaljvyn för den aktuella registreringen i flexiteWEB.
• Sökningar — Loggar sökningar utförda i flexiteWEB. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Händelseloggar > Sökningar'.
• Ändringar i rättighetsgrupper — Loggar förändringar i rättigheter för grupper. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Konfigurationsloggar > Ändringar i rättighetsgrupper'.
• Förändringar i process och organisation — Loggar ändringar gjorda i processer samt ändringar gjorda i organisationen som påverkar processen. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Konfigurationsloggar > Förändringar i process och organisation'.
• Gallring — Loggar ändringar av gallringsinställningar per attribut. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Konfigurationsloggar > Gallringsförändringar'.
• flexiteDB-link användar- och objektimport — Loggar för integrationsuppgifter av typerna Användarimport och Objektimport. Loggar för dessa integrationsuppgifter nås via länk i e-post till loggmottagare, angiven på respektive uppgift. Loggar för exekvering av flexiteDB-Link uppgifter lagras av flexiteProcessEngine på disk och hanteras av konfiguration för 'ProcessEngine och DLL loggar'.
• Förändringar av användarkonton — Loggar förändringar av användarkonton och ändringar i grupptillhörighet. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Konfigurationsloggar > Förändringar av användarkonton'.
• E-postmeddelanden — Loggar för utgående e-post. Loggar kan läsas i flexiteCLIENT under: 'System > Loggar > Händelseloggar > E-postmeddelanden'. Loggar för e-posttjänsten (MailSvc) lagras av flexiteProcessEngine på disk och hanteras av konfiguration för 'ProcessEngine och DLL loggar'.
• System — Loggar för systemförändringar och systemtekniska fel. Loggar kan läsas i flexiteCLIENT under: 'System / Loggar / Händelseloggar / System'. 'System / Loggar / Konfigurationsloggar / Systemförändringar'.

Radering och lagringstid för loggar i databas

Loggar i databasen lagras som standard för evigt. I flexiteCLIENT är det möjligt att per loggtyp ange hur många dagar som dessa loggar ska lagras innan de raderas. Konfiguration av loggning utförs under 'Inställningar > Loggning och automatisk utplåning > Konfigurera loggning'.

• Radera loggar efter ... dagar — Radera loggar i databasen som är äldre än angivet antal dagar.

Avancerad konfiguration

Radering av loggposter i databasen utförs löpande utav den flexiteProcessEngine som kör tjänsten 'MailSvc' alternativt 'OnHoldSvc'. Denna radering utförs i sjok (så kallade "chunks") med en paus mellan sjoken. Detta för att minimera tiden som databastabellerna låses av operationen, och därmed hindrar andra operationer från att skriva till dem.

Som standard är antalet loggposter i en chunk 10.000, med 5 sekunders paus mellan chunks.

Anpassa Chunk Size

Radering av loggposter utförs som standard per loggtyp i så kallade chunks med en paus mellan dessa chunks. Standardkonfigurationen av antalet loggposter i en chunk (10.000) samt tiden mellan chunks (5 sekunder) är framtagen för att nå en bra balans mellan låg tidsåtgång för löpande radering och minimal påverkan på normal drift. Hantering av en chunk med 10.000 loggposter slutförs i normala fall inom cirka 1 till 2 sekunder, men denna tidsåtgång kan variera beroende på prestanda på databasservern.

Medan operationen för att radera loggar körs låses databastabellerna för dessa loggar, vilket betyder att det inte är möjligt att skriva nya poster till dessa tabeller under denna tid. Skrivning av nya poster kommer att köas och köras när operationen för radering av aktuell chunk är slutförd.

Storleken på dessa chunks och tiden mellan chunks styrs av parametern DeleteLogsChunkSize i konfigurationsfilen för flexiteProcessEngine (flexiteProcessEngine.ini). Om parametern saknas används standardvärdet om 10.000 loggposter i en chunk och 5 sekunders paus mellan chunks.

Parameter i flexiteProcessEngine.ini:

[Database.0]
DeleteLogsChunkSize=

Värden för DeleteLogsChunkSize

Värde	Beskrivning
{chunkSize},{timeBetweenChunks}	Exempel: DeleteLogsChunkSize=10000,5 {chunkSize} = Antal loggposter som ska raderas i en och samma chunk. I varje chunk hanteras enbart loggposter från en och samma databastabell. Standardvärde: 10000 {timeBetweenChunks} = Tid i sekunder mellan radering av chunks. Under denna tid kan andra operationer startas och skriva till de tabeller i databasen som annars låses av loggraderingen. Värdet '0' innebär att loggposterna raderas i chunks, men att pausen mellan chunks är minimal. Det är därmed rekommenderat att enbart nyttja detta värde vid den initiala aktiveringen av loggradering i det fall det finns en stor mängd loggposter att radera. Standardvärde: 5
disable	Inaktivera radering av loggar på aktuell flexiteProcessEngine.
max	Radera samtliga loggar i ett svep utan att dela upp dem i chunks. Notera att detta kan resultera i att de tabeller i databasen som låses av loggraderingen inte kan skrivas till under lång tid, beroende på antal loggposter. Det är därmed rekommenderat att enbart nyttja detta värde vid den initiala aktiveringen av loggradering i det fall det finns en stor mängd loggposter att radera.

Funktionalitet vid avsaknad av eller inkorrekt värde

Om parametern DeleteLogsChunkSize saknas fullständigt i filen flexiteProcessEngine.ini används standardvärdet om 10.000 loggposter i en chunk och 5 sekunders paus mellan chunks.

Om parametern existerar i filen men saknar värde likställs detta med värdet disable, vilket medför att radering av loggar inaktiveras på aktuell flexiteProcessEngine.

Om parametern existerar i filen men har ett inkorrekt värde som inte matchar ovan beskrivna format likställs detta med värdet disable, vilket medför att radering av loggar inaktiveras på aktuell flexiteProcessEngine.

Rekommendation vid initial aktivering i befintligt system

I det fall radering av loggar aktiveras i ett befintligt system som körts under längre tid och därmed innehåller stora mängder loggar kan det vara en god idé att avsätta tid för den initiala loggraderingen och antingen minimera pausen mellan chunks (exempelvis DeleteLogsChunkSize=10000,0) eller radera samtliga loggposter i ett svep utan att dela upp dem i chunks (DeleteLogsChunkSize=max).

Minimera paus mellan chunks

Fördelen med att minimera pausen mellan chunks är att varje chunk hanteras som en separat transaktion. Om problem skulle uppstå med databasservern är det därmed enbart den senaste transaktionen (chunk) som behöver rullas tillbaka, och inte tidigare slutförda chunks. Detta resulterar i mindre förlorat arbete.

Nackdelen med att hantera loggposterna i chunks är att det tar längre tid, även med minimerad paus mellan chunks.

Radera samtliga loggposter i ett svep

Fördelen med att radera samtliga loggposter i ett svep är att det är den mest tidseffektiva lösningen, i och med att alla poster hanteras i en, oavbruten, transaktion.

Nackdelen med att radera samtliga loggposter i ett svep är att om problem skulle uppstå med databasservern måste hela transaktionen rullas tillbaka. Detta betyder att när raderingen återupptas så måste den börja om från början.

Funktionalitet med multipla flexiteProcessEngine

I system där multipla flexiteProcessEngine arbetar mot samma databas är det enbart en flexiteProcessEngine som sköter loggradering. Vilken flexiteProcessEngine det är beräknas med följande formel:

• Om E-posttjänsten (MailSvc) är AKTIVERAD i systemet (flexiteCLIENT > Inställningar > Processmotor > Mail):
  • Den flexiteProcessEngine som är registrerad att hantera 'MailSvc' hanterar loggradering.
• Om E-posttjänsten är INAKTIVERAD i systemet:
  • Den flexiteProcessEngine som är registrerad att hantera OnHold-tjänsten (OnHoldSvc) hanterar loggradering. Det är tekniskt möjligt att inaktivera även 'OnHoldSvc', men det är högst osannolikt i produktionssystem eftersom denna tjänst bland annat hanterar ärendeflöden.

Loggning av radering

Loggar för radering av loggar skrivs löpande till databasen och sammanfattas en gång per dag i flexiteProcessEngines loggfil; flexiteProcessEngine.log.

Vid uppstart av flexiteProcessEngine skrivs aktuell konfiguration av loggradering till loggfilen. Förändringar av värdet för parametern DeleteLogsChunkSize loggas löpande till loggfilen.

Loggning av konfiguration vid uppstart

Vid uppstart av flexiteProcessEngine loggas aktuell konfiguration av DeleteLogsChunkSize. Om DeleteLogsChunkSize INTE är satt till disable följs detta av aktuell global konfiguration av radering av loggar.

Exempel med radering aktiverat globalt och i flexiteProcessEngine

I detta exempel är radering av loggar äldre än 366 dagar aktiverat för användarsessioner (User Sessions) samt ändringar i rättighetsgrupper (Authorization Group Changes).

2022-12-01 01:00:00 [dbServer:dbName] Initial log deletion chunk size: "10000,5"
2022-12-01 01:00:00 [dbServer:dbName] Deletion of logs for "User Sessions" enabled (Delete logs after 366 days)
2022-12-01 01:00:00 [dbServer:dbName] Deletion from log "Instance Search" disabled in flexiteCLIENT. See Settings > Logging and Automatic Erasure
2022-12-01 01:00:00 [dbServer:dbName] Deletion of logs for "Authorization Group Changes" enabled (Delete logs after 366 days)
2022-12-01 01:00:00 [dbServer:dbName] Deletion from log "Process Changes" disabled in flexiteCLIENT. See Settings > Logging and Automatic Erasure
2022-12-01 01:00:00 [dbServer:dbName] Deletion from log "Replace Data Task Changes" disabled in flexiteCLIENT. See Settings > Logging and Automatic Erasure
2022-12-01 01:00:00 [dbServer:dbName] Deletion from log "flexiteDB-link user import" disabled in flexiteCLIENT. See Settings > Logging and Automatic Erasure
2022-12-01 01:00:00 [dbServer:dbName] Deletion from log "User Account Changes" disabled in flexiteCLIENT. See Settings > Logging and Automatic Erasure
2022-12-01 01:00:00 [dbServer:dbName] Deletion from log "Manual Log Export" disabled in flexiteCLIENT. See Settings > Logging and Automatic Erasure

Exempel med radering inaktiverat i flexiteProcessEngine

I detta exempel är radering av loggar inaktiverat i aktuell flexiteProcessEngine genom att sätta DeleteLogsChunkSize till disable.

2022-12-01 01:00:00 [dbServer:dbName] Initial log deletion chunk size: "disable"

Exempel med tjänsterna för e-post och OnHold inaktiverade i flexiteProcessEngine

I detta exempel är radering av loggar aktiverat samtidigt som tjänsterna för både e-post (MailSvc) och OnHold (OnHoldSvc) är aktiva i systemet men inaktiverade på aktuell flexiteProcessEngine.

2022-12-01 01:00:00 [dbServer:dbName] Initial log deletion chunk size: "10000,5"
2022-12-01 01:00:00 [dbServer:dbName] Log deletion cannot be started. Service MailSvc is not allowed to run on this host.

Loggning vid förändring av 'DeleteLogsChunkSize'

Vid förändring av konfiguration för DeleteLogsChunkSize loggas föregående och aktuellt värde. I detta exempel har DeleteLogsChunkSize ändrats från 10000,5 till disable. I och med att förändringen görs i en textfil på disk loggar inte flexite vem som utfört förändringen.

2022-12-01 01:00:00 [dbServer:dbName] Chunk size specification for log deletion changed from "10000,5" to "disable"

Loggning för radering av loggar

Radering av loggar loggas löpande till databasen. I början av varje dygn skrivs en sammanställning av de loggar som raderats under föregående dygn till flexiteProcessEngines loggfil flexiteProcessEngine.log. Informationen som loggas är loggtyp, antal loggposter, antal chunks samt total tidsåtgång.

2023-04-01 00:30:45 [dbServer:dbName] During 2023-03-31 following deleting was done:
User Sessions: deleted   9600 records in   2 chunks; total time:  2,600 seconds.
Instance Search: deleted   8200 records in   3 chunks; total time:  8,800 seconds.
Authorization Group Changes: deleted  21000 records in   3 chunks; total time:  9,000 seconds.
Replace Data Task Changes: deleted    200 records in   1 chunks; total time: 10,500 seconds.
flexiteDB-link user import: deleted   6700 records in   1 chunks; total time:  7,100 seconds.
User Account Changes: deleted   3100 records in   1 chunks; total time:  5,300 seconds.
Manual Log Export: deleted   5000 records in   2 chunks; total time:  3,600 seconds.

Export och lagringstid för loggar på disk

Loggar som lagras i databasen kan per loggtyp exporteras i klartext till disk. Det är även möjligt att ange hur många dagar som dessa exporterade loggar ska lagras. Konfiguration av export av loggar utförs i två steg, i flexiteCLIENT och i flexiteProcessEngine.

Aktivera export av loggar i flexiteCLIENT

Export av individuella loggar aktiveras globalt för systemet i flexiteCLIENT under 'Inställningar > Loggning och automatisk utplåning > Konfigurera loggning'. Det är även här lagringstid för exporterade loggar anges.

• Exportera loggar till textfiler — Exportera loggar i klartext till fil belägen i en underkatalog till flexiteProcessEngine (som standard AppLogs). De exporterade loggarna uppdateras varje minut. Varje natt tas det backup på dessa textfiler och lagras i samma katalog.
• Radera textfiler efter ... dagar — Radera backup av exporterade textfiler som är äldre än angivet antal dagar.

Aktivera export av loggar i flexiteProcessEngine

Export av individuella loggar aktiveras och konfigureras per flexiteProcessEngine i konfigurationsfilen flexiteProcessEngine.ini.

Parametrar i flexiteProcessEngine.ini:

[Database.0]
UsersSessionsLogs=AppLogs\UsersSessions
ExportUsersSessionsLog=1
AuthorizationChangesLogs=AppLogs\AuthorizationChanges
ExportAuthorizationChangesLog=1
SearchesLogs=AppLogs\Searches
ExportSearchesLog=1
InstancesLogs=AppLogs\Instances
ExportInstancesLog=1
ProcessChangesLogs=AppLogs\ProcessChanges
ExportProcessChangesLog=1
ReplaceDataTaskChangesLogs=AppLogs\ReplaceDataTaskChanges
ExportReplaceDataLog=1
ImportUsersLogs=AppLogs\ImportUsers
ExportImpUsersLog=1
UserAccountChangesLogs=AppLogs\UserAccountChanges
ExportUserAccountChanges=1
ManualExportLogs=AppLogs\ManualExport
ExportManualExport=1
Emails=AppLogs\Emails
ExportEmailsLog=1

Parameter	Beskrivning / Värde
ExportUsersSessionsLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för användarsessioner till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
UsersSessionsLogs	Relativ sökväg för exporterade loggar för användarsessioner. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\UsersSessions
ExportAuthorizationChangesLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för ändringar i rättighetsgrupper till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
AuthorizationChangesLogs	Relativ sökväg för exporterade loggar för ändringar i rättighetsgrupper. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\AuthorizationChanges
ExportSearchesLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för sökningar till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
SearchesLogs	Relativ sökväg för exporterade loggar för sökningar. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\Searches
ExportInstancesLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för registreringar till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
InstancesLogs	Relativ sökväg för exporterade loggar för registreringar. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\Instances
ExportProcessChangesLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för förändringar i process och organisation till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
ProcessChangesLogs	Relativ sökväg för exporterade loggar för förändringar i process och organisation. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\ProcessChanges
ExportReplaceDataLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för gallring till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
ReplaceDataTaskChangesLogs	Relativ sökväg för exporterade loggar för gallring. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\ReplaceDataTaskChanges
ExportImpUsersLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för flexiteDB-link användar- och objektimport till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
ImportUsersLogs	Relativ sökväg för exporterade loggar för flexiteDB-link användar- och objektimport. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\ImportUsers
ExportUserAccountChanges	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för förändringar av användarkonton till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
UserAccountChangesLogs	Relativ sökväg för exporterade loggar för förändringar av användarkonton. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\UserAccountChanges
ExportManualExport	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för manuell logg-export till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
ManualExportLogs	Relativ sökväg för exporterade loggar för manuell logg-export. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\ManualExport
ExportEmailsLog	Anger om aktuell flexiteProcessEngine ska kunna exportera loggar för e-postmeddelanden till fil, i enlighet med konfiguration i flexiteCLIENT. 0 = Inaktivera export. (standard om värde saknas) 1 = Aktivera export.
Emails	Relativ sökväg för exporterade loggar för e-postmeddelanden. Installationskatalogen för flexiteProcessEngine används som rot. Standard om värde saknas: AppLogs\Emails

Microsoft IIS som webbserver

Det är möjligt att köra flexites programvaror fullt ut på webbservern Apache Tomcat, men för utökad funktionalitet i Windows-miljöer kan Tomcat integreras med Microsoft Internet Information Services (IIS).

Med denna lösning nyttjas Microsoft IIS som webbserver och Apache Tomcat som Java container.

En integration mellan IIS och Tomcat har följande krav:

• Installation av Apache Tomcat. Detta är beskrivet i avsnitt Installera Apache Tomcat.
• Installation av Tomcat ISAPI Redirector. Denna används för integrationen mellan Tomcat och IIS och beskrivs i detta kapitel.
• Installation av Microsoft IIS. Detta beskrivs i detta kapitel.

För information om Apache Tomcat ISAPI Redirector, se Apaches dokumentation:

https://tomcat.apache.org/connectors-doc/webserver\_howto/iis.html

För information om administration av Microsoft IIS med IIS Manager, se Microsofts dokumentation:

https://learn.microsoft.com/en-us/iis/get-started/getting-started-with-iis/getting-started-with-the-iis-manager-in-iis-7-and-iis-8

Installation av Microsoft IIS

I det fall Microsoft IIS inte är installerat på servern måste rollen 'Web Server (IIS)' läggas till. Därtill måste stöd för 'CGI' och 'ISAPI' installeras. Denna installation utförs i applikationen 'Server Manager'.

1. Navigera till 'Manage > Add Roles and Features'.
2. Välj rollen 'Web Server (IIS)', och se till att följande roller är valda utöver standard:
   • Web Server > Common HTTP Features:
     • HTTP Redirect
   • Web Server > Security:
     • Basic Authentication
     • Windows Authentication
   • Web Server > Application Development:
     • CGI
     • ISAPI Extensions
     • ISAPI Filters

Konfiguration av Tomcat

För integrera Apache Tomcat med Microsoft IIS krävs det att Jakarta ISAPI Redirector registreras med sökvägen för Tomcat. Därtill måste det säkerställas att samtliga av flexites webbapplikationer finns konfigurerade i ISAPIs uriworkermap.properties.

1. Öppna Windows Services och stoppa tjänsten för Apache Tomcat.

2. Säkerställ att korrekt sökväg för Tomcat är angiven i installationsskriptet för ISAPI; C:\tomcat\bin\isapi\isapi.reg.
   Om standardsökväg inte används måste samtliga instanser av C:\\tomcat ersättas med den aktuella sökvägen. Notera kravet på dubbla backslash (\\).

3. Registrera 'Jakarta ISAPI Redirector' i systemet genom att köra installationsskriptet; C:\tomcat\bin\isapi\isapi.reg.

4. Säkerställ att webbapplikationerna flexiteWEB och flexiteAdmin finns angivna och är kopplade till korrekt Worker i C:\tomcat\conf\uriworkermap.properties. Som standard används Worker ajp13.

   /{webappName}/*=ajp13
   /{webappName}/servlet/*=ajp13

   Exempel med katalog ' flexite' respektive ' flexiteAdmin':

   /flexite/*=ajp13
   /flexite/servlet/*=ajp13
   /flexiteAdmin/*=ajp13
   /flexiteAdmin/servlet/*=ajp13

Konfiguration av Microsoft IIS

I Microsoft IIS behöver vi avsätta en Site för flexite samt konfigurera integrationen med Tomcat ISAPI.

1. Starta 'Internet Information Services (IIS) Manager'.
2. Konfigurera integrationen med Tomcat ISAPI genom att navigera till roten av webbservern (servernamnet), öppna 'ISAPI and CGI Restrictions' och lägga till en begränsning:
   • ISAPI or CGI path — C:\tomcat\bin\isapi\isapi_redirect.dll
   • Description — jakarta
   • Allow extension path to execute — Aktiverad
3. Lägg till en 'Site' för flexite om ingen existerar och öppna densamma. I detta kapitel benämner vi den 'Default Web Site'.
   • Konfigurera integration med Tomcat ISAPI genom att öppna 'ISAPI Filter' och lägga till ett ISAPI-filter:
     • Name — jakarta
     • Executable — C:\tomcat\bin\isapi\isapi_redirect.dll
   • Öppna 'Handler Mapping', välj 'ISAPI-dll', och välj 'Edit Feature Permissions...'.
     Aktivera samtliga behörigheter.
   • Högerklicka på 'Default Web Site' och välj 'Add Virtual Directory...':
     • Alias — jakarta
     • Physical path — C:\tomcat\bin\isapi
   • Konfigurera IIS att nyttja flexites errorsidor genom att öppna 'Error Pages' och där öppna 'Edit Feature Settings':
     • Error Responses — Detailed errors

Rekommendationer

Begränsa domännamn som IIS svarar på

Det är möjligt att kontakta och få svar från en Windows-server via flera adresser; angivet datornamn, angivna IP-adresser samt domännamn (FQDN) kopplade till dessa IP-adresser.

Som standard svarar en Site i IIS på samtliga anrop som inkommer till TCP port 80 (http), oavsett adress. För ökad kontroll av åtkomst är det rekommenderat att ange de specifika domännamn som vår Site ska svara på.

Notera att angivna domännamnet måste stämma överens med de domännamn som är angivna för flexiteWEB i flexiteCLIENT (se avsnitt Konfigurera sökvägar för flexite).

Fig.39: IIS. Standardkonfiguration av Site Bindings.

1. Starta 'Internet Information Services (IIS) Manager'.
2. Navigera till 'Sites' och markera 'Default Web Site'.
3. Öppna 'Bindings...', konfigurationsgränssnittet för vilka protokoll och portar som denna web site svarar på.
   • Markera befintlig binding för typen http och väj 'Edit...'.
     • Host name — Ange det domännamn (FQDN) som aktuell binding ska svara på.

Fig.40: IIS. Exempel på konfiguration av FQDN för standard Site Binding för http.

Stöd för multipla domännamn

I de fall behov finns av att nå samma IIS Site via multipla domännamn uppnås detta genom att skapa en unik Binding för varje unik FQDN.

HTTPS med IIS

I flexiteWEB skickas information såsom inloggningsuppgifter och formulärdata i okrypterat format mellan webbläsare och webbserver. För publika servrar är det därför kritiskt att nyttja det krypterade protokollet HTTPS istället för det okrypterade HTTP. För interna servrar, i skyddade miljöer, är det inte lika kritiskt, men fortfarande en rekommendation.

Som standard tillåter en IIS Site enbart kommunikation via det okrypterade protokollet HTTP. Notera att byte från HTTP till HTTPS kräver konfiguration av globala länkar i flexiteCLIENT. Se avsnitt Konfigurera sökvägar för flexite.

Notera att protokollet HTTPS kräver att ett matchande certifikat är installerat i Windows Certificate Store för 'Local Computer', under 'Personal' eller 'Web Hosting'. Detta certifikat måste i sin tur vara utfärdat av en Certificate Authority som är betrodd av samtliga klienter som ska ansluta till flexiteWEB.

Fig.41: IIS. Standardkonfiguration av Site Bindings.

1. Starta 'Internet Information Services (IIS) Manager'.
2. Navigera till 'Sites' och markera 'Default Web Site'.
3. Öppna 'Bindings...', konfigurationsgränssnittet för vilka protokoll och portar som denna Site svarar på.
   • Lägg till en ny binding med 'Add...':
     • Type — https
     • IP Address — Den IP-adress som aktuell binding ska svara på. Valfritt.
       Om ingen IP-adress anges ('All Unassigned') svarar aktuell binding på anrop till angiven port oavsett adress.
     • Port — Den port som aktuell binding ska svara på. Standard är 443 för protokollet https. Valfritt.
       Val av annan port än standard kräver att specifik port anges i globala länkar i flexiteCLIENT.
     • Host name — Domännamn (FQDN) som aktuell binding ska svara på. Måste matcha angivet SSL-certifikat. Valfritt.
       Om inget FQDN anges svarar aktuell binding på samtliga anrop till angiven IP och port, oavsett domännamn.
     • Require Server Name Indication — Av kompatibilitetsskäl är det starkt rekommenderat att lämna denna inaktiverad.
     • SSL certificate — Välj befintligt, installerat certifikat som matchar Host name.

Fig.42: IIS. Exempel på konfiguration av Site Binding för https.

Stöd för multipla domännamn och certifikat

I de fall behov finns av att nå samma IIS Site via multipla domännamn uppnås detta genom att skapa en unik Binding för varje unik FQDN.

Med 'Require Server Name Indication' inaktiverat binds angivna certifikat till varje unik kombination av IP-adress och port. Detta gäller globalt i IIS och påverkar därmed samtliga Sites.

I de fall det finns behov av att nyttja multipla certifikat krävs det således att även IP-adress eller port ändras för att på så vis skapa en ny unik kombination att binda certifikatet till.

Ta reda på aktuella certifikatkopplingar

Det är möjligt att få en överblick av samtliga aktuella certifikatkopplingar i IIS med CMD-kommandot netsh http show sslcert. Detta kan vara hjälpsamt för att exempelvis ta reda på vilka IP-adresser och portar som är kopplade till vilka certifikat.

Scenario

I detta exempel har vi en IIS Site med tre Site Bindings:

• http://flexite.company.com (standardport 80)
• https://flexite.company.com (standardport 443) Nyttjar unikt certifikat.
• https://int.company.com:4443 (port 4443) Nyttjar unikt certifikat.

Fig.43: IIS Website med tre Site Bindings.

Resultat

CMD-kommandot ger oss följande information:

PS C:\> netsh http show sslcert
SSL Certificate bindings:
-------------------------
    IP:port                      : 0.0.0.0:443
    Certificate Hash             : abcdefgh12345678
    Application ID               : {a1b2c3d4e5f6g7h8}
    Certificate Store Name       : WebHosting
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled
    Reject Connections           : Disabled
    Disable HTTP2                : Not Set
    IP:port                      : 0.0.0.0:4443
    Certificate Hash             : abcdefgh87654321
    Application ID               : {a1b2c3d4e5f6g7h8}
    Certificate Store Name       : WebHosting
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled
    Reject Connections           : Disabled
    Disable HTTP2                : Not Set

Från detta resultat kan vi utläsa följande:

• För kombinationen IP 0.0.0.0 (motsvarar 'All Unassigned') och port 443 nyttjas certifikatet med hash abcdefgh12345678.
• För kombinationen IP 0.0.0.0 (motsvarar 'All Unassigned') och port 4443 nyttjas certifikatet med hash abcdefgh87654321.

Dedikerad Application Pool för flexite

Hantering av systemresurser för IIS Sites sköts av 'Application Pools'. En Application Pool kan innehålla multipla IIS Sites.

Det är starkt rekommenderat att den IIS Site som används för flexite nyttjar en dedikerad Application Pool.

I det fall den IIS som nyttjas för flexite inte huserar några andra Sites behöver inga förändringar göras; standard Application Pool ('DefaultAppPool') kommer då enbart nyttjas av flexite.

I det fall ISS innehåller multipla Sites för andra applikationer än flexite är det starkt rekommenderat att skapa en Application Pool specifikt för flexite.

Skapa Application Pool

En Application Pool skapas på följande vis:

1. I IIS Manager, navigera till 'Application Pools'.
2. Lägg till en ny Application Pool med 'Add Application Pool...':
   • Name — Ange valfritt namn.
   • .NET CLR version — No Managed Code
   • Managed pipeline mode — Integrated
   • Start application pool immediately — AKTIV

Fig.44: IIS. Skapa Application Pool.

Koppla Site till Application Pool

Koppla flexite IIS Site till en Application Pool på följande vis:

1. I IIS Manager, öppna 'Basic Settings...' för den Site som används för flexite. Aktuell Application Pool kan utläsas under 'Application pool'.
2. Öppna dialogruta för att välja Application Pool med 'Select...' och välj önskad Pool.

Fig.45: IIS. Exempel på inställningar för Site 'Default Web Site' där Application Pool ' flexite' nyttjas.

Multipla Sites för flexite

I det fall multipla IIS Sites används för flexite är det starkt rekommenderat att nyttja samma Application Pool för samtliga Sites, för att på så vis förenkla administration av resurstilldelning.

Ett exempel på behov av detta beskrivs i avsnitt Separat Website för flexiteWEB Web Services och API vid nyttjande av SSO via Microsoft IIS.

Anpassa antal anslutningar och trådar

Maximalt antal samtidigt aktiva anslutningar som kan hanteras styrs delvis utav hur många trådar som maximalt tillåts allokeras. Hantering av anslutningar och trådar skiljer sig mellan Microsoft IIS och Apache Tomcat, men en tumregel är att en tråd kan hantera en anslutning.

För få allokerade trådar kan leda till att inkommande anslutningar köas eller till och med blockeras, och leda till långa svarstider.

För många allokerade trådar kan uppta för mycket maskinresurser och leda till långa svarstider eller till med systemlåsningar.

Grundläggande upplägg

Vid integration med Microsoft IIS är det tre separata nivåer som individuellt anger maximalt antal tillgängliga trådar för respektive nivå:

• Microsoft IIS
• ISAPI Redirect DLL
• Apache Tomcat

Nivå / Applikation	Location	Parameter	Typ av värde
Microsoft IIS	Avancerade inställningar för 'Application Pool'	Maximum Worker Processes	Antal Worker Processes. Varje Worker Process innehåller ett antal trådar.
ISAPI Redirect DLL	Konfigurationsfilen 'workers.properties'	{worker}.connection_pool_size	Antal trådar.
Apache Tomcat	Konfigurationsfilen 'server.xml'.	ISAPI AJP connector; maxThreads	Antal trådar.

Standardvärden

I en standardkonfiguration har de individuella nivåerna följande värden:

• Microsoft IIS — 1 Worker Process.
• ISAPI Redirect DLL — 250 trådar.
• Apache Tomcat — 250 trådar.

Uppskatta antal anslutningar

Vid installation av flexite i en ny miljö, där vi ännu inte har underlag för faktisk belastning, behöver en uppskattning utföras för att konfigurera de initiala värdena. Denna uppskattning baseras på förväntat antal samtidigt anslutna flexite-användare.

flexite kan använda sig av 2 till 3 anslutningar per öppen webbläsarflik, beroende på användaraktivitet, varav en anslutning alltid nyttjas för kontroll av åtkomst. En bra grundregel är att utgå från 5 anslutningar per användare.

Exempelvärden

I våra konfigurationsexempel utgår vi från 100 samtidiga användare, vilket ger oss 500 anslutningar och trådar.

Utred antal anslutningar och trådar

Medan en uppskattning ofta krävs för den initiala konfigurationen behövs en regelrätt utredning för att optimera antal trådar baserat på den faktiska användningen.

På den server som huserar Microsoft IIS och flexite, använd Windows 'Performance Monitor' för att övervaka användning av trådar och status för anslutningar för webbapplikationen under ett par normala arbetsdagar. I 'Performance Monitor' används följande 'Counters':

• W3SVC_W3WP > Maximum Threads Count > Instance: flexite Application Pool Worker Process — Visar maximalt antal tillgängliga trådar för varje individuell vald Worker Process. Worker Processes identifieras med dess unika ID följt av namnet på den Application Pool den tillhör. Exempel; '12345_ flexite'.
• W3SVC_W3WP > Active Threads Count > Instance: flexite Application Pool Worker Process — Visar antal aktiva trådar för varje individuell vald Worker Process. Worker Processes identifieras med dess unika ID följt av namnet på den Application Pool den tillhör. Exempel; '12345_ flexite'.
• HTTP Service Request Queues > CurrentQueueSize > Instance: flexite Application Pool — Visar antal HTTP Requests som är köade för vald Application Pool. Om detta värde överstiger noll betyder det generellt att antal trådar behöver ökas. Notera att samtliga av dessa köade anslutningar inte nödvändigtvis kommer att avvisas, men de kommer troligtvis att uppleva fördröjningar.
• HTTP Service Request Queues > RejectedRequests > Instance: flexite Application Pool — Visar antal HTTP Requests som avvisats för vald Application Pool. Sannolikt, men inte nödvändigtvis, på grund av full kö.

Bra att veta

Observera att övervakning av Worker Process enbart gäller för den unika processen. Vid omstart av tjänsten skapas som standard en ny unik process, varvid den befintliga övervakningen blir förlegad.

Valet '_Total' övervakar hela Application Pool och överlever omstarter, men kan inte ge information om individuella Worker Processes.

Logga övervakning till fil

Som standard visar Performance Monitor övervakningar i realtid, men det är möjligt att istället skriva informationen till fil:

1. Med alla Counters på plats, markera 'Performance Monitor' och välj 'Action > New > Data Collector Set'.
2. Ange valfritt namn.
3. Ange valfri sökväg för var loggfilen ska sparas.
4. På sista steget, välj 'Start this data collector set now' för att starta loggningen omedelbart.
5. Skapad Data Collector Set återfinns under 'Data Collector Sets > User Defined'.

Som standard skrivs all data till samma fil, men det är möjligt att skräddarsy filformat i egenskaperna för loggfilen ('Data Collector Sets > User Defined > {Collector Name} > {File Name}').

Läs loggfil för övervakning

Loggfilen för Data Collector Set går att avläsa i Performance Monitor:

1. Invänta att nödvändig information är loggad.
2. Stoppa Data Collector Set ('Data Collector Sets > User Defined'). Det är inte möjligt att läsa loggfiler som för tillfället används av Data Collector Set.
3. Läs rapporten under 'Reports > User Defined > {Collector Name}'.

Konfigurera IIS Worker Processes

I Microsoft IIS används en Application Pool för att hantera anslutningar till vår Site för flexite, som i sin tur vidarebefordrar dessa anslutningar via ISAPI till Apache Tomcat. Denna Application Pool använder sig av ett antal Worker Processes för att hantera trådar för dessa anslutningar.

Observera att antalet Worker Processes enbart dikterar hur många samtidiga anslutningar som kan hanteras, inte hur många anslutningar som tillåts. Anslutningar som för tillfället inte kan hanteras köas och hanteras vid ett senare tillfälle inom Timeout-perioden. För konfiguration av maximalt antal anslutningar, se avsnitt Konfigurera antal anslutningar för IIS Site.

Obs!

Det är kritiskt att den Application Pool som används för flexite inte nyttjas för andra applikationer. Detta för att säkerställa att samtliga anslutningar till aktuell Pool enbart är för flexite.

Fastställ maximalt antal trådar per Worker Process

En Worker Process innehåller en uppsättning trådar. Antalet trådar per process kan variera mellan system och det är därmed kritiskt att fastställa antalet trådar per process för det aktuella systemet innan konfiguration kan påbörjas.

I Windows 'Performance Monitor' går det att avläsa maximalt antal trådar per Worker Process:

• W3SVC_W3WP > Maximum Threads Count > Instance: flexite Application Pool Worker Process — Visar maximalt antal tillgängliga trådar för varje individuell vald Worker Process. Worker Processes identifieras med dess unika ID följt av namnet på den Application Pool den tillhör. Exempel; '12345_ flexite'.

Observera att maximalt antal trådar för en Worker Process allokeras dynamiskt baserat på belastning. I det fall en Application Pool tilldelats många Worker Processes kan därmed maximalt antal trådar variera.

För att säkerställa en korrekt avläsning av maximalt antal trådar för en Worker Process är det starkt rekommenderat att först konfigurera aktuell Application Pool att nyttja 1 Worker Process.

Beräkna antal Worker Processes

Med både behov av antal trådar samt antal trådar per Worker Process fastställda kan vi beräkna hur många Worker Processes vår Application Pool behöver:

{behov antal trådar} / {antal trådar per Worker Process} = Antal Worker Processes Resultatet avrundas uppåt till närmaste heltal.

Multiplicera antalet Worker Processes med antalet trådar per Worker Process för att få fram det faktiska maximala antalet trådar. Detta antal kommer att användas för konfiguration av maximalt antal anslutningar för vår IIS Site samt trådar för ISAPI och Apache Tomcat.

Exempel

I vårt exempel har vi 100 samtidiga användare, vilket ger oss 500 trådar, och för oss är maximalt antal trådar per Worker Process 256. Detta ger oss följande uträkning:

500 (behov trådar) / 256 (trådar per process) = 1,953 Worker Processes Avrundat ger detta oss 2 Worker Processes.

Med denna information kan vi nu även räkna ut hur många trådar vi totalt har att röra oss med; 256 trådar per process och 2 Worker Processes ger oss följande antal trådar:

256 (trådar per process) * 2 (Worker Processes) = 512 trådar

512 är det värde som kommer att nyttjas vid konfiguration av maximalt antal anslutningar för vår IIS Site samt trådar för ISAPI och Apache Tomcat.

Konfigurera Application Pool

Med antal Worker Processes beräknat kan vi nu konfigurera vår Application Pool:

1. I IIS Manager, öppna 'Advanced Settings...' för den Application Pool som används av flexite.
2. Ange beräknat antal processer för inställningen 'Process Model > Maximum Worker Processes'.

Exempel

I vårt exempel räknade vi ut att 2 Worker Processes behövs för 100 samtidiga användare. Detta ger följande konfiguration:

Maximum Worker Processes = 2

Anpassa antal trådar vid uppstart

Som standard startas 4 trådar vid uppstart av en Application Pool om antalet Worker Processes är 4 eller lägre. I det fall antalet Worker Processes är 5 eller högre startas en tråd per process.

Nya trådar startas utefter behov varje halvsekund. Det är möjligt att anpassa antal trådar vid uppstart med följande registernyckel:

HKLM\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolStartupThreadCount (REG_DWORD)

Konfigurera antal anslutningar för IIS Site

Med Worker Processes har vi angivit hur mycket systemresurser som ska kunna nyttjas för att hantera anslutningar till vår IIS Application Pool. Anslutningar som på grund av belastning inte kan hanteras av våra Worker Processes köas och hanteras vid ett senare tillfälle inom Timeout-perioden. Anslutningar som inte hinner hanteras inom Timeout avslås.

Maximalt antal tillåtna anslutningar anges per IIS Site. Som standard är detta värde obegränsat (tekniskt '4294967295'). Det är rekommenderat att konfigurera detta värde till det beräknade maximala totala antalet trådar:

1. I IIS Manager, öppna 'Limits...' för den IIS Site som används för flexite.
2. Aktivera 'Connection Limits > Limit number of connections' och ange beräknat totalt antal trådar.

Exempel

I vårt exempel räknade vi ut att 2 Worker Processes behövs för 100 samtidiga användare, vilket på vår server resulterade i totalt 512 trådar. Detta ger oss följande konfiguration:

Connection Limits > Limit number of connections = 512

Stöd för multipla IIS Sites

I det fall samma Application Pool används för multipla IIS Sites för flexite måste det totala antalet trådar fördelas mellan dessa Sites baserat på arbetsbelastning.

Ett exempel på behov av detta beskrivs i avsnitt Separat Website för flexiteWEB Web Services och API vid nyttjande av SSO via Microsoft IIS.

Konfigurera ISAPI

Med antalet Worker Processes beräknat har vi även räknat ut det maximala antalet trådar som kan användas i ISAPI och Apache Tomcat.

För ISAPI används antal trådar för att ange 'Connection Pool Size' för ISAPI Workers:

1. Öppna konfigurationsfilen för ISAPI Workers; C:\tomcat\conf\workers.properties.
2. För parametern worker.ajp13.connection_pool_size, ange beräknat totalt antal trådar. Standard: worker.ajp13.connection_pool_size=250

Exempel

I vårt exempel räknade vi ut att 2 Worker Processes behövs för 100 samtidiga användare, vilket på vår server resulterade i totalt 512 trådar. Detta ger oss följande konfiguration:

worker.ajp13.connection_pool_size=512

Stöd för multipla Workers

I det fall ISAPI är konfigurerad att nyttja multipla Workers måste det totala antalet trådar fördelas mellan dessa Workers baserat på arbetsbelastning.

Konfigurera Apache Tomcat

Antalet trådar för Tomcat Connector måste matcha Connection Pool Size för den specifika ISAPI Worker som anropar denna Connector:

1. Öppna konfigurationsfilen för Apache Tomcat Connectors; C:\tomcat\conf\server.xml.
2. Lokalisera den AJP Connector som anropas av ISAPI. Som standard är det den som svarar på port '8009'.
3. För parametern maxThreads, ange beräknat totalt antal trådar. Standard: maxThreads="250"

Exempel

I vårt exempel räknade vi ut att 2 Worker Processes behövs för 100 samtidiga användare, vilket på vår server resulterade i totalt 512 trådar. Detta ger oss följande konfiguration:

maxThreads="512"

Stöd för multipla Workers

I det fall ISAPI är konfigurerad att nyttja multipla Workers måste antalet trådar för varje AJP Connector matcha Connection Pool Size för den ISAPI Worker som anropar denna Connector.

Utökad funktionalitet

Separat Website för flexiteWEB Web Services och API vid nyttjande av SSO via Microsoft IIS

flexiteProcessEngine och flexiteWEB stödjer inte autentisering med Single Sign-On vid anrop av flexiteWEB Web Services Detsamma gäller för flexitePortal vid anrop till flexiteWEB API.

När systemet nyttjar Single Sign-On via Microsoft IIS måste flexites anslutningar till flexiteWEB Web Services och flexiteWEB API därmed konfigureras mot en annan URL, som inte nyttjar SSO.

I detta fall finns två huvudsakliga lösningar:

• Anslut mot en parallell Site i Microsoft IIS, utan SSO, som pekar mot samma Apache Tomcat.
  Detta möjliggör stöd för krypterad https-trafik och är den rekommenderade lösningen.
• Anslut direkt mot Apache Tomcats lyssningsport; som standard '8080'.
  Denna lösning innebär som standard okrypterad http-trafik, och det är starkt rekommenderat att enbart nyttja den i undantagsfall och då enbart för kommunikation inom samma server ('localhost').

Tjänster med behov av åtkomst till flexiteWEB Web Services

I flexite har följande tjänster i flexiteProcessEngine behov av åtkomst till flexiteWEB Web Services:

• Alarm — Nyttjar ' flexiteWEB Webservice' URL från 'Webbinställningar' som standard. Har stöd för manuell konfiguration.
• DB-link — Nyttjar ' flexiteWEB Webservice' URL från 'Webbinställningar' som standard. Har stöd för manuell konfiguration.
• Systemintegrationer — Utförs av flexiteDB-link.
• Extern Data-integrationer på formulär — URL anges individuellt i konfigurationsfiler på disk som synkroniseras mellan samtliga flexiteProcessEngine. För integrationer som nyttjas i processer som är tillgängliga på både intern och extern server är det starkt rekommenderat att nyttja en URL baserad på localhost.

Tjänster med behov av åtkomst till flexiteWEB API

I flexite har följande tjänster och applikationer behov av åtkomst till flexiteWEB API:

• Systemintegrationer — Några integrationslösningar nyttjar flexiteWEB API. URL anges individuellt i konfigurationsfiler på disk.
• Extern Data-integrationer på formulär — Några integrationslösningar nyttjar flexiteWEB API. URL anges individuellt i konfigurationsfiler på disk som synkroniseras mellan samtliga flexiteProcessEngine. För integrationer som nyttjas i processer som är tillgängliga på både intern och extern server är det starkt rekommenderat att nyttja en URL baserad på localhost.
• flexitePortal — En separat webbapplikation som nyttjar flexiteWEB API för all kommunikation med flexite. URL anges manuellt i konfigurationsfil.

Konfiguration

För exempel på konfiguration av parallella IIS Sites med koppling mot samma Apache Tomcat, se avsnitt Konfiguration — Microsoft IIS.

Blockera åtkomst baserat på klients IP-adress

I vissa fall kan det finnas behov av att kunna begränsa åtkomst till en IIS Site, och i utsträckning flexiteWEB, till enbart utvalda klienter eller servrar. Alternativt blockera åtkomst från utvalda klienter eller servrar.

Ett exempel på en sådan situation är vid nyttjande två IIS Sites; en för användarbaserad åtkomst som kräver autentisering via SSO och en för åtkomst till flexiteWEB Web Services som inte nyttjar SSO.

I detta fall kan det finnas behov av att kunna blockera gemene användare från att kringgå autentisering via SSO genom att istället ansluta till flexiteWEB via den Website som avsetts för åtkomst till Web Services.

För att tillgodose detta behov kan vi använda oss av en funktion i Microsoft IIS vid namn 'IP Address and Domain Restrictions'.

Installation

För att kunna nyttja funktionen 'IP Address and Domain Restrictions' måste rollen 'IP and Domain Restrictions' vara installerad för IIS.

1. Öppna 'Server Manager'.
2. Navigera till 'Manage' > 'Add Roles and Features'.
3. Expandera rollen 'Web Server (IIS)', och se till att följande roll är vald:
   • Web Server > Security:
     • IP and Domain Restrictions

Konfiguration

I vårt exempel har vi två IIS Sites; en för användarbaserad åtkomst och en för åtkomst till flexiteWEB Web Services. Vi vill att enbart utvalda enheter ska kunna komma åt vår Site för Web Services.

1. I IIS Manager, navigera till den Site för vilken åtkomst önskas begränsas.
2. Öppna 'IP Address and Domain Restrictions'.
3. Välj 'Edit Feature Settings...'. Här anges standardbeteendet för de adresser som inte matchar någon skapad regel.
   • Access for unspecified clients — Deny
     Detta val innebär att all trafik som inte explicit tillåts blockeras.
4. Välj 'Add Allow Entry...'. Här anges de specifika adresser från vilka trafik ska tillåtas.
   Det är möjligt att per regel ange en enskild IP-adress eller ett spann med IP-adresser.
   • Specific IP address — Ange enskild IP-adress från vilken trafik ska tillåtas.

Fig.46: Standardbeteende för ej specificerade adresser satt till 'Deny'.

Fig.47: Specifika regler för åtkomst till vår Website.

I exemplet ovan har vi angivit att åtkomst ska tillåtas från adresserna 127.0.0.1 (localhost, för loopback) samt 192.168.0.10.

Maximal storlek på filuppladdning

När Microsoft IIS används som webbserver kan det uppstå situationer där uppladdning av stora filer till flexiteWEB misslyckas. Detta avser både användarinteraktioner och integrationer som nyttjar flexiteWEB för att skriva information till flexite.

Orsaken till detta är att Microsoft IIS som standard har en begränsning på maximal mängd innehåll i en HTTP Request. I IIS version 10 är denna begränsning som standard satt till 30.000.000 Bytes (cirka 28,6 MB).

Även Apache Tomcat har stöd för denna typ av begränsning. I det installationspaket som tillhandahålles av Flexite AB är detta inte konfigurerat vilket betyder att Tomcat inte applicerar någon begränsning.

Fig.48: Exempel på felmeddelande som visas i flexiteWEB vid uppladdning av fil som överstiger IIS maximala storlek.

Konfigurera maximal storlek på HTTP Request

Konfiguration av Microsoft IIS sker i 'Internet Information Services (IIS) Manager' på applikationsservern. Det är möjligt att konfigurera denna begränsning globalt för samtliga Sites i IIS eller individuellt per Site. I detta exempel konfigurerar vi begränsningen på en individuell Site.

1. Starta 'Internet Information Services (IIS) Manager'.
2. Navigera till den Site som nyttjas av flexite och öppna 'Request Filtering'.
3. Under 'Actions', välj 'Edit Feature Settings'.
   • Maximum allowed content length (Bytes) — Ange maximal storlek på HTTP Request i Bytes. Standardvärde är '30000000'.

Förändringen appliceras omedelbart, utan behov av omstart av tjänster.

Fig.49: Microsoft IIS. Inställningar för Request Filtering.

Single Sign-On — SAML

SAML står för Security Assertion Markup Language och är en XML-baserad öppen standard för att utbyta autentisering och behörigheter mellan en Identity Provider och en eller flera Service Providers.

flexiteWEB och flexiteAdmin

Med SAML är det möjligt för flexite-användare att logga in i flexiteWEB och flexiteAdmin (som agerar Service Providers) med en identitet som inte har någon direkt anknytning till systemet, där identiteten istället autentiseras mot en extern källa (Identity Provider). Denna externa identitet har en koppling till ett användarkonto i flexite, oftast via en integration med ett extern användarregister, och det är med detta kopplade användarkonto som inloggning i flexite sker.

Detta möjliggör exempelvis att logga in automatiskt i flexiteWEB och flexiteAdmin med samma användarkonto som används för att logga in på datorn.

flexitePortal

flexitePortal är en webbapplikation där användare utan personligt flexite-konto, såsom exempelvis medborgare, kan logga in och hantera sina personliga ärenden i flexite.

Autentisering av dessa användare kan antingen genomföras med SAML eller med E-ID (E-ID för identifiering och signering).

För nya användare skapas en unik Identitet i flexite vid inloggning, och det är till denna Identitet som ärenden kommer att kopplas.

För återvändande användare sker inloggning med den Identitet som tidigare skapats i flexite.

Tillvägagångssätt

Konfiguration och aktivering av Single Sign-On via SAML i flexites webbapplikationer utförs i följande grundläggande steg:

1. Hämta metadata från Identity Provider.
2. Stoppa webbapplikationer.
3. Installera certifikat i webbapplikationer.
4. Konfigurera SAML i webbapplikationer.
5. Registrera webbapplikationer hos Identity Provider.
6. Aktivera inloggning med SAML i webbapplikationer.
7. Starta webbapplikationer.

Hämta metadata från Identity Provider

Metadata-filen från Identity Provider innehåller kritisk information om hur Service Provider ska kommunicera med Identity Provider.

Denna fil tillhandahålles av den Identity Provider som ska nyttjas och är i formatet XML. Som standard används samma metadata-fil för samtliga webbapplikationer.

I denna guide benämner vi denna fil 'saml_idp.xml'.

Stoppa webbapplikationer och ta backup

• Stoppa berörda webbapplikationer.
• Ta backup på eventuella befintliga keystores genom att döpa om dem eller flytta dem till annan plats.
  • I flexiteWEB har keystore följande sökväg som standard: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
  • I flexiteAdmin har keystore följande sökväg som standard: C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks
  • I flexitePortal har keystore följande sökväg som standard: C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks

Installera certifikat i webbapplikationer

För att säkerställa riktighet och konfidentialitet i kommunikationen mellan flexite och Identity Provider är det starkt rekommenderat att nyttja certifikat för att signera och kryptera informationen. Det rekommenderade förfarandet är att utfärda dessa certifikat på en betrodd Certificate Authority, men det är även möjligt att generera självsignerade certifikat lokalt i Apache Tomcat.

Certifikaten installeras i en individuell Java Keystore per applikation, som standard saml.jks. I och med att denna keystore enbart används för SAML är det rekommenderat att skapa en ny keystore för nya certifikat istället för att lägga till fler certifikat till befintlig keystore.

Det är rekommenderat att använda unika certifikat för de individuella applikationerna.

Installera certifikat i flexiteWEB

Importera certifikat från betrodd Certificate Authority

I detta exempel importerar vi ett certifikat tillsammans med privat nyckel i formatet PKCS#12 utfärdat utav en betrodd Certificate Authority med hjälp av Java Development Kit som levereras i katalogen för Apache Tomcat.

1. Öppna en kommandotolk och navigera till C:\tomcat\jdk\bin.

2. Importera de två certifikat med tillhörande privata nycklar som krävs för signering respektive kryptering. För certifikat i formatet PKCS#12 ser kommandot för att importera ett certifikat ut på följande vis:

   keytool.exe -importkeystore -srckeystore "C:\cert\exported_certificate.pfx" -srcstoretype pkcs12 -srcstorepass exported_password -destkeystore "C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks" -deststoretype jks -deststorepass keystore_password

   Detta kommando importerar ett certifikat med följande egenskaper:

   • importkeystore — Kommando för att importera certifikat från befintlig keystore. En certifikatfil av typen PKCS#12 kan innehålla multipla certifikat och är därmed att betrakta som en egen keystore.
   • srckeystore {sökväg} — Fullständig sökväg till certifikat som ska importeras. I detta exempel: C:\cert\exported_certificate.pfx
   • srcstoretype {typ} — Typ av keystore som certifikat ska importeras från. I detta fall är typen 'pkcs12'.
   • srcstorepass {lösenord} — Lösenord i klartext för certifikat som ska importeras. I detta exempel: exported_password
   • destkeystore {sökväg} — Fullständig sökväg till keystore-fil som certifikat ska importeras till. Om filen existerar uppdateras befintlig keystore, annars skapas en ny. I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • deststorepass {lösenord} — Lösenord i klartext för keystore. Om ny keystore skapas, ange lösenord i enlighet med policy. Om det rör sig om befintlig keystore, ange lösenordet för aktuell keystore. I detta exempel: keystore_password
   • deststoretype {typ} — Typ av keystore för den keystore-fil som certifikat ska importeras till. I detta fall är typen ' jks'.

3. Verifiera innehåll genom att visa detaljerad information om samtliga certifikat i aktuell keystore med följande kommando:

   keytool.exe -list -v -keystore C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten. I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore. I detta exempel: keystore_password

Stöd för andra format

För information om import av andra certifikat-format och parametrar gällande JDK keytool, se Oracles dokumentation:

https://docs.oracle.com/en/java/javase/17/docs/specs/man/keytool.html

Generera självsignerade certifikat

I detta exempel genererar vi självsignerade certifikat lokalt på applikationsservern med hjälp av Java Development Kit som levereras i katalogen för Apache Tomcat. För generering av certifikat används verktyget 'keytool' beläget i C:\tomcat\jdk\bin.

1. Öppna en kommandotolk och navigera till C:\tomcat\jdk\bin.

2. Generera certifikat för signering med följande kommando:

   keytool.exe -genkey -alias sign_certificate -keyalg RSA -keypass sign_password -keystore "C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks" -storetype jks -storepass keystore_password -validity 365 -keysize 2048

   • genkey — Kommando för att generera självsignerat certifikat och private key.
   • alias {namn} — Namn på certifikat. Ange valfritt namn.
     I detta exempel: sign_certificate
   • keyalg {algoritm} — Algoritm för private key. För denna typ av certifikat ska algoritmen vara 'RSA'.
   • keypass {lösenord} — Lösenord i klartext för certifikat. Anges i enlighet med policy.
     I detta exempel: sign_password
   • keystore {sökväg} — Fullständig sökväg till keystore-fil, inklusive filnamn. Om filen existerar uppdateras befintlig keystore, annars skapas en ny. Ange valfritt filnamn.
     I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • storetype {typ} — Typ av keystore. I detta fall är typen ' jks'.
   • storepass {lösenord} — Lösenord i klartext för keystore. Om ny keystore skapas, ange lösenord i enlighet med policy. Om det rör sig om befintlig keystore, ange lösenordet för aktuell keystore.
     I detta exempel: keystore_password
   • validity {dagar} — Giltighetstid för certifikat i dagar. Anges i enlighet med policy. Det är rekommenderat att sätta denna till 365 dagar.
     I detta exempel: 365
   • keysize {bits} — Storlek på private key i bits. För denna typ av certifikat ska storleken vara '2048'.
     När certifikatet genereras efterfrågas information för att ange utfärdare och ägare. Common Name (CN) är obligatorisk.
     • What is your first and last name? — FQDN för applikationsserver (CN).
       Exempel: flexite.company.com
     • What is the name of your organizational unit? — Namn på avdelning (OU).
       Exempel: Administration
     • What is the name of your organization? — Namn på organisation (O).
       Exempel: Flexite AB
     • What is the name of your City or Locality? — Namn på stad för organisation (L).
       Exempel: Örnsköldsvik
     • What is the name of your State or Province? — Namn på stat eller provins (ST).
       Exempel: Ångermanland
     • What is the two-letter country code for this unit? — Landskod (C).
       Exempel, för Sverige: SE

3. Generera certifikat för kryptering med följande kommando:

   keytool.exe -genkey -alias encrypt_certificate -keyalg RSA -keypass encrypt_password -keystore "C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks" -storetype jks -storepass keystore_password -validity 365 -keysize 2048

   • genkey — Kommando för att generera självsignerat certifikat och private key.
   • alias {namn} — Namn på certifikat. Ange valfritt namn.
     I detta exempel: encrypt_certificate
   • keyalg {algoritm} — Algoritm för private key. För certifikat av denna typ ska algoritmen vara 'RSA'.
   • keypass {lösenord} — Lösenord i klartext för certifikat. Anges i enlighet med policy.
     I detta exempel: encrypt_password
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikat för signering.
     I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • storetype {typ} — Typ av keystore. I detta fall är typen ' jks'.
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password
   • validity {dagar} — Giltighetstid för certifikat i dagar. Anges i enlighet med policy. Det är rekommenderat att sätta denna till 365 dagar.
     I detta exempel: 365
   • keysize {bits} — Storlek på private key i bits. För denna typ av certifikat ska storleken vara '2048'.
     Precis som för certifikat för signering efterfrågas information för att ange utfärdare och ägare.

4. Verifiera innehåll genom att visa detaljerad information om samtliga certifikat i aktuell keystore med följande kommando:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

Installera certifikat i flexiteAdmin

Certifikat importeras och genereras på samma vis för flexiteAdmin som för flexiteWEB, men med skillnaden att certifikaten sparas till Java keystore i flexiteAdmin.

Sökvägen för Java keystore i flexiteAdmin är som följer i en standardinstallation:

C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks

För information om att importera certifikat, se avsnitt Importera certifikat från betrodd Certificate Authority.

För information om att generera självsignerade certifikat, se avsnitt Generera självsignerade certifikat.

Installera certifikat i flexitePortal

Certifikat importeras och genereras på samma vis för flexitePortal som för flexiteWEB, men med skillnaden att certifikaten sparas till Java keystore i flexitePortal.

Sökvägen för Java keystore i flexitePortal är som följer i en standardinstallation:

C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks

För information om att importera certifikat, se avsnitt Importera certifikat från betrodd Certificate Authority.

För information om att generera självsignerade certifikat, se avsnitt Generera självsignerade certifikat.

Konfigurera SAML i webbapplikationer

Konfigurera SAML i webbapplikationerna med uppgifterna från aktuell Identity Provider:

Konfigurera SAML i flexiteWEB

Konfigurera SAML i flexiteAdmin

Konfigurera SAML i flexitePortal

Konfigurera SAML i flexiteWEB

Identity Provider metadata

Placera metadata-filen från Identity Provider i följande katalog i flexiteWEB:

C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml

Konfiguration

Konfigurera SAML i flexiteWEB med uppgifter om Identity Provider och certifikat. Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.conf

idp_metadata_file=/integration/saml/saml_idp.xml
idp_entity_id=https://idp.company.com:9443/
idp_user_attibute_name=urn:oid:2.4.8.128
fx_user_field_name=username
keystore_file=/integration/saml/saml.jks
keystore_password=keystore_password
sign_request=1
sign_cert_name=sign_certificate
sign_cert_password=sign_password
sign_assertion=1
encrypt_assertion=1
encrypt_cert_name=encrypt_certificate
encrypt_cert_password=encrypt_password

Identity Provider

• idp_metadata_file — Relativ sökväg till den metadata-fil som hämtats från Identity Provider. Använder katalogen ..\flexite\WEB-INF\classes som rot.
  I detta exempel: /integration/saml/saml_idp.xml
• idp_entity_id — ID för server som agerar Identity Provider.
  I detta exempel: https://idp.company.com:9443/
• idp_user_attribute_name — Det attribut hos Identity Provider som innehåller användar-id.
  I detta exempel: urn:oid:2.4.8.128
• fx_user_field_name — Det attribut i flexite som användar-id från Identity Provider ska verifieras mot. Möjliga alternativ:
  • username — Användarnamn angivet på användarkortet i flexite.
  • unique-id — Unik sträng angiven på användarkortet i flexite.

Certifikat

I detta exempel använder vi oss av de certifikat som genererades på applikationsservern i avsnitt Generera självsignerade certifikat.

• keystore_file — Relativ sökväg till keystore för SAML-certifikat. Använder katalogen ...flexite\WEB-INF\classes som rot.
  I detta exempel: saml.jks
• keystore_password — Lösenord i klartext för SAML-keystore.
  I detta exempel: keystore_password
• sign_request — Anger huruvida Requests skickade från flexiteWEB till Identity Provider ska signeras med certifikat eller ej. Nyttjar certifikatet som angivits i 'sign_cert_name'.
  • 0 — Signera inte Requests.
  • 1 — Signera Requests med certifikat.
• sign_cert_name — Namn på det certifikat som ska nyttjas av flexiteWEB för signering av Requests. Motsvarar parametern 'Alias name' för certifikat i keystore.
  I detta exempel: sign_certificate
• sign_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för signering.
  I detta exempel: sign_password
• sign_assertion — Ange huruvida Assertions från Identity Provider måste vara signerade med certifikat eller ej.
  • 0 — Kräv inte signering av Assertions.
  • 1 — Kräv signering av Assertions med certifikat. Kräver att metadata-filen innehåller certifikat för att verifiera signerings-certifikatet.
• encrypt_assertion — Anger huruvida Assertions som skickas från Identity Provider ska krypteras med certifikat eller ej. Nyttjar certifikatet som angivits i 'encrypt_cert_name'.
  • 0 — Kryptera inte Assertions.
  • 1 — Kryptera Assertions med certifikat.
• encrypt_cert_name — Namn på det certifikat som ska nyttjas av Identity Provider för kryptering av Assertions. Motsvarar parametern 'Alias name' för certifikat i keystore.
  I detta exempel: encrypt_certificate
• encrypt_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för kryptering av Assertions.
  I detta exempel: encrypt_password

Konfigurera SAML i flexiteAdmin

Identity Provider metadata

Placera metadata-filen från Identity Provider i följande katalog i flexiteAdmin:

C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml

Konfiguration

Konfigurera SAML i flexiteAdmin med uppgifter om Identity Provider och certifikat. Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.conf

idp_metadata_file=saml_idp.xml
idp_entity_id=https://idp.company.com:9443/
idp_user_attibute_name=urn:oid:2.4.8.128
fx_user_field_name=username
keystore_file=/integration/saml/saml.jks
keystore_password=keystore_password
sign_request=1
sign_cert_name=sign_certificate
sign_cert_password=sign_password
sign_assertion=1
encrypt_assertion=1
encrypt_cert_name=encrypt_certificate
encrypt_cert_password=encrypt_password

Identity Provider

• idp_metadata_file — Relativ sökväg till den metadata-fil som hämtats från Identity Provider. Använder katalogen för SAML som rot.
  I detta exempel: saml_idp.xml
• idp_entity_id — ID för server som agerar Identity Provider.
  I detta exempel: https://idp.company.com:9443/
• idp_user_attribute_name — Det attribut hos Identity Provider som innehåller användar-id.
  I detta exempel: urn:oid:2.4.8.128
• fx_user_field_name — Det attribut i flexite som användar-id från Identity Provider ska verifieras mot. Möjliga alternativ:
  • username — Användarnamn angivet på användarkortet i flexite.
  • unique-id — Unik sträng angiven på användarkortet i flexite.

Certifikat

I detta exempel använder vi oss av de certifikat som genererades på applikationsservern i avsnitt Generera självsignerade certifikat.

• keystore_file — Relativ sökväg till keystore för SAML-certifikat. Använder katalogen för SAML som rot.
  I detta exempel: saml.jks
• keystore_password — Lösenord i klartext för SAML-keystore.
  I detta exempel: keystore_password
• sign_request — Anger huruvida Requests skickade från flexiteAdmin till Identity Provider ska signeras med certifikat eller ej. Nyttjar certifikatet som angivits i 'sign_cert_name'.
  • 0 — Signera inte Requests.
  • 1 — Signera Requests med certifikat.
• sign_cert_name — Namn på det certifikat som ska nyttjas av flexiteAdmin för signering av Requests. Motsvarar parametern 'Alias name' för certifikat i keystore.
  I detta exempel: sign_certificate
• sign_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för signering.
  I detta exempel: sign_password
• sign_assertion — Ange huruvida Assertions från Identity Provider måste vara signerade med certifikat eller ej.
  • 0 — Kräv inte signering av Assertions.
  • 1 — Kräv signering av Assertions med certifikat. Kräver att metadata-filen innehåller certifikat för att verifiera signerings-certifikatet.
• encrypt_assertion — Anger huruvida Assertions som skickas från Identity Provider ska krypteras med certifikat eller ej. Nyttjar certifikatet som angivits i 'encrypt_cert_name'.
  • 0 — Kryptera inte Assertions.
  • 1 — Kryptera Assertions med certifikat.
• encrypt_cert_name — Namn på det certifikat som ska nyttjas av Identity Provider för kryptering av Assertions. Motsvarar parametern 'Alias name' för certifikat i keystore.
  I detta exempel: encrypt_certificate
• encrypt_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för kryptering av Assertions.
  I detta exempel: encrypt_password

Konfigurera SAML i flexitePortal

Identity Provider metadata

Placera metadata-filen från Identity Provider i följande katalog i flexitePortal:

C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\metadata\external

Konfiguration — Externa användare

Konfigurera SAML i flexitePortal med uppgifter om Identity Provider och certifikat.

I detta exempel använder vi SAML för att autentisera externa användare som inte har personliga konton i flexite. Denna lösning förutsätter att flexite konfigurerats att nyttja Identiteter (flexite — Komponenten Identitet och flexitePortal).

Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml.json

{
  "spEntityId": "https://flexite.company.com/flexitePortal/app/authentication/saml/metadata",
  "providers": {
    "external_idp": {
      "idpMetadataPath": "metadata/external/saml_idp.xml",
      "authenticationFlow": "external",
      "displayName": "External IdP",
      "attributeMappings": {
        "firstName": "urn:oid:2.4.8.16",
        "lastName": "urn:oid:2.4.8.32",
        "mail": "urn:oid:2.4.8.64",
        "uniqueId": "urn:oid:2.4.8.128"
      },
      "subjectIdSource": "uniqueId",
      "requireSignedResponse": false,
      "requireSignedAssertion": true,
      "keystorePath": "saml.jks",
      "keystoreType": "JKS",
      "keystorePassword": "keystore_password",
      "signAuthnRequest": true,
      "keyAlias": "sign_certificate",
      "keyPassword": "sign_password",
      "encryptAssertion": true,
      "encryptionKeyAlias": "encrypt_certificate",
      "encryptionKeyPassword": "encrypt_password",
      "nameLetterCase": "none",
      "clockSkewSeconds": 120
    }
  }
}

Service Provider

• spEntityId — Service Provider-identitet som nyttjas av flexitePortal. Denna identitet gäller för samtliga Identity Providers.
  I detta exempel: https://flexite.company.com/flexitePortal/app/authentication/saml/metadata

Identity Provider

Uppgifter för Identity Providers anges i providers, där en profil skapas per Identity Provider. I detta exempel har vi döpt vår profil till 'external_idp'.

• idpMetadataPath — Relativ sökväg till den metadata-fil som hämtats från Identity Provider. Använder katalogen för SAML som rot.
  I detta exempel: metadata/external/saml_idp.xml
• authenticationFlow — Anger huruvida SAML-inloggning ska ske med interna flexite-konton eller externa Identiteter.
  • external — Inloggning sker med externa Identiteter. Slagning sker mot Identitetsattribut. För nya identiteter skapas automatiskt ett nytt konto.
  • internal — Inloggning sker med interna flexite-konton. Stöds ej i dagsläget.
• displayName — Valfritt visningsnamn för profilen som presenteras i gränssnittet. Om inget namn anges visas istället profilnamnet.
  I detta exempel: External IdP
• attributeMappings — Koppla SAML-attribut till Identitetsattribut och variablar som kan nyttjas av andra funktioner.
  • firstName — Ange vilket SAML-attribut som motsvarar en Identitets förnamn. Obligatoriskt attribut.
    I detta exempel: urn:oid:2.4.8.16
  • lastName — Ange vilket SAML-attribut som motsvarar en Identitets efternamn. Obligatoriskt attribut.
    I detta exempel: urn:oid:2.4.8.32
  • mail — Ange vilket SAML-attribut som motsvarar en Identitets e-postadress.
    I detta exempel: urn:oid:2.4.8.64
  • uniqueId — SAML-attribut som i vårt exempel innehåller användarens unika ID.
    I detta exempel: urn:oid:2.4.8.128
• subjectIdSource — Anger vilket attribut från 'attributeMappings' som ska användas som unikt ID för Identiteten i flexite. Det är med den Identitet som matchar detta värde som inloggning kommer ske.
• requireSignedResponse — Ange huruvida svar från Identity Provider måste vara signerade med certifikat eller ej.
  • true — Kräv signering av svar med certifikat. Kräver att metadata-filen innehåller certifikat för att verifiera signerings-certifikatet.
  • false — Kräv inte signering av svar.
• requireSignedAssertion — Ange huruvida Assertions från Identity Provider måste vara signerade med certifikat eller ej.
  • true — Kräv signering av Assertions med certifikat. Kräver att metadata-filen innehåller certifikat för att verifiera signerings-certifikatet.
  • false — Kräv inte signering av Assertions.

Certifikat

Inställningar för certifikat anges per Identity Provider i providers.

• keystorePath — Relativ sökväg till keystore för SAML-certifikat. Använder katalogen för SAML som rot.
  I detta exempel: saml.jks
• keystoreType — Format på keystore. Stödjer 'JKS' (Java KeyStore) och 'PKCS12' (Public-Key Cryptography Standards #12).
  I detta exempel: JKS
• keystorePassword — Lösenord i klartext för SAML-keystore.
  I detta exempel: keystore_password
• signAuthnRequest — Ange huruvida Requests som skickas från flexitePortal till Identity Provider ska signeras med certifikat eller ej. Nyttjar certifikatet som angivits i 'keyAlias'.
  • true — Signera Requests med certifikat.
  • false — Signera inte Requests.
• keyAlias — Namn på det certifikat som ska nyttjas av flexitePortal för signering av Requests. Motsvarar parametern 'Alias name' för certifikat i keystore.
  I detta exempel: sign_certificate
• keyPassword — Lösenord i klartext för det certifikat som ska nyttjas för signering av Requests.
  I detta exempel: sign_password
• encryptAssertion — Ange huruvida Assertions från Identity Provider ska krypteras med certifikat eller ej. Nyttjar certifikatet som angivits i 'encryptionKeyAlias'.
  • true — Kryptera Assertions med certifikat.
  • false — Kryptera inte Assertions.
• encryptionKeyAlias — Namn på det certifikat som ska nyttjas av Identity Provider för kryptering av Assertions. Motsvarar parametern 'Alias name' för certifikat i keystore.
  I detta exempel: encrypt_certificate
• encryptionKeyPassword — Lösenord i klartext för det certifikat som ska nyttjas för kryptering av Assertions.
  I detta exempel: encrypt_password

Övrigt

• nameLetterCase — Ange hur namn-information som mottas från Identity Provider ska formateras när det sparas till flexite. Namn-information inkluderar attribut som innehåller för- och efternamn och berör inte information såsom e-postadress eller unikt ID.
  • none — Använd formatering från leverantör. Standardbeteende om parametern utelämnas.
  • uppercase — Formatera namn i versaler.
  • titlecase — Formatera namn med inledande versal.
• clockSkewSeconds — Tillåten klockskillnad i sekunder mellan Identity Provider och flexitePortal vid validering av tidsstämplar i SAML Assertions.
  Standardvärde: 180

Registrera webbapplikationer hos Identity Provider

För att webbapplikationerna ska kunna nyttja SAML måste applikationerna först registreras som Service Providers hos önskad Identity Provider.

Registrera flexiteWEB

På den server som agerar Identity Provider, registrera flexiteWEB som Service Provider. För detta behöver URL för metadata i flexiteWEB anges. I en standardinstallation ser den ut på följande vis:

https://flexite.company.com/flexite/login/saml.jsp?metadata=1

Registrera flexiteAdmin

På den server som agerar Identity Provider, registrera flexiteAdmin som Service Provider. För detta behöver URL för metadata i flexiteAdmin anges. I en standardinstallation ser den ut på följande vis:

https://flexite.company.com/flexiteAdmin/saml/metadata

Registrera flexitePortal

På den server som agerar Identity Provider, registrera flexitePortal som Service Provider. För detta behöver URL för metadata för aktuell Identity Provider i flexitePortal anges. Denna URL konstrueras från spEntityId + provider för aktuell Identity Provider, angiven i saml.json.

I vårt exempel ser den ut på följande vis:

https://flexite.company.com/flexitePortal/app/authentication/saml/metadata/external_idp

Aktivera inloggning via SAML i webbapplikationer

Med kommunikationen mellan webbapplikationerna (Service Providers) och Identity Provider upprättad återstår det att aktivera automatisk inloggning via SAML i applikationerna.

För flexiteWEB och flexiteAdmin sker detta genom att i konfigurationsfiler ange vilka inloggningsmetoder som ska nyttjas.

I flexitePortal presenteras samtliga aktiva inloggningsmetoder automatiskt, och ingen vidare konfiguration krävs.

Inloggning via SAML i flexiteWEB

I flexiteWEB är det möjligt att simultant tillåta både manuell och automatisk inloggning. I detta fall visas en välkomstsida vid anslutning till flexiteWEB där användaren ombeds välja metod för inloggning; manuellt med flexite- eller LDAP-konto eller automatiskt enligt konfigurerad integration.

Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexite\WEB-INF\classes\settings\flexite.conf

login-type-manual=NONE
login-type-auto=SAML

• login-type-manual — Ange val av manuell autentiseringsmetod där användare själva behöver mata in inloggningsuppgifter.
  Tillgängliga alternativ:
  • FLEXITE — Autentisera mot samtliga användare i flexite-databasen.
  • FLEXITE_RESTRICTED — Autentisera mot de användare i flexite-databasen som givits tillåtelse att logga in manuellt när systemet använder begränsad inloggning. Denna inställning aktiveras på den individuelle användarens användarkort.
    För information om användarinställningar, se avsnitt Användarinformation i flexite Administration.
  • LDAP — Autentisera mot extern LDAP-server. Kräver ytterligare konfiguration.
  • NONE — Tillåt inte manuell inloggning.
• login-type-auto — Ange val av automatisk autentiseringsmetod där användare inte själva behöver mata in inloggningsuppgifter. För nyttjande av SAML anges alternativet 'SAML'.

Fig.50: Exempel på välkomstsida när både manuell och automatisk inloggning nyttjas.

Inloggning via SAML i flexiteAdmin

I flexiteAdmin är det möjligt att simultant tillåta både manuell och automatisk inloggning. I detta fall visas en välkomstsida vid anslutning till flexiteAdmin där användaren ombeds välja metod för inloggning; manuellt med flexite-konto eller automatiskt enligt konfigurerad integration.

Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\flexiteAdmin.conf

login-type=SAML

• login-type — Ange val av autentiseringsmetod. Multipla metoder separeras med mellanslag.
  Tillgängliga alternativ:
  • MANUAL — Manuell autentisering mot samtliga användare i flexite-databasen.
  • SAML — Automatisk autentisering mot SAML IdP.

Fig.51: Exempel på välkomstsida när både manuell och automatisk inloggning nyttjas.

Inloggning via SAML i flexitePortal

I flexitePortal presenteras samtliga inloggningsalternativ som konfigurerats och användaren ombeds välja metod för inloggning.

Fig.52: Exempel där inloggning med både BankID och SAML (döpt till "External IdP") är möjlig.

Starta webbapplikationer

1. Ta bort samtliga filer och kataloger för berörda applikationer i Catalina Work:

   • C:\tomcat\work\Catalina\localhost\flexite
   • C:\tomcat\work\Catalina\localhost\flexiteAdmin
   • C:\tomcat\work\Catalina\localhost\flexitePortal

2. Starta de berörda applikationerna.

Uppdatera certifikat

Certifikat utfärdas med en fast giltighetstid och behöver således uppdateras med jämna mellanrum. Denna typ av uppdatering går i korthet ut på att ersätta befintliga certifikat med nya. Certifikat kan antingen utfärdas av en betrodd Certificate Authority, men det är även möjligt att generera självsignerade certifikat lokalt i Apache Tomcat.

Certifikaten installeras i en individuell Java Keystore per applikation, som standard 'saml.jks'. I och med att denna keystore enbart används för SAML är det rekommenderat att skapa en ny keystore för de nya certifikaten istället för att lägga till fler certifikat till befintlig.

Det är rekommenderat att använda unika certifikat för de individuella applikationerna.

Uppdatering av certifikat utförs i följande grundläggande steg:

1. Ta reda på information om befintliga certifikat.
2. Stoppa webbapplikationer.
3. Installera certifikat i webbapplikationer.
4. Uppdatera konfiguration av SAML i webbapplikationer.
5. Starta webbapplikationer.
6. Uppdatera metadata för webbapplikationer (Service Providers) hos Identity Provider.

Ta reda på information om befintliga certifikat

För certifikat som genereras på applikationsservern är det rekommenderat att återanvända information från befintliga certifikat. För att ta reda på denna information används konfigurationsfilerna för SAML i respektive applikation samt verktyget keytool beläget i C:\tomcat\jdk\bin.

Befintliga certifikat i flexiteWEB

I flexiteWEB har konfigurationsfilen för SAML följande sökväg:

C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.conf

1. Ta reda på filnamn och lösenord för aktuell keystore i konfigurationsfilen för SAML.

   keystore_file=/integration/saml/saml.jks
   keystore_password=keystore_password

   • keystore_file — Relativ sökväg till aktuell keystore. Använder ..\flexite\WEB-INF\classes som rot.
     I detta exempel: /integration/saml/saml.jks
   • keystore_password — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

2. Visa detaljerad information om samtliga certifikat i aktuell keystore. Navigera till C:\tomcat\jdk\bin och kör följande kommando:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

3. Notera värden för följande parametrar för respektive certifikat:

   • Alias name — Namnet på certifikatet.
   • Owner/Issuer — Den som utfärdat certifikatet.

Befintliga certifikat i flexiteAdmin

I flexiteAdmin har konfigurationsfilen för SAML följande sökväg:

C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.conf

1. Ta reda på filnamn och lösenord för aktuell keystore i konfigurationsfilen för SAML.

   keystore_file=saml.jks
   keystore_password=keystore_password

   • keystore_file — Relativ sökväg till aktuell keystore. Använder katalogen för SAML som rot.
     I detta exempel: saml.jks
   • keystore_password — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

2. Visa detaljerad information om samtliga certifikat i aktuell keystore. Navigera till C:\tomcat\jdk\bin och kör följande kommando:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

3. Notera värden för följande parametrar för respektive certifikat:

   • Alias name — Namnet på certifikatet.
   • Owner/Issuer — Den som utfärdat certifikatet.

Befintliga certifikat i flexitePortal

I flexitePortal har konfigurationsfilen för SAML följande sökväg:

C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml.json

1. Ta reda på filnamn och lösenord för aktuella keystores i konfigurationsfilen för SAML. flexitePortal har stöd för att nyttja flera Identity Providers samtidigt, och varje Identity Provider kan ha en egen keystore. Varje individuell Identity Provider sparas till en unik provider.

   "providers": {
     "external_idp": {
       ...
       "keystorePath": "saml.jks",
       "keystoreType": "JKS",
       "keystorePassword": "keystore_password",
       ...
     }
   }

   • keystorePath — Relativ sökväg till aktuell keystore. Använder katalogen för SAML som rot.
     I detta exempel: saml.jks
   • keystoreType — Format på keystore.
     I detta exempel: JKS
   • keystorePassword — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

2. Visa detaljerad information om samtliga certifikat i aktuell keystore. Navigera till C:\tomcat\jdk\bin och kör följande kommando:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

3. Notera värden för följande parametrar för respektive certifikat:

   • Alias name — Namnet på certifikatet.
   • Owner/Issuer — Den som utfärdat certifikatet.

Stoppa webbapplikationer och ta backup

• Stoppa webbapplikationerna.
• Ta backup på befintliga keystores genom att döpa om dem eller flytta dem till annan plats.
  • I flexiteWEB har keystore följande sökväg som standard: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
  • I flexiteAdmin har keystore följande sökväg som standard: C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks
  • I flexitePortal har keystore följande sökväg som standard: C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks

Installera nya certifikat i webbapplikationer

Uppdatering av certifikat sker genom att importera nya certifikat från en betrodd Certificate Authority alternativt generera nya självsignerade certifikat och lagra dem i nya keystores.

Importera certifikat från betrodd Certificate Authority

För information om tillvägagångssätt för att importera certifikat utfärdade av en betrodd Certificate Authority, se kapitel för respektive applikation:

• flexiteWEB — Importera certifikat från betrodd Certificate Authority
• flexiteAdmin — Installera certifikat i flexiteAdmin
• flexitePortal — Installera certifikat i flexitePortal

Rekommendation för keystore

• Använd samma filnamn som för tidigare keystore. Parametern keystore i verktyget keytool och keystore_file i konfigurationsfilen saml.conf.
• Ange nytt lösenord enligt policy.

Generera självsignerade certifikat

För information om tillvägagångssätt för att generera självsignerade certifikat lokalt på applikationsservern, se kapitel för respektive applikation:

• flexiteWEB — Generera självsignerade certifikat
• flexiteAdmin — Installera certifikat i flexiteAdmin
• flexitePortal — Installera certifikat i flexitePortal

Rekommendation för keystore

• Använd samma filnamn som för tidigare keystore. Parametern keystore i verktyget keytool och keystore_file i konfigurationsfilen saml.conf.
• Ange nytt lösenord enligt policy.

Rekommendation för certifikat

• Använd samma namn som för tidigare certifikat. Parametern alias i verktyget keytool och sign_cert_name respektive encrypt_cert_name i konfigurationsfilen saml.conf.
• Använd samma ägaruppgifter som för tidigare certifikat.
• Ange giltighetstid enligt policy.
• Ange nya lösenord enligt policy.

Uppdatera konfiguration i flexiteWEB

Konfigurera SAML i flexiteWEB att nyttja de nya certifikaten. Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.conf

1. Visa detaljerad information om certifikat i aktuell keystore. Detta utförs med verktyget keytool, tillgängligt i C:\tomcat\jdk\bin:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexite\WEB-INF\classes\integration\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

2. Redigera konfigurationsfilen för SAML i flexiteWEB; saml.conf.

   keystore_file=/integration/saml/saml.jks
   keystore_password=keystore_password
   sign_request=1
   sign_cert_name=sign_certificate
   sign_cert_password=sign_password
   sign_assertion=1
   encrypt_assertion=1
   encrypt_cert_name=encrypt_certificate
   encrypt_cert_password=encrypt_password

   Av intresse är följande parametrar:

   • keystore_file — Relativ sökväg till aktuell keystore. Använder ..\flexite\WEB-INF\classes som rot.
     I detta exempel: /integration/saml/saml.jks
   • keystore_password — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password
   • sign_cert_name — Namn på det certifikat som ska nyttjas för signering. Motsvarar parametern Alias name för certifikat i keystore.
     I detta exempel: sign_certificate
   • sign_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för signering.
     I detta exempel: sign_password
   • encrypt_cert_name — Namn på det certifikat som ska nyttjas för kryptering. Motsvarar parametern Alias name för certifikat i keystore.
     I detta exempel: encrypt_certificate
   • encrypt_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för kryptering.
     I detta exempel: encrypt_password

Uppdatera konfiguration i flexiteAdmin

Konfigurera SAML i flexiteAdmin att nyttja de nya certifikaten. Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.conf

1. Visa detaljerad information om certifikat i aktuell keystore. Detta utförs med verktyget keytool, tillgängligt i C:\tomcat\jdk\bin:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexiteAdmin\WEB-INF\classes\settings\integration\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

2. Redigera konfigurationsfilen för SAML i flexiteAdmin; 'saml.conf'.

   keystore_file=saml.jks
   keystore_password=keystore_password
   sign_request=1
   sign_cert_name=sign_certificate
   sign_cert_password=sign_password
   sign_assertion=1
   encrypt_assertion=1
   encrypt_cert_name=encrypt_certificate
   encrypt_cert_password=encrypt_password

   Av intresse är följande parametrar:

   • keystore_file — Relativ sökväg till aktuell keystore. Använder katalogen för SAML som rot.
     I detta exempel: saml.jks
   • keystore_password — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password
   • sign_cert_name — Namn på det certifikat som ska nyttjas för signering. Motsvarar parametern Alias name för certifikat i keystore.
     I detta exempel: sign_certificate
   • sign_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för signering.
     I detta exempel: sign_password
   • encrypt_cert_name — Namn på det certifikat som ska nyttjas för kryptering. Motsvarar parametern Alias name för certifikat i keystore.
     I detta exempel: encrypt_certificate
   • encrypt_cert_password — Lösenord i klartext för det certifikat som ska nyttjas för kryptering.
     I detta exempel: encrypt_password

Uppdatera konfiguration i flexitePortal

Konfigurera SAML i flexitePortal att nyttja de nya certifikaten. Konfigurationsfilen har följande sökväg:

C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.json

1. Visa detaljerad information om certifikat i aktuell keystore. Detta utförs med verktyget keytool, tillgängligt i C:\tomcat\jdk\bin:

   keytool.exe -list -v -keystore "C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks" -storepass keystore_password

   • list — Kommando för att visa information om innehåll i angiven keystore.
   • v — Tilläggskommando till 'list' för att visa detaljerad information.
   • keystore {sökväg} — Fullständig sökväg till den keystore-fil som använts för certifikaten.
     I detta exempel: C:\tomcat\webapps\flexitePortal\WEB-INF\classes\settings\saml\saml.jks
   • storepass {lösenord} — Lösenord i klartext för aktuell keystore.
     I detta exempel: keystore_password

2. Redigera konfigurationsfilen för SAML i flexitePortal; 'saml.json'.

   "providers": {
     "external_idp": {
       ...
       "keystorePath": "saml.jks",
       "keystoreType": "JKS",
       "keystorePassword": "keystore_password",
       "keyAlias": "sign_certificate",
       "keyPassword": "sign_password",
       "encryptionKeyAlias": "encrypt_certificate",
       "encryptionKeyPassword": "encrypt_password",
       ...
     }
   }

   • keystorePath — Relativ sökväg till keystore för SAML-certifikat. Använder katalogen för SAML som rot.
     I detta exempel: saml.jks
   • keystoreType — Format på keystore.
     I detta exempel: JKS
   • keystorePassword — Lösenord i klartext för SAML-keystore.
     I detta exempel: keystore_password
   • keyAlias — Namn på det certifikat som ska nyttjas av flexitePortal för signering av Requests. Motsvarar parametern 'Alias name' för certifikat i keystore.
     I detta exempel: sign_certificate
   • keyPassword — Lösenord i klartext för det certifikat som ska nyttjas för signering av Requests.
     I detta exempel: sign_password
   • encryptionKeyAlias — Namn på det certifikat som ska nyttjas av Identity Provider för kryptering av Assertions. Motsvarar parametern 'Alias name' för certifikat i keystore.
     I detta exempel: encrypt_certificate
   • encryptionKeyPassword — Lösenord i klartext för det certifikat som ska nyttjas för kryptering av Assertions.
     I detta exempel: encrypt_password

Starta webbapplikationer

1. Ta bort samtliga filer och kataloger för berörda applikationer i Catalina Work:

   • C:\tomcat\work\Catalina\localhost\flexite
   • C:\tomcat\work\Catalina\localhost\flexiteAdmin
   • C:\tomcat\work\Catalina\localhost\flexitePortal

2. Starta de berörda applikationerna.

Uppdatera metadata för webbapplikationer hos Identity Provider

På den server som agerar Identity Provider, uppdatera metadata via URL:

• flexiteWEB — https://flexite.company.com/flexite/login/saml.jsp?metadata=1
• flexiteAdmin — https://flexite.company.com/flexiteAdmin/saml/metadata
• flexitePortal — URL konstrueras från spEntityId + provider för aktuell Identity Provider, angiven i saml.json. I detta exempel: https://flexite.company.com/flexitePortal/app/authentication/saml/metadata/external_idp

Säkerhet — Anpassa åtkomst till flexiteWEB Web Service

Web Services i flexiteWEB används för kommunikation med flexiteProcessEngine samt integrationer med externa system. Som standard tillåts åtkomst till Web Services enbart från den server som utgör host åt flexiteWEB. I miljöer där enbart flexiteProcessEngine behöver åtkomst till dessa Web Services är detta oftast fullt tillräckligt, eftersom standardförfarandet är att flexiteProcessEngine är belägen på samma server.

I de fall där det finns behov av att tillåta åtkomst till Web Services från externa system kan detta aktiveras individuellt per flexiteWEB-instans och individuellt per Web Service. Detta betyder att i miljöer med en intern och en extern server kan åtkomst aktiveras för vissa Web Services på den interna och för andra Web Services på den externa.

Notera att denna aktivering resulterar i publik åtkomst till aktuell Web Service. Eventuella behov av begränsningar till specifika externa system hanteras i mellanliggande brandväggar.

Extern åtkomst aktiveras för individuella Web Services i flexiteWEBs konfigurationsfil customer.conf.

Tillgängliga Web Services

Konfigurationen kräver att de exakta namnen anges för de Web Services där extern åtkomst ska göras tillgänglig. Fullständiga namn på tillgängliga Web Services för aktuell flexiteWEB går att se via en URL med strukturen https://{webServer}/{webappName}/services.

Exempel: https://flexite.company.com/flexite/services

Denna sida listar samtliga tillgängliga Web Services för aktuell flexiteWEB tillsammans med tillgängliga funktioner för varje Web Service.

Konfiguration av customer.conf

Konfiguration av extern åtkomst till Web Services utförs i C:\tomcat\webapps\flexite\WEB-INF\classes\settings\customer.conf: med parametern Web.Service.Allow.External.Access.

Med denna parameter anges för vilka individuella Web Services som extern åtkomst ska tillåtas. Multipla Web Services separeras med mellanslag.

Om parametern saknar värde eller saknas helt blockeras extern åtkomst till samtliga Web Services.

Exempel

För att aktivera extern åtkomst till samtliga Web Services konfigureras parametern Web.Service.Allow.External.Access på följande vis:

Web.Service.Allow.External.Access=ImportExportService Expired flexiteDBLinkRoleTask searchInstance signInstance myMessages adHoc RegisterComplaintAndFeedback

Säkerhet — Hantering av krypteringsnycklar för XML

flexite använder en privat unik nyckel för att kryptera, och dekryptera, innehållet i de tillfälliga XML-filer som skapas och läses av flexite för exempelvis integrationer. Denna nyckel används ej för kryptering eller dekryptering av XML som skickas till eller från ett externt system.

Denna nyckel genereras, om den inte redan existerar, vid första uppstart av flexiteCLIENT, flexiteProcessEngine och flexiteDB-link.

Fig.53: Krypteringsnycklar. Exempel på en aktiv nyckel för kryptering och dekryptering samt en historisk nyckel för enbart dekryptering.

Verktygsfält

Skapa ny nyckel för kryptering och dekrypteringGenerera ny unik nyckel. Den nya nyckeln kommer att nyttjas för framtida krypteringar. Befintlig nyckel för kryptering kommer framgent enbart att nyttjas för dekryptering.

Importera nycklar för dekrypteringImportera krypteringsnycklar exporterade från flexite. De importerade nycklarna kommer enbart att nyttjas för dekryptering.Nycklar som redan existerar i databasen importeras ej.

Exportera samtliga nycklar för kryptering och dekrypteringExportera samtliga krypteringsnycklar till fil för import i annat flexite-system. Dessa nycklar kommer enbart att användas för dekryptering av det flexite-system som de importeras i.

Tabellinnehåll

• Unikt ID – Unikt ID för aktuell krypteringsnyckel.
• Skapad – Tidpunkt för när aktuell krypteringsnyckel sparades till databasen. Detta avser både skapande av nyckel samt import av nyckel.
• Användning – Användningsområde för aktuell krypteringsnyckel.
  • Kryptering och dekryptering – Krypteringsnyckeln nyttjas för både kryptering och dekryptering av XML. Enbart en nyckel kan nyttjas för kryptering, och detta är uteslutande den nyckel som senast skapats i systemet.
  • Dekryptering enbart – Krypteringsnyckeln nyttjas enbart för dekryptering. Detta appliceras på samtliga historiska och importerade nycklar.

Stöd för multipla nycklar

flexite stödjer att nyttja en nyckel för kryptering och multipla nycklar för dekryptering. Den nyckel som nyttjas för kryptering är uteslutande den nyckel som senast skapats i systemet, medans övriga nycklar i systemet enbart nyttjas för dekryptering.

Spårbarhet av nycklar i XML-filer

Vid kryptering av innehåll i en XML-fil skriver flexite in det unika ID:t för den nyckel som nyttjats för krypteringen. Detta ID skrivs i krypterad form till XML-filen, men för denna kryptering används en statisk krypteringsnyckel som är hårdkodad i flexite.

Stöd för äldre nyckel

I äldre versioner av flexite krypterades XML-innehåll med en statisk krypteringsnyckel hårdkodad i applikationen. Denna nyckel nyttjas ej längre för att kryptera innehåll i nya XML-filer, men används vid behov för att dekryptera innehåll i gamla XML-filer.

I och med att äldre versioner av flexite använde en statisk krypteringsnyckel för kryptering av XML-innehåll skrevs ingen information om denna nyckel till XML-filen.

Förfarande vid dekryptering av XML

Förfarandet för när flexite läser in en XML-fil var innehåll krypterats av flexite ser ut på följande grundläggande vis:

• flexite läser det unika ID som använts för att kryptera innehållet.
• Om det unika ID:t återfinns i flexites databas dekrypteras innehållet med den nyckel som motsvarar det unika ID:t och behandlas i enlighet med aktuell uppgift.
• Om det unika ID:t inte återfinns i flexites databas kan flexite inte dekryptera innehållet och vidare behandling av aktuell fil kan därmed inte slutföras. Detta loggas och rapporteras i enlighet med aktuell uppgift.
• Om ingen information om unikt ID finns registrerat i XML-filen nyttjar flexite den hårdkodade krypteringsnyckeln för att dekryptera innehållet i filen och behandla det i enlighet med aktuell uppgift.

Säkerhet — Kryptering av databaskommunikation

För att säkerställa riktighet och konfidentialitet i den information som hanteras i flexite är det rekommenderat att kryptera kommunikationen mellan de olika noderna.

Vi har i tidigare kapitel nämnt hur kommunikationen mellan klientens webbläsare och webbservern kan skyddas med hjälp av HTTPS; krypterad HTTP-trafik.

I detta kapitel går vi igenom hur kommunikationen mellan applikationsservrar och databasserver kan skyddas med hjälp av kryptering av SQL-protokollet. Detta resulterar i att anslutningar från flexite applikationssvit till databasservern säkras.

Konfiguration av kryptering sker på Microsoft SQL-instanser. Detta kräver att ett giltigt TLS-certifikat är installerat och tilldelat SQL-instansen på databasservern.

För mer information om certifikat och konfiguration av Microsoft SQL Server, se Microsofts artikel:

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine

Krav på certifikat

Till skillnad från Microsoft IIS tillåter Microsoft SQL Server som standard inte längre nyttjande av så kallade wildcard-certifikat, utan kräver certifikat utfärdade för det FQDN som databasservern använder.

Det är kritiskt att säkerställa att det Service Account som används för SQL-instansen på databasservern har rättighet att läsa det aktuella certifikatet.

För att flexites applikationer ska kunna verifiera det certifikat som nyttjas av SQL-servern är det kritiskt att säkerställa att certifikatet, eller certifikatkedjan, för den Certificate Authority (CA) som utfärdat certifikatet existerar i respektive keystore på applikationsservern. Certifikat utfärdade av en stor publik CA kräver sällan någon extra administration, men för certifikat som utfärdats av en privat CA kan rotcertifikatet för CA behöva installeras manuellt.

För information om certifikathantering, se avsnitt Certifikathantering.

Identifiera Service Account för SQL-instans

För att kunna tilldela rättigheter till certifikatet måste vi veta vilket konto som används för den SQL-instans för vilken kommunikationen ska krypteras. Detta arbete utförs på databasservern.

1. Starta 'SQL Server Configuration Manager'.
2. Navigera till 'SQL Server Services', högerklicka på tjänsten 'SQL Server ({dbInstance})' och välj 'Properties'. '{dbInstance}' är namnet på den SQL-instans för vilken anslutningar ska krypteras.
   • Under fliken 'Log On', notera kontot angivet för 'Account Name'. Som standard skapar Microsoft SQL ett konto som namnges enligt strukturen 'NT Service\MSSQL${dbInstance}', där '{dbInstance}' är namnet på SQL-instans för vilken anslutningar ska krypteras.

Verifiera rättigheter till certifikat för aktuellt Service Account

När vi vet vilket konto som nyttjas av SQL-instansen kan vi säkerställa att kontot har rättigheter till den privata nyckeln för certifikatet. Detta arbete utförs på databasservern.

1. Starta 'Microsoft Management Console'.
2. Öppna menyn 'File' och välj 'Add/Remove Snap-in'.
3. Lägg till 'Certificates' och välj det 'store' som det aktuella certifikatet är installerat till; vanligtvis 'My user account' eller 'Computer account' (för 'Local computer'). Klicka 'OK'.
4. Navigera till den mapp som certifikatet installerats till; vanligtvis 'Personal > Certificates'.
5. Högerklicka på aktuellt certifikat och välj 'All Tasks > Manage Private Keys...'.
   • Verifiera att kontot angivet för SQL-instansen har rättighet att läsa certifikatet.
   • Om kontot saknas i listan, lägg till det genom att klicka på 'Add...' och söka rätt på kontot. Om standardkonto används kan det vara nödvändigt att söka på det kompletta kontonamnet; 'NT Service\MSSQL${dbInstance}'. Säkerställ att sökningen utförs på rätt plats ('Locations...'), standardkontot ligger exempelvis på den lokala maskinen och inte på domännivå.

Konfigurera anslutningskryptering på SQL-instans

Som standard tillåter Microsoft SQL både okrypterade och krypterade anslutningar, och nyttjar ett self-signed certifikat för krypterade anslutningar.

Detta kapitel beskriver hur en befintlig Microsoft SQL-instans kan konfigureras att nyttja ett certifikat samt enbart tillåta krypterade anslutningar till instansen. Dessa steg förutsätter att en SQL-instans existerar samt att ett giltigt TLS-certifikat finns installerat på servern.

1. Starta 'SQL Server Configuration Manager'.
2. Expandera 'SQL Server Network Configuration', högerklicka på 'Protocols for {dbInstance}' och välj 'Properties'. '{dbInstance}' är namnet på den SQL-instans för vilken anslutningar ska krypteras.

   • Under fliken 'Flags', utför följande konfiguration för att enbart tillåta krypterade anslutningar:

     • Force Encryption — Yes

     Det är möjligt att fortsätta tillåta okrypterade anslutningar till instansen genom att inte aktivera 'Force Encryption', men av säkerhetsskäl detta inte rekommenderat.
     Om databaser belägna på samma SQL-instans har behov av okrypterade anslutningar är det rekommenderat att istället flytta dessa databaser till en annan instans.

   • Under fliken 'Certificate', välj ett giltigt certifikat som ska nyttjas av instansen.

   • Klicka 'OK' för att spara utförda ändringar

3. Navigera till 'SQL Server Services' och starta om tjänsten 'SQL Server ({dbInstance})' för att ändringarna ska träda i kraft. '{dbInstance}' är namnet på den SQL-instans för vilken anslutningar ska krypteras.

Konfigurera flexite att ansluta till SQL-instans

Detta kapitel beskriver hur applikationerna i flexite konfigureras för att ansluta till en Microsoft SQL-instans. Det är möjligt att ansluta till en SQL-instans antingen via namnet på instansen eller via den unika porten för instansen, beroende på hur SQL-servern konfigurerats.

Notera att oavsett om konfiguration av anslutning i flexite sker med instans-namn eller port så måste applikationen kunna nå databasservern på den port som är angiven för instansen på SQL-servern.

Dessa konfigurationsexempel gäller för en krypterad anslutning till en specifik SQL-instans på en Microsoft SQL-server med följande egenskaper:

• Servernamn (FQDN) — sqlserver.company.com
• Instansnamn — dbinstance
• Port — 1234
• Databasnamn — flexite

flexiteDBUpdate/hotfixDBUpdate

Applikationerna flexiteDBUpdate och hotfixDBUpdate används vid installation, uppgradering och patchning av applikationssviten flexite.

Konfiguration av databaskoppling för dessa applikationer sker i respektive applikation.

Anslutning via instans-namn

Database — {dbServer}\{dbInstance}:

Exempel

Database — sqlserver.company.com\dbinstance:flexite

Anslutning via port

Applikationerna flexiteDBUpdate och hotfixDBUpdate ansluter till standardporten för Microsoft SQL, 1433, om ingen annan port är angiven. Port konfigureras på följande vis:

Database — {dbServer},{dbPort}:

Exempel

Database — sqlserver.company.com,1234:flexite

flexiteCLIENT

Konfiguration av databaskoppling för flexiteCLIENT sker i flexite.ini, belägen i rotkatalogen för flexiteCLIENT.

Anslutning via instans-namn

[DATABASE CONNECTION]
ConnectServerType=SQLServerEnc
ConnectDatabaseName={dbServer}\{dbInstance}:{dbName}

Exempel

[DATABASE CONNECTION]
ConnectServerType=SQLServerEnc
ConnectDatabaseName=sqlserver.company.com\dbinstance:flexite

Anslutning via port

flexiteCLIENT ansluter till standardporten för Microsoft SQL, 1433, om ingen annan port är angiven. Port konfigureras på följande vis:

[DATABASE CONNECTION]
ConnectServerType=SQLServerEnc
ConnectDatabaseName={dbServer},{dbPort}:{dbName}

Exempel

[DATABASE CONNECTION]
ConnectServerType=SQLServerEnc
ConnectDatabaseName=sqlserver.company.com,1234:flexite

ConnectServerType — Kryptering av databaskommunikation

flexiteCLIENT och flexiteProcessEngine stödjer både krypterad och okrypterad anslutning till databasservern. Detta innebär att det tillåts att falla tillbaka till en okrypterad anslutning i det fall både server och klient stödjer en sådan.

Med parametern ConnectServerType är det möjligt att ange huruvida flexiteCLIENT respektive flexiteProcessEngine ska tillåtas att falla tillbaka till okrypterad anslutning eller ej.

• SQLServer — Tillåt kommunikation över både okrypterat och krypterat protokoll. Konfiguration av SQL-server bestämmer i detta fall vilket protokoll som kommer att nyttjas. I det fall SQL-servern stödjer både krypterat och okrypterat protokoll kommer anslutningen att nyttja okrypterat. Standardvärde om parameter saknas.
• SQLServerEnc — Tillåt enbart kommunikation över krypterat protokoll.

flexiteProcessEngine

Konfiguration av databaskoppling för flexiteProcessEngine sker i flexiteProcessEngine.ini, belägen i rotkatalogen för flexiteProcessEngine.

Anslutning via instans-namn

[Database.0]
ConnectServerType=SQLServerEnc
ConnectDatabaseName={dbServer}\{dbInstance}:{dbName}

Exempel

[Database.0]
ConnectServerType=SQLServerEnc
ConnectDatabaseName=sqlserver.company.com\dbinstance:flexite

Anslutning via port

flexiteProcessEngine ansluter till standardporten för Microsoft SQL, 1433, om ingen annan port är angiven. Port konfigureras på följande vis:

[Database.0]
ConnectServerType=SQLServerEnc
ConnectDatabaseName={dbServer},{dbPort}:{dbName}

Exempel

[Database.0]
ConnectServerType=SQLServerEnc
ConnectDatabaseName=sqlserver.company.com,1234:flexite

ConnectServerType — Kryptering av databaskommunikation

Ange stöd för okrypterad anslutning, se avsnitt ConnectServerType — Kryptering av databaskommunikation.

flexiteWEB

Konfiguration av databaskoppling för flexiteWEB sker i flexite.conf, belägen under {flexiteWEB}\WEB-INF\classes\settings.

Notera att konfigurationen av parametern db-service-name MÅSTE matcha konfigurationen av parametern ConnectDatabaseName i flexiteProcessEngine.ini.

Anslutning via instans-namn

### Database settings
db-service-name={dbServer}\{dbInstance}:{dbName}
db-user-name={dbUserName}
db-user-password={dbUserPassword}
db-server-url=jdbc:sqlserver://{dbServer};instanceName={dbInstance};databaseName={dbName};encrypt=true

Exempel

### Database settings
db-service-name=sqlserver.company.com\dbinstance:flexite
db-user-name=flexite
db-user-password=ABCDEFGH1234567890
db-server-url=jdbc:sqlserver://sqlserver.company.com;instanceName=dbinstance;databaseName=flexite;encrypt=true

Anslutning via port

Parametern db-service-name använder standardporten för Microsoft SQL, 1433, om ingen annan port är angiven. Port konfigureras på följande vis:

### Database settings
db-service-name={dbServer},{dbPort}:{dbName}
db-user-name={dbUserName}
db-user-password={dbUserPassword}
db-server-url=jdbc:sqlserver://{dbServer}:{dbPort};databaseName={dbName};encrypt=true

Exempel

### Database settings
db-service-name=sqlserver.company.com,1234:flexite
db-user-name=flexite
db-user-password=ABCDEFGH1234567890
db-server-url=jdbc:sqlserver://sqlserver.company.com:1234;databaseName=flexite;encrypt=true

encrypt — kryptering av databaskommunikation

flexiteWEB är konstruerat att som standard stödja både krypterad och okrypterad anslutning till databasservern. Detta innebär att det tillåts att falla tillbaka till en okrypterad anslutning i det fall både server och klient stödjer en sådan.

Med parametern encrypt är det möjligt att ange huruvida flexiteWEB ska tillåtas att falla tillbaka till okrypterad anslutning eller ej.

• false — Tillåt kommunikation över både okrypterat och krypterat protokoll. Konfiguration av SQL-server bestämmer i detta fall vilket protokoll som kommer att nyttjas. I det fall SQL-servern stödjer både krypterat och okrypterat protokoll kommer anslutningen att nyttja okrypterat. Standardvärde om parameter saknas.
• true — Tillåt enbart kommunikation över krypterat protokoll.

flexiteAdmin

Konfiguration av databaskoppling för flexiteAdmin sker i flexiteAdmin.conf, belägen under {flexiteAdmin}\WEB-INF\classes\settings.

Anslutning via instans-namn

jdbc-server-url={dbServer};instanceName={dbInstance}
jdbc-database-name={dbName}
jdbc-encrypt=1

Exempel

jdbc-server-url=sqlserver.company.com;instanceName=dbinstance
jdbc-database-name=flexite
jdbc-encrypt=1

Anslutning via port

Parametern jdbc-server-url använder standardporten för Microsoft SQL, 1433, om ingen annan port är angiven. Port konfigureras på följande vis:

jdbc-server-url={dbServer}:{dbPort}
jdbc-database-name={dbName}
jdbc-encrypt=1

Exempel

jdbc-server-url=sqlserver.company.com:1234
jdbc-database-name=flexite
jdbc-encrypt=1

jdbc-encrypt — kryptering av databaskommunikation

flexiteAdmin är konstruerat att som standard stödja både krypterad och okrypterad anslutning till databasservern. Detta innebär att det tillåts att falla tillbaka till en okrypterad anslutning i det fall både server och klient stödjer en sådan.

Med parametern jdbc-encrypt är det möjligt att ange huruvida flexiteAdmin ska tillåtas att falla tillbaka till okrypterad anslutning eller ej.

• 0 — Tillåt kommunikation över både okrypterat och krypterat protokoll. Konfiguration av SQL-server bestämmer i detta fall vilket protokoll som kommer att nyttjas. I det fall SQL-servern stödjer både krypterat och okrypterat protokoll kommer anslutningen att nyttja okrypterat. Standardvärde om parameter saknas.
• 1 — Tillåt enbart kommunikation över krypterat protokoll.

Kontrollera krypteringsstatus

Det är möjligt att kontrollera krypteringsstatus för samtliga aktiva sessioner till en databas med SQL-skript. Observera att detta skript kräver åtkomst till databasen 'master'.

Exempel på skript för att kontrollera status för anslutningar mot databasen ' flexite':

USE [master];

GO
SELECT   es.login_name,
         ec.client_net_address,
         es.client_interface_name,
         es.login_time,
         ec.encrypt_option
FROM     sys.dm_exec_sessions AS es
         INNER JOIN
         sys.dm_exec_connections AS ec
         ON ec.session_id = es.session_id
WHERE    es.database_id = (DB_ID('flexite'))
ORDER BY es.login_time ASC;

Exempel — Resultat

login_name	client_net_address	client_interface_name	login_time	encrypt_option
COMPANY\admin	<local machine>	Framework Microsoft SqlClient Da	2026-04-01 09:01:40.900	TRUE
flexite	192.168.0.10	OLEDB	2026-04-01 11:54:53.230	TRUE
flexite	192.168.0.10	Microsoft JDBC Driver 13.4	2026-04-01 11:57:35.360	TRUE
flexite	192.168.0.10	Microsoft JDBC Driver 13.4	2026-04-01 11:58:01.400	TRUE

Säkerhet — Skydd mot brute force-attacker

I flexiteWEB och flexiteAdmin finns det ett inbyggt skydd mot upprepade inloggningsförsök, så kallade brute force-attacker, mot flexite-konton.

Vad är en brute force-attack?

En brute force-attack är en metod för att komma åt inloggningsuppgifter genom att systematiskt testa alla möjliga kombinationer av tecken. Attacken är automatiserad och utförs med skript och/eller bots som riktar in sig på en utvald inloggningssida. På grund av sin relativt enkla uppbyggnad är brute force en vanlig metod för dataintrång och är något som såväl företag som den enskilda användaren behöver skydda sig emot.

Hur skyddar vi oss mot en brute force-attack?

I flexites programvara finns det i grund och botten två nivåer av skydd mot brute force-attacker:

• Begränsning av antal inloggningsförsök på systemnivå I flexiteWEB och flexiteAdmin är antalet tillåtna misslyckade inloggningsförsök begränsad. Denna begränsning är vad detta dokument behandlar.
• Komplexa och unika lösenord på användarkonton Om ett användarkonto har ett så pass simpelt lösenord att det är enkelt att gissa sig till spelar det ingen roll hur bra övriga skydd är. Lösenord måste vara tillräckligt komplexa för att övriga skydd ska utlösas. Det är rekommenderat att använda en blandning av gemener, versaler, siffror och specialtecken. Det är dessutom viktigt att inloggningsuppgifterna är unika och inte förekommer på andra platser.

Skydd mot brute force-attacker i flexiteWEB och flexiteAdmin

Det är rimligt att anta att en legitim användare från och till misslyckas med ett fåtal inloggningsförsök. Om det däremot sker flertalet misslyckade försök, mot ett eller flera konton, under kort tid är detta att betrakta som suspekt aktivitet.

Detta skydd avser både autentisering i det ordinarie gränssnittet för användare samt autentisering vid åtkomst till flexiteWEBs API.

I flexiteWEB och flexiteAdmin finns ett inbyggt skydd mot upprepade inloggningsförsök mot flexite-konton, baserat på följande scenarion:

• Attack mot enskilt användarkonto — Användarkontot låses efter:
  • 10 konsekutiva misslyckade inloggningsförsök inom 24 timmar, oavsett från vilken IP-adress som försöken utförts.
  • 10 konsekutiva misslyckade inloggningsförsök inom 24 timmar från en och samma IP-adress, oavsett om inloggning lyckats från andra IP-adresser.
• Attacker från enskild IP-adress — Efter 10 misslyckade inloggningsförsök, med ett eller flera användarkonton, inom 60 sekunder från en och samma IP-adress, blockeras IP-adressen från vilken inloggningsförsöken utförts.
• Attacker från flera IP-adresser — Efter 50 misslyckade inloggningsförsök, med ett eller flera användarkonton, inom 60 sekunder blockeras alla anrop till webbapplikationerna flexiteWEB och flexiteAdmin.

Global blockering

Dessa skyddsåtgärder är globala och påverkar samtliga instanser av flexiteWEB och flexiteAdmin i systemet.

Detta betyder att ett användarkonto som låses på grund av misslyckade inloggningsförsök i en instans av flexiteWEB blockeras från att logga in i samtliga instanser av både flexiteWEB och flexiteAdmin. Detsamma gäller för blockering av webbapplikationer.

Skydd för inloggning med PIN-kod

Användare utan flexite-konto kan via länk i e-post logga in med sin e-postadress i kombination med en PIN-kod som skickas till e-postadressen. Denna inloggningsmetod skyddas på liknande vis som enskilda användarkonton, med skillnaden att det i detta fall är e-postadressen som blockeras och inte ett användarkonto.

Utreda och häva blockering

Det är kritiskt att utreda varför en blockering inträffat innan blockeringen hävs.

Vid blockering av enskilda användarkonton och IP-adresser kan blockeringen hävas från flexiteCLIENT.

I det fall webbapplikationen stoppats fullständigt måste den startas upp igen. Notera att webbapplikationen som standard startar automatiskt när tjänsten för Apache Tomcat startas, vilket medför att det inte ska ses som ett beständigt skydd.

Låst användarkonto

Ett användarkonto låses som standard efter att:

• 10 konsekutiva misslyckade inloggningsförsök utförts inom 24 timmar mot ett och samma konto, oavsett från vilken IP-adress som försöken utförs.
• 10 konsekutiva misslyckade inloggningsförsök utförts inom 24 timmar mot ett och samma konto från en enskild IP-adress, oavsett om inloggning lyckats från andra IP-adresser.

Det grundläggande förfarandet är att analysera åtkomstloggar och samtala med användaren för att utreda huruvida det rör sig om en attack, eller om användaren själv stått för de misslyckade inloggningsförsöken:

1. I flexiteCLIENT, ta reda på exakt tidpunkt och orsak för låsning av användarkontot. Under 'Systemaktivitet' visas samtliga låsta användarkonton tillsammans med tidpunkt för låsning. Loggar för flexite brute force-skydd finns att läsa under 'System > Loggar > Åtkomstloggar > Säkerhet'. Låsning av användarkonto loggas på följande vis:

   Användarkonto {användarnamn} har låsts på grund av 10 misslyckade inloggningsförsök inom 86400 sekunder

   • Låsning av användarkonto loggas även i loggfilen för flexiteWEB; C:\tomcat\flexite\log\{date}_flexite.log:

     {timestamp} Account {username} has been locked due to 10 unsuccessful login attempts within 86400 seconds

2. I flexiteCLIENT, navigera till 'System > Loggar > Åtkomstloggar > Användarsessioner' och filtrera loggen på användarnamnet för den blockerade användaren samt datum för låsning.

   • Notera tidpunkter för loggrader för Händelse 'Inloggning misslyckades'.

3. Samtala med användaren om tidpunkterna för de misslyckade inloggningsförsöken.

4. Utifrån insamlad information, bedöm om det rör sig om användarmisstag eller en attack.

   • Om det rör sig om användarmisstag, lås upp kontot under 'Systemaktivitet' alternativt på användarkortet.
   • Om det rör sig om en attack betyder det att användarnamnet hamnat i fel händer. Överväg att byta användarnamn på aktuellt konto, alternativt att inaktivera aktuellt konto och skapa nytt. Starta om flexiteWEB efter utförda åtgärder.

Låst IP-adress

En IP-adress låses som standard efter att 10 misslyckade inloggningsförsök utförts, med ett eller flera användarkonton, inom 60 sekunder från en och samma IP-adress.

Det grundläggande förfarandet är att analysera åtkomstloggar och utreda huruvida det rör sig om en attack, eller om det rör sig om användarmisstag.

1. I flexiteCLIENT, ta reda på exakt tidpunkt för låsning av IP-adressen. Under 'Systemaktivitet' listas samtliga blockerade IP-adresser tillsammans med tidpunkt för låsning. Loggar för flexite brute force-skydd finns att läsa under 'System > Loggar > Åtkomstloggar > Säkerhet'. Låsning av IP-adress logga på följande vis:

   IP-adressen {adress} har låsts på grund av 10 misslyckade inloggningsförsök inom 60 sekunder

   • Låsning av IP-adress loggas även i loggfilen för flexiteWEB; C:\tomcat\flexite\log\{date}_flexite.log:

     {timestamp} IP address {address} has been locked due to 10 unsuccessful login attempts within 60 seconds

2. I flexiteCLIENT, navigera till 'System > Loggar > Åtkomstloggar > Användarsessioner' och filtrera loggen på datum för låsning.

   • Notera tidpunkter, användarnamn samt IP-adresser för loggrader för Händelse 'Inloggning misslyckades'.

3. Om det rör sig om ett fåtal användarkonton, samtala med användarna om tidpunkterna för de misslyckade inloggningsförsöken.

4. Utifrån insamlad information, bedöm om det rör sig om användarmisstag eller en attack.

   • Om det rör sig om användarmisstag, lås upp IP-adressen under 'Systemaktivitet'.
   • Om det inte rör sig om användarmisstag och samtliga försök skett mot samma användarkonto kan det betyda att användarnamnet hamnat i fel händer. Överväg att byta användarnamn på aktuellt konto, alternativt att inaktivera aktuellt konto och skapa nytt, för användaren.
   • Om det inte rör sig om användarmisstag och försöken skett mot flera konton kan det röra sig om en organiserad attack. I dessa fall kan åtkomsten till webbservern som huserar flexiteWEB behöva ses över i driftmiljön.

Låst webbapplikation

Efter att 50 misslyckade inloggningsförsök utförts, med ett eller flera användarkonton, inom 60 sekunder blockeras alla anrop till webbapplikationerna flexiteWEB och flexiteAdmin.

Det grundläggande förfarandet är att analysera åtkomstloggar och utreda huruvida det rör sig om en attack, eller om det rör sig om användarmisstag:

1. I flexiteCLIENT, ta reda på exakt tidpunkt för blockering webbapplikationerna. Loggar för flexite brute force-skydd finns att läsa under 'System > Loggar > Åtkomstloggar > Säkerhet'. Blockering av webbapplikationer loggas på följande vis:

   flexite system har låsts på grund av 50 misslyckade inloggningsförsök inom 60 sekunder

   • Nedstängning av flexiteWEB loggas även i loggfilen för flexiteWEB; C:\tomcat\flexite\log\{date}_flexite.log:

     {timestamp} Flexite system has been locked due to 50 unsuccessful login attempts within 60 seconds

2. I flexiteCLIENT, navigera till 'System > Loggar > Åtkomstloggar > Användarsessioner' och filtrera loggen på datum för nedstängning.

   • Notera tidpunkter, användarnamn samt IP-adresser för loggrader för Händelse 'Inloggning misslyckades'.

3. Utifrån insamlad information, bedöm om det rör sig om användarmisstag eller en attack. Med denna mängd misslyckade inloggningsförsök finns det en risk att det rör sig om en attack, oavsett om försöken utförts från en eller flera IP-adresser.

   • Om samtliga försök skett mot samma användarkonto kan det betyda att användarnamnet hamnat i fel händer. Överväg att byta användarnamn på aktuellt konto, alternativt att inaktivera aktuellt konto och skapa nytt, för användaren.
   • Om försöken skett mot flera konton kan det röra sig om en organiserad attack. I dessa fall bör åtkomsten till webbservern som huserar flexiteWEB ses över i driftmiljön.

4. För att undvika obehörig åtkomst till applikationerna är det rekommenderat att starta om webbapplikationerna först efter åtgärder vidtagits.

Konfiguration

Skydd mot upprepade inloggningsförsök är aktiverad som standard, men det är möjligt att anpassa tröskelvärden i konfigurationsfilerna för respektive applikation.

Bra att veta

Standardvärden är framtagna för att uppnå en balans mellan säkerhet och användarvänlighet. Ändring av dessa värden bör enbart utföras i samråd med Flexite AB efter att en utredning fastställt ett drifttekniskt behov.

Konfigurationsfiler

• flexiteWEB:
  flexiteWEB\WEB-INF\classes\settings\customer.conf
• flexiteAdmin:
  flexiteAdmin\WEB-INF\classes\settings\flexiteAdmin.conf

Attack mot enskilt användarkonto

Inställningar för enskilda användarkonton gäller även för åtkomst via PIN-kod. Ett användarkonto låses efter:

• 10 konsekutiva misslyckade inloggningsförsök inom 24 timmar, oavsett från vilken IP-adress som försöken utförts.
• 10 konsekutiva misslyckade inloggningsförsök inom 24 timmar från en och samma IP-adress, oavsett om inloggning lyckats från andra IP-adresser.

Tiden räknas från första misslyckade försök.

Parameter

login-attempts-account-lock=10,24

Parameter konfigurerad med standardvärden; 10 försök inom 24 timmar.

Om parametern inte är angiven används standardkonfigurationen; 10 försök inom 24 timmar.

Rekommendation

Flexite AB bedömer det som osannolikt att behov uppstår där ändring måste utföras och avråder därmed från att ändra dessa tröskelvärden.

Attacker från enskild IP-adress

Efter 10 misslyckade inloggningsförsök, med ett eller flera användarkonton, inom 60 sekunder från en och samma IP-adress, blockeras IP-adressen från vilken inloggningsförsöken utförts.

Parameter

login-attempts-ip-block=10,60

Parameter konfigurerad med standardvärden; 10 försök inom 60 sekunder.

Om parametern inte är angiven används standardkonfigurationen; 10 försök inom 60 sekunder.

Rekommendation

Vid nyttjande av proxy eller NAT för anslutning till flexiteWEB (där resultatet är att flertalet användare ansluter från samma IP-adress) kan det vara nödvändigt att öka tröskelvärdet för inloggningsförsök för att undvika oönskad blockering vid legitima försök. I de fall där blockering inträffar på grund av legitima inloggningsförsök kan tröskelvärdet för antal försök efter utredning gradvis ökas. Flexite AB bedömer det som osannolikt att behov uppstår där tröskelvärdet för antal försök behöver ökas till mer än 50 (login-attempts-ip-block=50,60).

Om proxy eller NAT inte nyttjas bedömer Flexite AB det som osannolikt att behov uppstår där ändring måste utföras och avråder därmed från att ändra dessa tröskelvärden.

Attacker från flera IP-adresser

Efter 50 misslyckade inloggningsförsök, med ett eller flera användarkonton, inom 60 sekunder stängs webbapplikationerna fullständigt.

Parameter

login-attempts-total-shutdown=50,60

Parameter konfigurerad med standardvärden; 50 försök inom 60 sekunder.

Om parametern inte är angiven används standardkonfigurationen; 50 försök inom 60 sekunder.

Rekommendation

Flexite AB bedömer det som osannolikt att behov uppstår där ändring måste utföras och avråder därmed från att ändra dessa tröskelvärden.

Tjänster — Schemaläggning

Somliga systemtjänster och integrationer kan låsa systemresurser medan de körs och därmed påverka användares arbete i flexite. För att motverka att detta inträffar har flexite stöd för individuell schemaläggning per systemtjänst och integration. Detta innebär att det är möjligt att ange vid vilka tidpunkter och intervall som tjänsterna ska köras.

Notera att denna påverkan är mest märkbar i stora system där tjänsterna hanterar stora mängder information och därmed tar längre tid att utföra.

Systemtjänster som kan påverka arbete i flexite

Följande systemtjänster kan medan de körs påverka användares arbete i flexite:

• Alarm
• Ersättare
• OnHold

Integrationer som kan påverka arbete i flexite

Integrationer är ofta systemspecifika och därmed varierar eventuell systempåverkan beroende på typ av integration och implementation.

Följande standardintegration påverkar absolut användares arbete i flexite:

• Gallring

Rekommendationer

För systemtjänster är det rekommenderat att i stora system med stora mängder data schemalägga dessa tjänster att köras vid unika tidpunkter samt enbart utanför kontorstid. Det är därtill starkt rekommenderat att konfigurera tjänsterna att beräkna tidpunkten för nästa körning utifrån den aktuella tjänstens starttid för att ha större kontroll över tidpunkterna.

För integrationer av typen gallring är det starkt rekommenderat att schemalägga integrationerna vid unika tidpunkter och enbart utanför kontorstid.

Det är även starkt rekommenderat att schemalägga systemtjänster och integrationer utanför eventuella underhållsfönster för IT-miljön.

Automatisk statuskontroll

Systemtjänsterna är konstruerade att rapportera till flexiteProcessEngine en gång per minut. I flexiteCLIENT är det möjligt att per tjänst ange det tidsintervall som en tjänst tillåts inte rapportera in innan den stoppas och sedan startas på nytt vid nästa schemalagda start.

En orsak till att en tjänst inte rapporterar inkan vara att den väntar på svar från en tjänst, webbservice eller DLL-integration.

För tjänster där det är sannolikt att operationer kan ta lång tid utan återkoppling är det rekommenderat att ange ett längre tidsintervall för den automatiska statuskontrollen.

För information om konfiguration av flexiteProcessEngines tjänster i flexiteCLIENT, se avsnitt Konfigurera flexiteProcessEngine.

Återförsök — Systemtjänster

I det fall en systemtjänst av någon anledning inte kan utföra sitt arbete vid schemalagd tidpunkt kommer tjänsten att försöka på nytt så snart det är möjligt. Som standard utförs dessa återförsök tills dess att tjänsten lyckas slutföra sin uppgift.

I det fall nästa körning beräknas från starttid kommer starttiden i detta fall att beräknas från den ursprungliga schemalagda starttiden och inte starttiden för det lyckade återförsöket. Periodiciteten adderas till den ursprungliga starttiden tills dess att en tidpunkt efter aktuell tidpunkt uppnås.

Begränsa tidsspann för återförsök

Det är möjligt att per systemtjänst ange en begränsning i form av ett tidsspann för denna typ av återförsök i konfigurationsfilen för flexiteProcessEngine; flexiteProcessEngine.ini.

Denna begränsning anges per tjänst med följande parameter:

ScheduledServiceTimeout=X

• X — Anger tidsintervall i timmar, räknat från schemalagd tidpunkt, under vilket tjänsten tillåts att göra återförsök. Värdet '0' innebär ingen begränsning av tidsintervall och är standardvärde om inget annat värde anges.

Exempel

[AlarmSvc]
ScheduledServiceTimeout=2
[OnHoldSvc]
ScheduledServiceTimeout=2
[StatisticsSvc]
ScheduledServiceTimeout=0
[DBLinkSvc]
ScheduledServiceTimeout=0
[LeadTimesSvc]
ScheduledServiceTimeout=0
[SubstituteSvc]
ScheduledServiceTimeout=2
[MailSvc]
ScheduledServiceTimeout=0

I exemplet ovan tillåts tjänsterna Alarm (AlarmSvc), OnHold (OnHoldSvc) och Ersättare (SubstituteSvc) utföra återförsök inom 2 timmar från ursprunglig schemalagd tidpunkt (ScheduledServiceTimeout=2).

För övriga tjänster anges ingen begränsning av tidsintervall för återförsök (ScheduledServiceTimeout=0).

Återförsök — Integrationer

Integrationer har en liknande hantering av återförsök som systemtjänster (Återförsök — Systemtjänster). I det fall en integration av någon anledning inte kan utföra sitt arbete vid schemalagd tidpunkt kommer integrationen som standard att försöka på nytt så snart det är möjligt. Som standard utförs dessa återförsök tills dess att tjänsten lyckas slutföra sin uppgift.

Begränsa tidsspann för återförsök

Integrationer hanteras av systemtjänsten DB-link och följer därmed i första hand konfiguration av återförsök för denna tjänst.

Integrationer av typen Gallring

Integrationer av typen Gallring har stöd för att ange under vilka specifika intervall som integrationen INTE ska köras. Denna parameter heter 'Kör inte på' i gränssnittet och möjliggör att ange veckodagar och klockslag för när integrationen inte ska köras.

Med 'Kör inte på' aktiverat tillåts återförsök enbart inom 5 minuter från schemalagd starttid.

Fig.54: Integrationer av typen Gallring har stöd för att ange under vilka tidsintervall integrationen INTE ska köras.