Loading…
Tilbage
×

Info

Der findes en nyere version af resourcen her

OIOSAML Profil version 2.0.6


 

SAML 2.0 er en teknisk standard, der beskriver hvordan IT systemer kan udveksle oplysninger om en bruger. Standarden gør det muligt at koble IT systemer fra forskellige organisationer sammen på nye måder, hvilket skaber sammenhæng og mulighed for nye, digitale services. Endvidere opnås en forbedret brugeroplevelse, idet brugerne ikke konstant vil skulle logge sig på systemerne.

OIO Web SSO Profile (OIOSAML) 2.0 er en dansk specialisering (profil) af SAML, som beskriver hvorledes standarden skal anvendes i dansk sammenhæng - herunder hvordan f.eks. CVR og CPR numre kan anvendes til at identificere virksomheder, borgere og medarbejdere.

OIOSAML 2.0 har status af ”anbefalet” i OIO kataloget.

Denne version 2.0.6 af profilen er opdateret med præciseringer og mindre fejlrettelser. De konkrete rettelser er angivet i Document History i starten af dokumentet. OIOSAML 2.0.6 erstatter den hidtidigt gældende version 2.0.5

 

Filer og referencer

Titel Type
oiosaml-2.0.6.pdf pdf
[slettet indlaeg]

OIOSAML-profilen muliggør, men foreskriver ikke, brug af OCES. Profilen giver også mulighed for at den eneste information, som overføres om brugeren, kan være et meningsløst pseudonym. Dette pseudonym vil være forskelligt i forhold de forskellige serviceudbydere.

Det er korrekt at den arkitektur, som benyttes i forbindelse med SAML forudsætter at Serviceudbyder har tillid til den Identity Provider, som på basis af autenticitetssikring af brugeren udsteder en assertion til serviceudbyderen herom.

Et basalt spørgsmål er om man kan stole på tredjeparter eller om al digital interaktion, hvor brugere kan identificeres, altid skal være bilateral uden anvendelse af intermediære og tredjeparter.

I forbindelse med det fællesoffentlige brugerstyringsarbejde antager vi at tillid til tredjeparter kan etableres via opstilling af en række aftalevilkår, og revision of hvorvidt disse aftalevilkår overholdes.

Jeg har noteret mig din kritik heraf, men ser ikke det forhold ændre sig på den korte bane. Jeg ser det i mange situationer heller ikke ændre sig på den længere bane - fordi der simpelt hen er god mening i at lade nogen, der har gjort det til deres kerneopgave, håndtere en række opgaver man ikke selv er klædt på til/ønsker at udføre.

Jeg vil dog gerne diskutere muligheder for at en fremtidig arkitektur kan udvides med ekstra services til brugere og løsninger, der ønsker større grad af anonymitet overfor serviceudbyder uden involvering af tredjepart i deres transaktioner – og i forhold til infrastrukturen iøvrigt. Det vil blandt andet kræve at der er en metode, som er skalerbar – mht, teknologi, brugervenlighed, og økonomi - til sikring af anonymitet uden opgivelse af ansvarlighed.

Du er meget velkommen til at kontakte mig med henblik på et møde hvor konkrete løsningsmuligheder kan diskuteres.

Profilbillede

UserCertificate mandatory

Peter Buus


Vi har udviklet en række securityprovidere til .Net, php og en række javabaserede applikationsservere der håndterer et lokalt OCES logon.


Det vil være nemt for os at genbruge centrale dele heraf, hvis UserCertificate (urn:oid:1.3.6.1.4.1.1466.115.121.1.8) var tilgængeligt (=mandatory). Vores kunder ønsker under alle omstændigheder lokal OCES validering ifbm aftale signering og der er også ønske om at falde tilbage til lokal logon hvis den centrale NemLogin server er utilgængelig.


Vi foreslår derfor derfor at UserCertificate ophøjes til en mandatory attribut i OIOSAML profilen.


 


 


 


 


Hej Peter,

Da vi lavede OCES attribut-profilen var der en del overvejelser mellem at sende relevante OCES attributter, som vi gør i dag og/eller at sende hele certifikatet.

