Authenticatie, signing en authorisatie

[pietercolpaert]

Mogelijke te ondersteunen standaarden:

• W3C WebID: https://www.w3.org/wiki/WebID
• OAuth
• HTTP authenicatie
• ...

[koenedaele]

• JSON Web Tokens: https://jwt.io/

[koenedaele]

Voorzien van richtlijnen voor integratie met ACM/IDM

[pietercolpaert]

ACM/IDM ben ikzelf niet vertrouwd mee. Meer informatie op: https://overheid.vlaanderen.be/gebruikersbeheer

[maarten-vermeyen]

• OIDC: (http://openid.net/connect/)

[RubenVerborgh]

+1 to OIDC. OIDC can encompass many other methods.

[CumpsD]

@pietercolpaert ACM/IDM is of SAML of OIDC sinds enige tijd.

[jaanclaeys]

Als we het puur hebben over APIs, ben ik er niet van overtuigd dat zij authenticatie rechtstreeks moeten afhandelen, in wezen moeten zij authoriseren.

OpenID Connect in dat opzicht doet enkel iets voor de client die de API aanspreekt, en de identiteit (identity token) wordt ook aan die client gegeven, die dit verifieert. Dat identity token wordt echter niet doorgegeven (of dat is toch een foute implementatie), maar een OAuth 2.0 accesstoken wordt doorgegeven aan de API, die een scope heeft waarmee de API de persoonsinformatie kan opvragen, en kan verifieren als de persoon consent heeft gegeven voor het gebruik van de client naar de API.
Zie ook:
Why use access tokens to secure APIs

In dat opzicht moet de API enkel OAuth 2.0 implementeren ter verificatie van accesstokens.
De spec zegt dat de API dat token moet verifieren bij een OAuth 2.0 endpoint, en zich ook authenticeren aan de OAuth 2.0 Server. Hoe die authenticatie gebeurt laat de spec vrij, maar hier is het wel aangeraden een sterk protocol met assymetrische encryptie toe te passen.

De vraag is als je al die gaten wel wil invullen als aanbeveling. Mijn minimale aanbeveling zou zijn:

• Gebruik OAuth 2.0 access tokens om je gebruiker en client te autoriseren aan de API kant.

[jaanclaeys]

Wat betreft WebID vind ik dit een heel mooi protocol, echter is er al lang een draft, en is er geen ondersteuning. Het brengt ook wat praktische problemen met zich mee voor de doorsnee gebruiker (certificaten veilig bewaren, aanmaken, transporteren, backup, ... )
Het leunt sterk aan bij een soort blockchain implementatie van identiteit.
Ik denk dat we nood hebben aan dit soort protocol, waarbij andere mensen, organisaties, overheden identiteiten kunnen verifieren.

Echter moeten de facebooks, googles, microsofts hierin eerst overtuigd worden, alsmede overheden e.d. anders zal dit er nooit van komen.

[RubenVerborgh]

Wat betreft WebID vind ik dit een heel mooi protocol

Opgepast, er is een verschil tussen:

• WebID (een dereferenceable URL hebben die je identificeert)
• WebID-TLS (client-certificaten gebruiken om je aan te melden met je WebID)
• WebID-OIDC (client-certificaten gebruiken om je aan te melden met je WebID)

Het leunt sterk aan bij een soort blockchain implementatie van identiteit.

Niet echt.

Ik denk dat we nood hebben aan dit soort protocol, waarbij andere mensen, organisaties, overheden identiteiten kunnen verifieren.

OIDC (OpenID Connect) is hier een goede kandidaat voor, omdat het als wrapper-protocol kan gebruikt worden rond andere zaken (gebruikersnaam/wachtwoord, vingerafdruk, client-certificaten, …)

[jaanclaeys]

Niet echt.

Het is idd wat kort door de bocht, maar het gedistribueerde aspect ervan lijkt me een kandidaat. Stel dat het leggen van die FOAF relaties transactioneel laten verlopen en die laten valideren door de community kom je ergens in de buurt.

OIDC (OpenID Connect) is hier een goede kandidaat voor, omdat het als wrapper-protocol kan gebruikt worden rond andere zaken (gebruikersnaam/wachtwoord, vingerafdruk, client-certificaten, …)

Ik bedoel eigenlijk een digitale identiteit die gedistribueerd geverifieerd is, OpenID Connect ongeacht de credential heeft één autoriteit. Ik denk dat die WebID dat beter doet omdat je zelf je identiteit creëert, en er met die FOAF relaties worden gelegd tussen andere identiteiten. Ik ken persoonlijk geen protocol die identiteit semantisch benadert (WebID en FOAF), en tegelijkertijd gedistribueerd geverifieerd (namecoin) kan worden. Dat lijkt me nuttig, maar meer iets voor de toekomst.

Ik denk ook wel dat OIDC momenteel het geschikte protocol is voor authenticatie van eindgebruikers aan de client kant van de APIs. Mijn bemerking is echter dat je onderscheid moet maken met wat de APIs moeten implementeren, en dat is niet het OIDC protocol, maar het achterliggende OAuth 2.0 protocol.

Ik denk op niveau van de Vlaamse Overheid dat we daar momenteel geen geschikte oplossing hebben. We hebben een OAuth 2.0 server, en een OIDC server maar die zijn niet gelinkt en liggen bij verschillende entiteiten. Dat is dus een To-Be verhaal dat we momenteel vanuit GeoSecure (OAuth 2.0), samen met ACM/IDM (OIDC) moeten oplossen.
Bijgevolg krijg je rare API integraties, waarbij Identity Tokens worden doorgegeven aan APIs, en de API daar bovenop ook nog eens OAuth 2.0 accesstokens verifieert voor B2B integraties.
Momenteel dus een beetje een rommelboeltje.

Informatie voor clients voor de OAuth 2.0 server van GeoSecure kan je hier vinden.

Om dus een perfecte werkbare bouwsteen te kunnen aanbieden voor de API is er nog wat werk aan de winkel.

[RubenVerborgh]

Ik bedoel eigenlijk een digitale identiteit die gedistribueerd geverifieerd is, OpenID Connect ongeacht de credential heeft één autoriteit.

Niet noodzakelijk. Met WebID+OIDC kan je in je WebID een lijst aangeven van identity providers die je toestemming geeft om je als die WebID te authenticeren.

[jaanclaeys]

Niet noodzakelijk. Met WebID+OIDC kan je in je WebID een lijst aangeven van identity providers die je toestemming geeft om je als die WebID te authenticeren.

Ah, dat is inderdaad een mooie manier van werken.

@RubenVerborgh Heb je het over deze github? https://github.com/solid/webid-oidc-spec

[RubenVerborgh]

Inderdaad, en specifiek dit mechanisme: https://github.com/solid/webid-oidc-spec#issuer-discovery-from-webid-profile

[jaanclaeys]

Er is blijkbaar recent een nieuwe spec verschenen voor public services, igov en openid-connect en oauth 2.0. Bij een eerste diagonale lezing doen ze wat zaken strenger.

• Geen public clients, geen simple grant.
• Iedere client moet authenticeren met JWT en private key / public key
• Dynamische registratie van clients mogelijk, waarbij het mogelijk is voor iedere device een nieuwe clientId te krijgen

OpenID Connect iGov spec

en de onderliggende
OAuth 2.0 iGov spec

Misschien is dit wel een om naar toe te werken in ons geval.

[jensscheerlinck]

Ik kwam net deze working draft tegen:
https://opencreds.org/specs/source/identity-credentials/

Waarschijnlijk nog te experimenteel om meteen iets mee te doen.

This specification describes how to express a digital identity and a collection of digital credentials that assert claims about that identity. It also describes a set of mechanisms for issuing and requesting credentials.

This is an experimental specification that is attempting to unify the work performed in the Credentials Community Group, the Web Payments Community Group, the Linked Data community, the WebID Community Group, and the Mozilla Persona team. As such, the specification borrows a number of concepts from each group. It attempts to synthesize these concepts into a comprehensive solution that can be easily implemented and deployed by Web developers in order to help foster a rich ecosystem of digital identities and credentials on the Web.

[jensscheerlinck]

Dit werk lijkt ook relevant:

https://www.w3.org/wiki/WebAccessControl

Besluit op vorige werkgroepsessie (22/06/2018) was om de boublok rond authenticatie voorlopig out of scope te laten en te bekijken of hier een afzonderlijk traject rond kan worden opgestart.

[RubenVerborgh]

Authorisatie met WebACL wordt onder andere gebruikt in Solid.