search

swedenconnect / technical-framework

Technical Specifications for the Swedish eID Framework
28 stars 3 forks source link

Make RequesterID RECOMMENDED for Identity Providers #182

Open magnussuther opened 2 years ago

magnussuther commented 2 years ago

Ang "Tekniska anslutningsregler.md" (https://github.com/swedenconnect/technical-framework/pull/181)

Avsnitt 2.1 anger att "Visningsnamn och logotyp för den förlitande parten skall hämtas från den förlitande partens metadatapost". I fallet underskrifter är det alltså den logiska instansen av kundens Underskriftstjänst som är "förlitande part".

Avsnitt 7.1 i "02 - Deployment Profile for the Swedish eID Framework.md" anger angående Scoping/RequesterID att "The reason for this recommendation is that an Identity Provider may adapt user interfaces or authentication procedures to different Service Providers based on either static configuration or on information found in the Service Provider's metadata".

Knowits (fd. Cybercom) IdP:er använder sedan en tid tillbaka Scoping/RequesterID för att rendera GUI (från SP-metadata), samt välja rätt RP-cert för de olika kunderna. Om inte Scoping/RequesterID är definierat, eller inte identifierar en SP i federationen (hittas inte), så görs det fallback till Issuerns metadata, dvs DSS:ens.

Tekniskt Ramverk har inte så mycket att säga om Scoping/RequesterID, tyvärr. Det är RECOMMENDED att DSS:en skickar Scoping/RequesterID till IdP:n, men det är inte ens formulerat som ett förslag att IdP:n ska använda detta till något. Det är ett "may".

Avsnitt 2.1 i "Tekniska anslutningsregler.md" blir en smula otympligt i fallet där en kund ansluter olika Service Providers för underskrift, och förväntar sig olika GUI och RP-cert. Om vi tar ett aktuellt case. Bolagsverket bygger "Mina ombud". Likt Verksamt så är detta ett samarbetsprojekt mellan flera myndigheter, men det är Bolagsverket som representerar Underskriftstjänstens existens i Sweden Connect. Så som övriga IdP:er i SC fungerar idag (i enlighet med 2.1), så måste vi som leverantör göra oss besväret att sätta upp en helt ny DSS-instans för "Mina ombud", i det enda syftet att användarna ska få rätt logotyp och displayname vid underskrift med Freja eller eIDAS-connectorn. Någon annan teknisk anledning finns inte, som jag ser det. Kanske juridisk eller filosofisk, men inte teknisk. Både Verksamt och Mina ombud borde kunna använda Bolagsverkets befintliga DSS-instans, men det faller på detta.

Mitt förslag och önskan är att Tekniskt Ramverk gör det RECOMMENDED att en IdP ska rendera GUI och välja RP-cert utifrån den SP som anges i Scoping/RequesterID i första hand, med fallback till DSS:ens (Issuerns) metadata.

martin-lindstrom commented 2 years ago

Nja. Jag tycker att man ska lösa problemen på rätt sätt. I ditt exempel med "Mina ombud" så anser jag att det bör finnas en dedikerad SP (signservice-instans) för just detta syfte. Och det kan väl ändå inte vara det enda syftet med att få en tydlig uppdelning i en underskriftstjänst? Spårbarhet och en allmän uppdelning mellan olika användningsområden är snarare allmän hygien.

Jag säger inte emot dig kring RequesterID, men det är lite vanskligt att bli för "komplicerad" i de tekniska specarna. Målsättningen är ju att hyllprodukter, med rimliga anpassningar, ska kunna uppfylla tekniskt ramverk.

Jag skulle kunna tänka mig att ditt förslag om "recommended" gäller för anrop från underskriftstjänster. Synd bara att detta kom in precis när den nya versionen precis har spikats. Även om de tekniska anslutningsreglerna är mer rörliga så är ju kravet egentligen formulerat i tekniskt ramverk.

magnussuther commented 2 years ago

Min poäng var att det bara skulle behövas en DSS-instans per myndighet/kund, om inte kunden begär av leverantören att fler instanser sätts upp av skäl som "separation of concerns" eller dylikt. Då minskar man komplexiteten för alla parter.

Spårbarhet har man ju ändå i form av loggar. Underlag för (intern-)fakturering (om det är olika konstnadsställen bakom e-tjänsterna) löser man med leverantörens transaktionsloggar och månadsrapporter, där det framgår antalet underskrifter för varje SP (RequesterID). Och samma siffror bör finnas i respektive SP också.

Om jag ska signera en bygglovsansökan, så kanske det är lämpligare att det står "Stadsbyggnadsnämndens e-tjänst för bygglov" som displayName (eller description), istället för "Grönköpings underskriftstjänst" eller bara "Grönköpings kommun". Inte bästa exemplet kanske, men högre kvalite blir det inte såhär på en måndagkväll.

Aja, egentligen ville jag mest bara lyfta frågan, eftersom det finns en fin mekanism i RequesterID som man skulle kunna förorda, och Avsnitt 2.1 litegrann krockar med detta.

martin-lindstrom commented 2 years ago

Men en instans av en underskriftstjänst kan ju ha flera SAML-SP:ar i sig. Jag förstår vad du är ute efter, men det behöver inte nödvändigtvis vara en ändring i Tekniskt ramverk som löser de specifika problemen (jag säger inte heller att vi inte bör överväga dina förslag).

Personligen så skulle jag nog se över designen för er underskriftstjänst och där tydligt separera olika kunder till en och samma underskriftsinstans som separata SP:ar. Det var vår grundinställning när vi designade fristående underskrifts-konceptet. SP:n är ju den del som frontar IdP:erna och "it makes sense" att man då har en egen entitet och inte försöker trolla med RequesterID (vilket får sägas höra till SAML-överkurs).