Det betyder en hel del for SAML tokenets størrelse at inkludere userCertificate, og vi har set i ihvertfald et tilfælde at en performanceudfordring gik væk hvis userCertificate blev fjernet fra tokenet. I de integrationscases der blev diskuteret skulle man alligevel blot bruge de attributer, som vi sender i "færdig-parsede" - så det er baggrunden for at userCertificate ikke er mandatory.

Jeg kan godt se at når I har eksisterende kode, der som input tager et helt certifikat, så vil det være nemmere at integrere hvis I kan få hele certifikatet i hånden.

En måde at løse dette på kunne være at I efter at have modtaget brugerens SAML assertion så lavede en AttributeQuery mod IdP'en og så fik suppleret med brugerens userCertificate. I får jeres certifikat - og vi undgår at SAML tokenet generelt skal bære hele certifikatet med.

Jeg skal skynde mig at sige at denne attribut ikke er tilgængelig fra Nemlog-in i dag til attributopslag, men hvis det er en mulighed, som kan spare jer for noget arbejde er I velkomne til at gå i nærmere dialog om dette.

 

/Søren P

 

Hej Søren, tak for svaret

Jeg er ikke den store SAML 2 trold, men er det ikke sådan at IDP'en kun pakker de attributter som SP'en har bestilt i <RequestedAttributes> i SP metadata? Og evt performance udfordringer med userCertificate kun rammer de SP'er der har bestilt userCertificate?

Betyder mandatory ikke kun at en IDP skal pakke en attribut med på opfordring - eller betyder det at IDP altid skal pakke attributten med?

Hvis det er en mulighed med et efterfølgende AttributeQueryRequest er vi liebhavere til den funktionalitet, da det vil spare os for meget arbejde og give os mulighed for en mindre kodebase. Kan du sige noget om mulighed og tidsramme for den udvidelse?

 

 

Hej igen Peter,

Hvis en attribut er mandatory inden for en given attributprofil, skal en IdP altid sende den når Service Provideren har valgt at anvende den givne attributprofil.


På den måde sikres at service providerne ved hvad de har at gøre godt med i et fler-IdP scenarie, samtidig med at IdP'erne kan lave en mere ensartet konfiguration af de service providere, der tilsluttes.


Så det er rigtigt at SP'en i SAML 2.0 metadata-filen kan udpege de attributter man er interesseret, men man kan på føderationsniveau godt vælge at spare på administrationsomkostningerne ved ikke at understøtte alt hvad standarden giver mulighed for.
Om NemLog-in kan tilrettes til at levere userCertificate via en AttributeQueryRequest vil bl.a. afhænge af hvor mange der vil have fordel af denne funktionalitet, hvad det koster at implementere den, og hvordan det finansieres...
Jeg tager fat i dig off-line med info om hvordan I kan komme videre med jeres forespørgsel.

/Søren P

Profilbillede

Ændringer i OIOSAML 2.0.6

Søren Peter Nielsen

Følgende er ændret i OIOSAML 2.0.6


  • The NotBefore attribute on the Conditions element has been allowed to be present but is not required to be processed by receivers.

  • Requirements for NameIDMappingService and ManageNameIDMappingService  meta data have been removed as these services are no longer used by the profile.

  • The Format qualifier is now explicitly allowed on the Issuer element. The NameQualifier and SPNameQualifier are allowed when using persistent pseudonyms.

  • A name convention for representing OCES subjects as strings has been added to section 8.1.1.

  • To support consistent naming in the Danish standards portfolio the short name for this profile has been changed from DK-SAML 2.0 to OIOSAML 2.0.

  • Updated language in sections 1.3 and 7.4 concerning Sector-specific attributes to clarify that while Sector or IdP specific attributes must be made available via attribute query when other IdP’s are used as well, it is allowed to include the attributes in authentication assertions as well.

  • Section 11.2 “Convention for naming Entity Identifier” has been amended with guidelines for naming Entity Identifiers when an organisation has multiple SAML installations within the same domain.

  • Section 11.4.1 "Exchanging meta data" has been amended with information pulled from the OASIS standard that entities MAY publish their metadata documents at the location denoted by its unique identifier, which MUST be in the form of a URL

  • Section 7.3.6 - Representation of Friendly Name has been added to example for Uid attribute

 

 

 


 

 

ændret af Søren Peter Nielsen (27.03.2009)