Tjänsteplattform Tekniska krav ARK_0034
| RIV Tekniska AnvisningarParallella huvudversioner av ett tjänstekontraktVersion 1. 50 ARK_0040 2017-02-17 |
| Innehållsförteckning |
|---|
Versionshistorik | |||
Version | Revision Datum | Författare | Kommentar |
PA1 | Mattias Nordvall | Första utkast | |
PA2 | Mattias Nordvall | Uppdaterat efter intern remiss | |
PA3 | Lars Erik Röjerås | Justeringar efter genomläsning | |
1.0 | Mattias Nordvall | Dokumentets underrubrik är nu ”Tekniska krav” istället för ”Regler för interoperabilitet”. Lagt till kapitel med definition av termer. Tagit bort texter om reverse proxy (betraktas som implementationsdetalj). Lagt till felkoder för virtualiseringsplattform. Tagit bort regel om loggning av förändringar av TAK-information (inte ett tekniskt krav). Tagit bort skrivning om godkännande av tjänstekontrakt i 3.1.1 (inte ett tekniskt krav). Ändrat regel om uppbyggnad av URL:er till att enbart beskriva slutet på adresserna (det enda som är reglerat i RIV TA). Förtydligat att anropsbehörighet i TAK avser närmast anropande tjänstekonsument. Kapitlet om TAK använde begreppet ”logisk adress” om två olika saker. Lagt till översiktligt kapitel om Tjänsteväxel. Korrigerat ordval och stavfel. Uppdaterade illustrationer. | |
1.0.1 | Mattias Nordvall | Korrigerat vissa formuleringar och illustrationer. Nytt stycke om förhållandet mellan nationella och regionala tjänsteplattformar. | |
1.1 | Mattias Nordvall | Kapitlet om anpassningsplattform och tjänsteväxel omskrivet och felaktigheter korrigerade. Regel ”Exponering av URL:er” i kapitel 4 korrigerad för att överensstämma med underliggande regelverk. Exempel från den senaste versionen av RIV-TA Basic Profile, t.ex. SOAP Headers, är ändrade till mer generella begrepp | |
1.2 | Mattias Nordvall | Lagt till regler i kapitel 4 från RIV TA Basic Profile 2.0. Dessa regler behöver följas av tjänsteplattformar. Lagt till Regel #6 under kapitlet Aggregeringsplattform. | |
1.3 | Mattias Nordvall | Uppdaterat Regel #6 under kapitlet Aggregeringsplattform. | |
| 1.4 | 2017-12-07 | Björn Hedman | Lagt till information om adressering baserat på TAK och organisationsdata "HSA klättring" Under rubrik 4.2.6 har görs hänvisning till Basic Profile istället för att beskriva och exemplifiera i detta dokument Rättat numrering av regler under kapitel 5.1 (Virtualiseringsplattform) felet uppstod mellan version 1.0 och 1.1 (några regler utgick i 1.1) Tagit bort hänvisning till fallstudie för "Regional tjänsteplattform, Landstinget Dalarna" eftersom länken var bruten. |
| 1.5 | 2018-08-27 | Lars Erik Röjerås | Reglerna 2 och 4 har utökats med beskrivning av HSA-baserat vägval och anropsbehörighet samt användning av "*". |
...
Åtkomstbesluten skall baseras på information som lagras i tjänsteadresseringskatalogen. Om åtkomst inte tillåts skall den inkommande förfrågan inte vidarebefordras. Istället skall ett felmeddelande returneras, enligt aktuell RIV TA-profil.
Källa: [R2] Kapitel 8.5
Deaktiverad åtkomstkontroll. Om den logiska adressen "*" ingår i definitionen av en åtkomstbehörighet för tjänstekonsument i en tjänsteplattforms tjänsteadresseringskatalog innebär det att kontrollen skall deaktiveras för aktuellt tjänstekontrakt och tjänstekonsument, och att tjänstekonsumenten ska ha behörighet att anropa oberoende av den logiska adressen i själva meddelandet.
Åtkomstkontroll via hierarkisk organisationsinformation. De logiska adresserna består i de flesta fall av ett HSA-id som representerar en verksamhet eller organisation (källsystemsbaserade logiska adresser berörs inte av denna metod för åtkomstkontroll). Genom att tillföra information till VP om det hierarkiska sambanden mellan logiska adresser (ex via en fil över organisationsträdet i HSA) skapas möjligheten att utföra åtkomstkontroll via en överliggande adress i hierarkin. I de fall där kontrollen av åtkomstkontroll för explicit angiven logisk adress misslyckas så hämtar VP närmast överliggande logiska adress i hierarkin och prövar om den har åtkomstbehörighet. Denna klättring och försök fortsätter tills endera:
- En åtkomstbehörighet hittas - vilket innebär att anropet får åtkomstbehörighet
- Toppen nås i organisationsträdet (utan att åtkomstbehörighet har tilldelats)
Roten i organisationshierarkin består definitionsmässigt av den logiska adressen "SE". Se mer information i separat dokumentation kring modellen [R9].
Källa: [R2] Kapitel 8.7
Regel #3: Utgått
Regel #4: Vägval för anrop
...
- meddelandets logiska mottagaradress
- anropat tjänstekontrakt, inkl. tjänstedomän och kontraktets huvudversion
- anropad RIVTA-profilversion
Vägval via hierarkisk organisationsinformation. De logiska adresserna består i de flesta fall av ett HSA-id som representerar en verksamhet eller organisation (källsystemsbaserade logiska adresser berörs inte av denna metod för åtkomstkontroll). Genom att tillföra information till VP om det hierarkiska sambanden mellan logiska adresser (ex via en fil över organisationsträdet i HSA) skapas möjligheten att definiera vägval via en överliggande adress i hierarkin. I de fall där inget explicit vägval hittas så hämtar VP närmast överliggande logiska adress i hierarkin och prövar om den har vägval definierat. Denna klättring och försök fortsätter till endera:
- Ett vägval hittas - vilket innebär att detta vägval används för aktuellt meddelande
- Toppen i hierarkin nås utan att ett vägval hittats - kontroll ska då ske om ett standardval är definierat, se nedan.
Roten i organisationshierarkin består definitionsmässigt av den logiska adressen "SE". Se mer information i separat dokumentation kring modellen [R9].
Standardval. Om den logiska adressen asterisk ("*") ingår i definition av ett vägval så innebär det att detta vägval är standardval (default) för tjänstekontraktet. Om den logiska adressen i en begäran inte återfinns i något vägval enligt metoderna ovan skall vägvalet med logisk adress "*" användas (om ett sådant finns).
Källa: [R2] Kapitel 8.6
Regel #5: Vidarebefordran av anrop
...