TLS og mTLS

Adgangen til Keycloak sker udelukkende via enten TLS eller mTLS. Server certifikaterne udstedes af generelt trustede CA'er som anvendes i NSP.

Validering af mTLS klientcertifikater

Opgaven med at validerer mTLS klientcertifikater er delt mellem NGINX (se diagram nedenfor) og Keycloak.




Validering af trust i NSP Netværkskomponenten

NGINX terminerer TLS forbindelse. Dette betyder at server certifikatet er installeret i denne komponent.

Der laves optionelt klient autentifikation hvis klienten sender certifikater med ved etablering at TLS forbindelsen. NGINX verificerer at klient certifikatet er trusted. Trust er konfigureret med OCES3 Rod certifikatet (produktion eller test) og det forventes at klienten medsender intermediate (udstedende) CA certifikat sammen med klient certifikatet. Hvis der ikke medsendes intermediate certifikat så der kan etableres en trusted kæde til rod CA'en skal NSP Netværkskomponenten afvise klienten.

Hvis der etables en mTLS forbindelse med et trusted klientcertifikat, indsætter NSP Netværkskomponenten klientcertifikatet som http headers i request til Keycloak. Navngivning af denne header er gjort i både NSP Netværkskomponentens konfigurationen og i konfigurationen af Keycloak.

Validering i Keycloak

Når en request skal autoriseres via klientcertifikater i Keycloak gøres det på følgende vis:

OCES 3 mTLS klientcertifikater

Klientcertifikater skal være OCES3 certifikater. 

Format af Subject på mTLS klientcertifikater

Ved registrering af klienter skal certifikat subject dn angives i format som specificeret i RFC4514 (se https://datatracker.ietf.org/doc/html/rfc8705#section-2.1.2).

Dette er beklageligvis ikke det format som vises af f.eks. openssl. Eksempelvis vises subject dn for et OCES 3 test certifikat som følgende tekst streng af openssl's x509 kommando:

openssl x509 -in system-1.crt -subject -nocert

subject=CN=System 1, serialNumber=UI:DK-O:G:7bd0d84a-c1f3-4650-a351-4235c482ebeb, O=Testorganisation nr. 96024140, organizationIdentifier=NTRDK-96024140, C=DK

Den korrekte repræsentation af dette DN er jf. RFC4514 :

C=DK,2.5.4.97=#0c0e4e5452444b2d3936303234313430,O=Testorganisation nr. 96024140,2.5.4.5=#132e55493a444b2d4f3a473a37626430643834612d633166332d343635302d613335312d343233356334383265626562,CN=System 1

Keycloak benytter Java metoden

X509Certificate.getSubjectX500Principal().getName(X500Principal.RFC2253, CUSTOM_OIDS)

hvor 

Map<String, String> CUSTOM_OIDS = new HashMap<>();
CUSTOM_OIDS.put("2.5.4.5", "serialNumber".toUpperCase());
CUSTOM_OIDS.put("2.5.4.15", "businessCategory".toUpperCase());
CUSTOM_OIDS.put("1.3.6.1.4.1.311.60.2.1.3", "jurisdictionCountryName".toUpperCase());
CUSTOM_OIDS.put("1.2.840.113549.1.9.1", "emailAddress".toUpperCase());

til at finde en streng repræsentation af det anvendte klientcertifikat og benytter denne streng til at verificerer den specificerede tls_client_auth_subject_dn i metadata. 

Det betyder at Subject (fra openssl) 

CN=System 1, serialNumber=UI:DK-O:G:7bd0d84a-c1f3-4650-a351-4235c482ebeb, O=Testorganisation nr. 96024140, organizationIdentifier=NTRDK-96024140, C=DK

Skal angives i metadata filerne med følgende værdi:

"tls_client_auth_subject_dn": "C=DK,2.5.4.97=#0c0e4e5452444b2d3936303234313430,O=Testorganisation nr. 96024140,SERIALNUMBER=UI:DK-O:G:7bd0d84a-c1f3-4650-a351-4235c482ebeb,CN=System 1"

Forskellen er