12:22 p.m.
Hello Keycloak developers,
I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During the login
we match the authentication certificate's subjectDN against the value stored in the
user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()
Here we have a problem regarding the subject DN order. We realized that the subject DN
order is security provider specific:
· Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=example.com,
ST=California, C=US"
· Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen
III,E=bjensen(a)example.com"
This is obviously a problem.
Does anybody else ran into the same problem?
In my opinion it would be better to use:
cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
What is your opinion?
Best regards
Sebastian
--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany
Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: Sebastian.Loesch@governikus.de<mailto:Sebastian.Loesch@governikus.de>
www.governikus.de<http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Geschäftsführer: Dr. Stephan Klein
Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359
Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg -
Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 |
Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>
[cid:image8a82cf.JPG@26f9b88d.448c29be]<http://www.jahrestagung.governikus.de/>
12:51 p.m.
Hi Sebastian,
how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.
Cheers,
Thomas
Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de>:
Hello Keycloak developers,
I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During
the login we match the authentication certificate's subjectDN against the
value stored in the user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()
Here we have a problem regarding the subject DN order. We realized that
the subject DN order is security provider specific:
· Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=
example.com, ST=California, C=US"
· Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
bjensen(a)example.com"
This is obviously a problem.
Does anybody else ran into the same problem?
In my opinion it would be better to use:
cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
What is your opinion?
Best regards
Sebastian
--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany
Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: Sebastian.Loesch(a)governikus.de<mailto:
Sebastian.Loesch(a)governikus.de>
www.governikus.de<http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Geschäftsführer: Dr. Stephan Klein
Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
Hochschulring 4, 28359 Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
>
Digitaler Staat | 02. + 03.04.2019 | Berlin<
https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/
>
[cid:image8a82cf.JPG@26f9b88d.448c29be]<
http://www.jahrestagung.governikus.de/>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1 p.m.
Hello Thomas,
sounds good. Would you be happy, if I provide a pull request fort that? It seem’s not a
big thing to implement.
Best regards,
Sebastian
Von: Thomas Darimont <thomas.darimont(a)googlemail.com>
Gesendet: Dienstag, 12. Februar 2019 12:52
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
Hi Sebastian,
how about Keycloak would introduce an option for this authenticator like: "Use
canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use the
"canonical" option for extracting the subject as you suggested.
Cheers,
Thomas
Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian
<Sebastian.Loesch(a)governikus.de <mailto:Sebastian.Loesch@governikus.de> >:
Hello Keycloak developers,
I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During the login
we match the authentication certificate's subjectDN against the value stored in the
user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()
Here we have a problem regarding the subject DN order. We realized that the subject DN
order is security provider specific:
· Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen(a)example.com <mailto:bjensen@example.com> , CN=Ms. Barbara
J Jensen III, O=example.com <http://example.com> , ST=California, C=US"
· Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com <http://example.com> ,CN=Ms. Barbara J Jensen
III,E=bjensen(a)example.com <mailto:bjensen@example.com> "
This is obviously a problem.
Does anybody else ran into the same problem?
In my opinion it would be better to use:
cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
What is your opinion?
Best regards
Sebastian
--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany
Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: Sebastian.Loesch(a)governikus.de <mailto:Sebastian.Loesch@governikus.de>
<mailto:Sebastian.Loesch@governikus.de <mailto:Sebastian.Loesch@governikus.de>
>
www.governikus.de <http://www.governikus.de> <http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Geschäftsführer: Dr. Stephan Klein
Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359
Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg -
Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 |
Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>
[cid:image8a82cf.JPG@26f9b88d.448c29be]<http://www.jahrestagung.governikus.de/>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:19 p.m.
IIRC, email address should be included/parsed as a subject alternative name
extension. BouncyCastle seems doing it right.
What is the JDK version being used?
On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
Hi Sebastian,
how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.
Cheers,
Thomas
Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de>:
> Hello Keycloak developers,
>
> I am currently working on configuring keycloak for X.509 certificate
login.
> We store the whole user certificate's subject DN as user attribute.
During
> the login we match the authentication certificate's subjectDN against the
> value stored in the user attributes.
> The subject DN is determined executing:
> cert.getSubjectDN().getName()
>
> Here we have a problem regarding the subject DN order. We realized that
> the subject DN order is security provider specific:
>
> · Using SUN security provider we get a subject DN like:
> "EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=
> example.com, ST=California, C=US"
>
> · Using BouncyCastle security provider we get a subject DN like:
> "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> bjensen(a)example.com"
> This is obviously a problem.
> Does anybody else ran into the same problem?
>
> In my opinion it would be better to use:
>
> cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> to determine the subject DN, as the result is provider independent.
> But this would be an backward incompatible change in Method
>
>
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>
> What is your opinion?
>
> Best regards
> Sebastian
>
> --
> Solution Engineering
> --
> Governikus GmbH & Co. KG
> Hochschulring 4
> 28359 Bremen, Germany
>
> Phone: +49 421 204 95 - 28
> Fax: +49 421 204 95 - 11
> E-Mail: Sebastian.Loesch(a)governikus.de<mailto:
> Sebastian.Loesch(a)governikus.de>
> www.governikus.de<http://www.governikus.de/>
> --
> Governikus GmbH & Co. KG
> Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> 22041
> Geschäftsführer: Dr. Stephan Klein
>
> Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
> Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns...
> Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
>
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
> >
> Digitaler Staat | 02. + 03.04.2019 | Berlin<
> https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> https://www.zukunftskongress.info/de>
> Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<
https://www.bw-4-0.de/
> >
>
> [cid:image8a82cf.JPG@26f9b88d.448c29be]<
> http://www.jahrestagung.governikus.de/>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:23 p.m.
Btw, we also support extracting email using a subject alt name extension.
Maybe we could safely use CANONICAL (which seems to be more aligned with
the specs) and tell people to use this extractor if they want to use email
address from certificates.
On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva(a)redhat.com> wrote:
IIRC, email address should be included/parsed as a subject
alternative
name extension. BouncyCastle seems doing it right.
What is the JDK version being used?
On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
> Hi Sebastian,
>
> how about Keycloak would introduce an option for this authenticator like:
> "Use canonical principal extraction" on/off with default "off",
> meaning the default behavior stays the same. "on" would then mean to use
> the "canonical" option for extracting the subject as you suggested.
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
> Sebastian.Loesch(a)governikus.de>:
>
> > Hello Keycloak developers,
> >
> > I am currently working on configuring keycloak for X.509 certificate
> login.
> > We store the whole user certificate's subject DN as user attribute.
> During
> > the login we match the authentication certificate's subjectDN against
> the
> > value stored in the user attributes.
> > The subject DN is determined executing:
> > cert.getSubjectDN().getName()
> >
> > Here we have a problem regarding the subject DN order. We realized that
> > the subject DN order is security provider specific:
> >
> > · Using SUN security provider we get a subject DN like:
> > "EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=
> > example.com, ST=California, C=US"
> >
> > · Using BouncyCastle security provider we get a subject DN like:
> > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> > bjensen(a)example.com"
> > This is obviously a problem.
> > Does anybody else ran into the same problem?
> >
> > In my opinion it would be better to use:
> >
> > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> > to determine the subject DN, as the result is provider independent.
> > But this would be an backward incompatible change in Method
> >
> >
>
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
> >
> > What is your opinion?
> >
> > Best regards
> > Sebastian
> >
> > --
> > Solution Engineering
> > --
> > Governikus GmbH & Co. KG
> > Hochschulring 4
> > 28359 Bremen, Germany
> >
> > Phone: +49 421 204 95 - 28
> > Fax: +49 421 204 95 - 11
> > E-Mail: Sebastian.Loesch(a)governikus.de<mailto:
> > Sebastian.Loesch(a)governikus.de>
> > www.governikus.de<http://www.governikus.de/>
> > --
> > Governikus GmbH & Co. KG
> > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> > 22041
> > Geschäftsführer: Dr. Stephan Klein
> >
> > Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
> > Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
> >
> >
> > ****************************************************
> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > Hochschulring 4, 28359 Bremen
> >
> > Veranstaltungsvorschau: Besuchen Sie uns...
> > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> >
>
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
> > >
> > Digitaler Staat | 02. + 03.04.2019 | Berlin<
> > https://www.digitaler-staat.org/>
> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> > https://www.zukunftskongress.info/de>
> > Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<
> https://www.bw-4-0.de/
> > >
> >
> > [cid:image8a82cf.JPG@26f9b88d.448c29be]<
> > http://www.jahrestagung.governikus.de/>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:36 p.m.
Hello Pedro,
I am using JDK 1.8 Update 201.
Best regards,
Sebastian
Von: Pedro Igor Silva <psilva(a)redhat.com>
Gesendet: Dienstag, 12. Februar 2019 13:19
An: Thomas Darimont <thomas.darimont(a)googlemail.com>
Cc: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
IIRC, email address should be included/parsed as a subject alternative name extension.
BouncyCastle seems doing it right.
What is the JDK version being used?
On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont
<mailto:thomas.darimont@googlemail.com> wrote:
Hi Sebastian,
how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.
Cheers,
Thomas
Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
mailto:Sebastian.Loesch@governikus.de>:
Hello Keycloak developers,
I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During
the login we match the authentication certificate's subjectDN against the
value stored in the user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()
Here we have a problem regarding the subject DN order. We realized that
the subject DN order is security provider specific:
· Using SUN security provider we get a subject DN like:
"EMAILADDRESS=mailto:bjensen@example.com, CN=Ms. Barbara J Jensen III, O=
http://example.com, ST=California, C=US"
· Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=http://example.com,CN=Ms. Barbara J Jensen III,E=
mailto:bjensen@example.com"
This is obviously a problem.
Does anybody else ran into the same problem?
In my opinion it would be better to use:
cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
What is your opinion?
Best regards
Sebastian
--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany
Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: mailto:Sebastian.Loesch@governikus.de<mailto:
mailto:Sebastian.Loesch@governikus.de>
http://www.governikus.de<http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Geschäftsführer: Dr. Stephan Klein
Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
Hochschulring 4, 28359 Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
>
Digitaler Staat | 02. + 03.04.2019 | Berlin<
https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/
>
[cid:image8a82cf.JPG@26f9b88d.448c29be]<
http://www.jahrestagung.governikus.de/>
****************************************************
Neue Adresse!
Ab 1.1.2019 ändert sich unsere Bremer Anschrift: Hochschulring 4, 28359 Bremen
7. Anwenderforum AusweisApp2 | 21.01.2019 | Berlin
OMNISECURE | 21. - 23.01.2019 | Berlin
_______________________________________________
keycloak-dev mailing list
mailto:keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
mailto:keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:57 p.m.
Hello developer,
I opened a new issue for Keycloak: https://issues.jboss.org/browse/KEYCLOAK-9554
and provided a pull request: https://github.com/keycloak/keycloak/pull/5878
Best regards,
Sebastian
Von: Pedro Igor Silva <psilva(a)redhat.com>
Gesendet: Dienstag, 12. Februar 2019 13:24
An: Thomas Darimont <thomas.darimont(a)googlemail.com>
Cc: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>; keycloak-dev
<keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
Btw, we also support extracting email using a subject alt name extension. Maybe we could
safely use CANONICAL (which seems to be more aligned with the specs) and tell people to
use this extractor if they want to use email address from certificates.
On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva
<psilva@redhat.com<mailto:psilva@redhat.com>> wrote:
IIRC, email address should be included/parsed as a subject alternative name extension.
BouncyCastle seems doing it right.
What is the JDK version being used?
On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont
<thomas.darimont@googlemail.com<mailto:thomas.darimont@googlemail.com>>
wrote:
Hi Sebastian,
how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.
Cheers,
Thomas
Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
Sebastian.Loesch@governikus.de<mailto:Sebastian.Loesch@governikus.de>>:
Hello Keycloak developers,
I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During
the login we match the authentication certificate's subjectDN against the
value stored in the user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()
Here we have a problem regarding the subject DN order. We realized that
the subject DN order is security provider specific:
· Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen@example.com<mailto:bjensen@example.com>, CN=Ms. Barbara
J Jensen III, O=
example.com<http://example.com>, ST=California, C=US"
· Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com<http://example.com>,CN=Ms. Barbara J Jensen
III,E=
bjensen@example.com<mailto:bjensen@example.com>"
This is obviously a problem.
Does anybody else ran into the same problem?
In my opinion it would be better to use:
cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
What is your opinion?
Best regards
Sebastian
--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany
Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail:
Sebastian.Loesch@governikus.de<mailto:Sebastian.Loesch@governikus.de><mailto:
Sebastian.Loesch@governikus.de<mailto:Sebastian.Loesch@governikus.de>>
www.governikus.de<http://www.governikus.de><http://www.governiku...
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Geschäftsführer: Dr. Stephan Klein
Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
Hochschulring 4, 28359 Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
>
Digitaler Staat | 02. + 03.04.2019 | Berlin<
https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/
>
[cid:image8a82cf.JPG@26f9b88d.448c29be]<
http://www.jahrestagung.governikus.de/>
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359
Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg -
Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse-Dataport.aspx>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 |
Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>
[cid:image71d7fc.JPG@4dd78026.4b9f719f]<http://www.jahrestagung.governikus.de/>
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:27 p.m.
Thanks. I'm still not sure about that new CANONICAL parameter. Added a
comment to your PR.
On Tue, Feb 12, 2019 at 11:57 AM Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de> wrote:
Hello developer,
I opened a new issue for Keycloak:
https://issues.jboss.org/browse/KEYCLOAK-9554
and provided a pull request:
https://github.com/keycloak/keycloak/pull/5878
Best regards,
Sebastian
*Von:* Pedro Igor Silva <psilva(a)redhat.com>
*Gesendet:* Dienstag, 12. Februar 2019 13:24
*An:* Thomas Darimont <thomas.darimont(a)googlemail.com>
*Cc:* Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>; keycloak-dev <
keycloak-dev(a)lists.jboss.org>
*Betreff:* Re: [keycloak-dev] Certificate subject DN is provider dependent
Btw, we also support extracting email using a subject alt name extension.
Maybe we could safely use CANONICAL (which seems to be more aligned with
the specs) and tell people to use this extractor if they want to use email
address from certificates.
On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva(a)redhat.com>
wrote:
IIRC, email address should be included/parsed as a subject alternative
name extension. BouncyCastle seems doing it right.
What is the JDK version being used?
On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
Hi Sebastian,
how about Keycloak would introduce an option for this authenticator like:
"Use canonical principal extraction" on/off with default "off",
meaning the default behavior stays the same. "on" would then mean to use
the "canonical" option for extracting the subject as you suggested.
Cheers,
Thomas
Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de>:
> Hello Keycloak developers,
>
> I am currently working on configuring keycloak for X.509 certificate
login.
> We store the whole user certificate's subject DN as user attribute.
During
> the login we match the authentication certificate's subjectDN against the
> value stored in the user attributes.
> The subject DN is determined executing:
> cert.getSubjectDN().getName()
>
> Here we have a problem regarding the subject DN order. We realized that
> the subject DN order is security provider specific:
>
> · Using SUN security provider we get a subject DN like:
> "EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=
> example.com, ST=California, C=US"
>
> · Using BouncyCastle security provider we get a subject DN like:
> "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> bjensen(a)example.com"
> This is obviously a problem.
> Does anybody else ran into the same problem?
>
> In my opinion it would be better to use:
>
> cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> to determine the subject DN, as the result is provider independent.
> But this would be an backward incompatible change in Method
>
>
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
>
> What is your opinion?
>
> Best regards
> Sebastian
>
> --
> Solution Engineering
> --
> Governikus GmbH & Co. KG
> Hochschulring 4
> 28359 Bremen, Germany
>
> Phone: +49 421 204 95 - 28
> Fax: +49 421 204 95 - 11
> E-Mail: Sebastian.Loesch(a)governikus.de<mailto:
> Sebastian.Loesch(a)governikus.de>
> www.governikus.de<http://www.governikus.de/>
> --
> Governikus GmbH & Co. KG
> Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> 22041
> Geschäftsführer: Dr. Stephan Klein
>
> Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
> Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns...
> Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
>
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
> >
> Digitaler Staat | 02. + 03.04.2019 | Berlin<
> https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> https://www.zukunftskongress.info/de>
> Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<
https://www.bw-4-0.de/
> >
>
> [cid:image8a82cf.JPG@26f9b88d.448c29be]<
> http://www.jahrestagung.governikus.de/>
>
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
Hochschulring 4, 28359 Bremen
Veranstaltungsvorschau: Besuchen Sie uns…
Dataport Hausmesse | 02.04.2019 | Hamburg – Schnelsen
<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
Digitaler Staat | 02. + 03.04.2019 | Berlin
<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin
<https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart
<https://www.bw-4-0.de/>
<http://www.jahrestagung.governikus.de/>
_______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:01 p.m.
Incidentally, this issue has been discussed few weeks ago on this mailing
list in the thread "User TLS client certificate authentication -
inconsistent DN string representation with LDAP" starting on Dec 23. Could
you please ensure the concerns from that thread are addressed in the PR?
On Tue, Feb 12, 2019 at 3:30 PM Pedro Igor Silva <psilva(a)redhat.com> wrote:
Thanks. I'm still not sure about that new CANONICAL parameter.
Added a
comment to your PR.
On Tue, Feb 12, 2019 at 11:57 AM Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de> wrote:
> Hello developer,
>
>
>
> I opened a new issue for Keycloak:
> https://issues.jboss.org/browse/KEYCLOAK-9554
>
> and provided a pull request:
> https://github.com/keycloak/keycloak/pull/5878
>
>
>
> Best regards,
>
> Sebastian
>
>
>
>
>
> *Von:* Pedro Igor Silva <psilva(a)redhat.com>
> *Gesendet:* Dienstag, 12. Februar 2019 13:24
> *An:* Thomas Darimont <thomas.darimont(a)googlemail.com>
> *Cc:* Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>; keycloak-dev <
> keycloak-dev(a)lists.jboss.org>
> *Betreff:* Re: [keycloak-dev] Certificate subject DN is provider
dependent
>
>
>
> Btw, we also support extracting email using a subject alt name extension.
> Maybe we could safely use CANONICAL (which seems to be more aligned with
> the specs) and tell people to use this extractor if they want to use
email
> address from certificates.
>
>
>
> On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva(a)redhat.com>
> wrote:
>
> IIRC, email address should be included/parsed as a subject alternative
> name extension. BouncyCastle seems doing it right.
>
>
>
> What is the JDK version being used?
>
>
>
> On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
> thomas.darimont(a)googlemail.com> wrote:
>
> Hi Sebastian,
>
> how about Keycloak would introduce an option for this authenticator like:
> "Use canonical principal extraction" on/off with default "off",
> meaning the default behavior stays the same. "on" would then mean to use
> the "canonical" option for extracting the subject as you suggested.
>
> Cheers,
> Thomas
>
> Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
> Sebastian.Loesch(a)governikus.de>:
>
> > Hello Keycloak developers,
> >
> > I am currently working on configuring keycloak for X.509 certificate
> login.
> > We store the whole user certificate's subject DN as user attribute.
> During
> > the login we match the authentication certificate's subjectDN against
the
> > value stored in the user attributes.
> > The subject DN is determined executing:
> > cert.getSubjectDN().getName()
> >
> > Here we have a problem regarding the subject DN order. We realized that
> > the subject DN order is security provider specific:
> >
> > · Using SUN security provider we get a subject DN like:
> > "EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=
> > example.com, ST=California, C=US"
> >
> > · Using BouncyCastle security provider we get a subject DN
like:
> > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> > bjensen(a)example.com"
> > This is obviously a problem.
> > Does anybody else ran into the same problem?
> >
> > In my opinion it would be better to use:
> >
> > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> > to determine the subject DN, as the result is provider independent.
> > But this would be an backward incompatible change in Method
> >
> >
>
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
> >
> > What is your opinion?
> >
> > Best regards
> > Sebastian
> >
> > --
> > Solution Engineering
> > --
> > Governikus GmbH & Co. KG
> > Hochschulring 4
> > 28359 Bremen, Germany
> >
> > Phone: +49 421 204 95 - 28
> > Fax: +49 421 204 95 - 11
> > E-Mail: Sebastian.Loesch(a)governikus.de<mailto:
> > Sebastian.Loesch(a)governikus.de>
> > www.governikus.de<http://www.governikus.de/>
> > --
> > Governikus GmbH & Co. KG
> > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> > 22041
> > Geschäftsführer: Dr. Stephan Klein
> >
> > Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
> > Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
> >
> >
> > ****************************************************
> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > Hochschulring 4, 28359 Bremen
> >
> > Veranstaltungsvorschau: Besuchen Sie uns...
> > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> >
>
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
> > >
> > Digitaler Staat | 02. + 03.04.2019 | Berlin<
> > https://www.digitaler-staat.org/>
> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> > https://www.zukunftskongress.info/de>
> > Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<
> https://www.bw-4-0.de/
> > >
> >
> > [cid:image8a82cf.JPG@26f9b88d.448c29be]<
> > http://www.jahrestagung.governikus.de/>
> >
>
>
> ****************************************************
> Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> Hochschulring 4, 28359 Bremen
>
> Veranstaltungsvorschau: Besuchen Sie uns…
> Dataport Hausmesse | 02.04.2019 | Hamburg – Schnelsen
> <
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
>
> Digitaler Staat | 02. + 03.04.2019 | Berlin
> <https://www.digitaler-staat.org/>
> 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin
> <https://www.zukunftskongress.info/de>
> Kongress Baden-Württemberg | 04.07.2019 | Stuttgart
> <https://www.bw-4-0.de/>
>
> <http://www.jahrestagung.governikus.de/>
>
> _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:05 p.m.
I think these threads are not talking about the same thing. The issue here
is the email address within the subject dn, which is deprecated in favor of
a specific subject alternative name extension in the certificate.
The PR LGTM too, I'm just not sure about the new "CANONICAL" configuration
option ...
On Tue, Feb 12, 2019 at 3:01 PM Hynek Mlnarik <hmlnarik(a)redhat.com> wrote:
Incidentally, this issue has been discussed few weeks ago on this
mailing
list in the thread "User TLS client certificate authentication -
inconsistent DN string representation with LDAP" starting on Dec 23. Could
you please ensure the concerns from that thread are addressed in the PR?
On Tue, Feb 12, 2019 at 3:30 PM Pedro Igor Silva <psilva(a)redhat.com>
wrote:
> Thanks. I'm still not sure about that new CANONICAL parameter. Added a
> comment to your PR.
>
> On Tue, Feb 12, 2019 at 11:57 AM Lösch, Sebastian <
> Sebastian.Loesch(a)governikus.de> wrote:
>
> > Hello developer,
> >
> >
> >
> > I opened a new issue for Keycloak:
> > https://issues.jboss.org/browse/KEYCLOAK-9554
> >
> > and provided a pull request:
> > https://github.com/keycloak/keycloak/pull/5878
> >
> >
> >
> > Best regards,
> >
> > Sebastian
> >
> >
> >
> >
> >
> > *Von:* Pedro Igor Silva <psilva(a)redhat.com>
> > *Gesendet:* Dienstag, 12. Februar 2019 13:24
> > *An:* Thomas Darimont <thomas.darimont(a)googlemail.com>
> > *Cc:* Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>; keycloak-dev
<
> > keycloak-dev(a)lists.jboss.org>
> > *Betreff:* Re: [keycloak-dev] Certificate subject DN is provider
> dependent
> >
> >
> >
> > Btw, we also support extracting email using a subject alt name
> extension.
> > Maybe we could safely use CANONICAL (which seems to be more aligned with
> > the specs) and tell people to use this extractor if they want to use
> email
> > address from certificates.
> >
> >
> >
> > On Tue, Feb 12, 2019 at 10:19 AM Pedro Igor Silva <psilva(a)redhat.com>
> > wrote:
> >
> > IIRC, email address should be included/parsed as a subject alternative
> > name extension. BouncyCastle seems doing it right.
> >
> >
> >
> > What is the JDK version being used?
> >
> >
> >
> > On Tue, Feb 12, 2019 at 9:57 AM Thomas Darimont <
> > thomas.darimont(a)googlemail.com> wrote:
> >
> > Hi Sebastian,
> >
> > how about Keycloak would introduce an option for this authenticator
> like:
> > "Use canonical principal extraction" on/off with default
"off",
> > meaning the default behavior stays the same. "on" would then mean to
use
> > the "canonical" option for extracting the subject as you suggested.
> >
> > Cheers,
> > Thomas
> >
> > Am Di., 12. Feb. 2019 um 12:33 Uhr schrieb Lösch, Sebastian <
> > Sebastian.Loesch(a)governikus.de>:
> >
> > > Hello Keycloak developers,
> > >
> > > I am currently working on configuring keycloak for X.509 certificate
> > login.
> > > We store the whole user certificate's subject DN as user attribute.
> > During
> > > the login we match the authentication certificate's subjectDN against
> the
> > > value stored in the user attributes.
> > > The subject DN is determined executing:
> > > cert.getSubjectDN().getName()
> > >
> > > Here we have a problem regarding the subject DN order. We realized
> that
> > > the subject DN order is security provider specific:
> > >
> > > · Using SUN security provider we get a subject DN like:
> > > "EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=
> > > example.com, ST=California, C=US"
> > >
> > > · Using BouncyCastle security provider we get a subject DN
> like:
> > > "C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=
> > > bjensen(a)example.com"
> > > This is obviously a problem.
> > > Does anybody else ran into the same problem?
> > >
> > > In my opinion it would be better to use:
> > >
> > > cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
> > > to determine the subject DN, as the result is provider independent.
> > > But this would be an backward incompatible change in Method
> > >
> > >
> >
>
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
> > >
> > > What is your opinion?
> > >
> > > Best regards
> > > Sebastian
> > >
> > > --
> > > Solution Engineering
> > > --
> > > Governikus GmbH & Co. KG
> > > Hochschulring 4
> > > 28359 Bremen, Germany
> > >
> > > Phone: +49 421 204 95 - 28
> > > Fax: +49 421 204 95 - 11
> > > E-Mail: Sebastian.Loesch(a)governikus.de<mailto:
> > > Sebastian.Loesch(a)governikus.de>
> > > www.governikus.de<http://www.governikus.de/>
> > > --
> > > Governikus GmbH & Co. KG
> > > Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
> > > 22041
> > > Geschäftsführer: Dr. Stephan Klein
> > >
> > > Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
> > > Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
> > >
> > >
> > > ****************************************************
> > > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > > Hochschulring 4, 28359 Bremen
> > >
> > > Veranstaltungsvorschau: Besuchen Sie uns...
> > > Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<
> > >
> >
>
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
> > > >
> > > Digitaler Staat | 02. + 03.04.2019 | Berlin<
> > > https://www.digitaler-staat.org/>
> > > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<
> > > https://www.zukunftskongress.info/de>
> > > Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<
> > https://www.bw-4-0.de/
> > > >
> > >
> > > [cid:image8a82cf.JPG@26f9b88d.448c29be]<
> > > http://www.jahrestagung.governikus.de/>
> > >
> >
> >
> > ****************************************************
> > Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift:
> > Hochschulring 4, 28359 Bremen
> >
> > Veranstaltungsvorschau: Besuchen Sie uns…
> > Dataport Hausmesse | 02.04.2019 | Hamburg – Schnelsen
> > <
>
https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...
> >
> > Digitaler Staat | 02. + 03.04.2019 | Berlin
> > <https://www.digitaler-staat.org/>
> > 7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin
> > <https://www.zukunftskongress.info/de>
> > Kongress Baden-Württemberg | 04.07.2019 | Stuttgart
> > <https://www.bw-4-0.de/>
> >
> > <http://www.jahrestagung.governikus.de/>
> >
> > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:27 p.m.
On 2/12/19 1:05 PM, Pedro Igor Silva wrote:
I think these threads are not talking about the same thing. The issue
here
is the email address within the subject dn, which is deprecated in favor of
a specific subject alternative name extension in the certificate.
Actually I think the two issues are pretty much the same and presence of
an email address is a red herring [1]. In both cases one is trying to
compare a DN for equality.
What is a bit troubling is the order of the RDN's as returned by the two
providers. Notice they are reversed. This is a common problem with
different X509 implementations. The RFC's are clear, the order of RDN's
in a string representation are supposed to be added by starting with the
LAST RDN in the binary format (ASN.1) and proceeds towards the first.
However this is often the opposite of how humans want to read these
strings and some implementations reverse the order (a classic example is
OpenSSL vs. NSS).
The other thing to note is one provider is using an alias for the email
address and the other isn't.
What is not clear to me from the email is how the string representations
from the two providers was obtained, clearly they are using different
algorithms. BUT the certificate subject is in binary form in the
certificate and the same X509 implementation SHOULD produce identical
string representations from the same binary data. Therefore be careful
and draw a sharp distinction between asking one implementation to
convert binary data to string format and the actual binary data.
FWIW the Java implementations refer to RFC 2253 but that has been
superseded by RFC 4514.
[1] Yes, email addresses are better specified in a SAN but for legacy
reasons it's perfectly fine to include them in the subject, things
should still work.
--
John Dennis
9:04 p.m.
Pretty much, but not the same. The fix for this still does not seem to
solve the problem being discussed in the other thread.
The change provided by Sebastian does solve this problem while still
backwards compatible with certificates with subject dn containing an
emailAddress. My point though is whether or not we should be backward
compatible given that emailAddress is a deprecated RDN in the subject DN.
As you mentioned, RFC-2253 was superseded by RFC-4514 and there you can't
have emailAddress in subject DN but prefer a SAN. So, my question is ... Is
OK in 2019 to assume that certificates are using RFC-4514 ? So we could
just use the canonical format in our side and avoid any additional
configuration.
You are right, java defaults to RFC-2253, I'm not sure if the "canonical"
format is related with the support for 4514 (at least removing emailAddress
from subject DN).
On Tue, Feb 12, 2019 at 5:27 PM John Dennis <jdennis(a)redhat.com> wrote:
On 2/12/19 1:05 PM, Pedro Igor Silva wrote:
> I think these threads are not talking about the same thing. The issue
here
> is the email address within the subject dn, which is deprecated in favor
of
> a specific subject alternative name extension in the certificate.
Actually I think the two issues are pretty much the same and presence of
an email address is a red herring [1]. In both cases one is trying to
compare a DN for equality.
What is a bit troubling is the order of the RDN's as returned by
the two
providers. Notice they are reversed. This is a common problem with
different X509 implementations. The RFC's are clear, the order of RDN's
in a string representation are supposed to be added by starting with the
LAST RDN in the binary format (ASN.1) and proceeds towards the first.
However this is often the opposite of how humans want to read these
strings and some implementations reverse the order (a classic example is
OpenSSL vs. NSS).
The other thing to note is one provider is using an alias for the email
address and the other isn't.
What is not clear to me from the email is how the string representations
from the two providers was obtained, clearly they are using different
algorithms. BUT the certificate subject is in binary form in the
certificate and the same X509 implementation SHOULD produce identical
string representations from the same binary data. Therefore be careful
and draw a sharp distinction between asking one implementation to
convert binary data to string format and the actual binary data.
FWIW the Java implementations refer to RFC 2253 but that has been
superseded by RFC 4514.
[1] Yes, email addresses are better specified in a SAN but for legacy
reasons it's perfectly fine to include them in the subject, things
should still work.
--
John Dennis
9:43 p.m.
On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
Pretty much, but not the same. The fix for this still does not
seem to
solve the problem being discussed in the other thread.
The change provided by Sebastian does solve this problem while still
backwards compatible with certificates with subject dn containing an
emailAddress. My point though is whether or not we should be backward
compatible given that emailAddress is a deprecated RDN in the subject DN.
As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
can't have emailAddress in subject DN but prefer a SAN. So, my question
is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So
we could just use the canonical format in our side and avoid any
additional configuration.
You are right, java defaults to RFC-2253, I'm not sure if the
"canonical" format is related with the support for 4514 (at least
removing emailAddress from subject DN).
No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
in ASN.1 format is converted to a string representation. These RFC's do
not define the permissible members of a DN in an X509 certificate. In
fact the subject member of an X509 certificate was originally *under*
specified leading to all sorts of compatibility problems. The usual
solution adopted only by convention and not by specification is to
extract the CommonName (i.e. CN) RDN value and use that as the subject
name (usually in the scope of the issuer). But as you can imagine that
also has it's own problems (e.g. name collisions that would otherwise be
uniquely determined by the other RDN values and/or scoping to the issuer).
I go back to my original assertion when I first replied weeks ago. If
you want to compare DN's for equality you're going to have to do so by
breaking the DN down into it's component parts and comparing them
individually or reformat the string representation of the DN into a
canonical form and perform a string comparison (note that forming a
canonical string representation also requires breaking the components
apart so there is little actual difference between doing an equality
test between DN objects and an equality comparison on the resulting
canonical strings, the later just adds the cycles needed to format the
individual components).
--
John Dennis
10:26 p.m.
On Tue, Feb 12, 2019 at 6:43 PM John Dennis <jdennis(a)redhat.com> wrote:
On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
> Pretty much, but not the same. The fix for this still does not seem to
> solve the problem being discussed in the other thread.
>
> The change provided by Sebastian does solve this problem while still
> backwards compatible with certificates with subject dn containing an
> emailAddress. My point though is whether or not we should be backward
> compatible given that emailAddress is a deprecated RDN in the subject DN.
>
> As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
> can't have emailAddress in subject DN but prefer a SAN. So, my question
> is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So
> we could just use the canonical format in our side and avoid any
> additional configuration.
>
> You are right, java defaults to RFC-2253, I'm not sure if the
> "canonical" format is related with the support for 4514 (at least
> removing emailAddress from subject DN).
No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
in ASN.1 format is converted to a string representation. These RFC's do
not define the permissible members of a DN in an X509 certificate. In
fact the subject member of an X509 certificate was originally *under*
specified leading to all sorts of compatibility problems. The usual
solution adopted only by convention and not by specification is to
extract the CommonName (i.e. CN) RDN value and use that as the subject
name (usually in the scope of the issuer). But as you can imagine that
also has it's own problems (e.g. name collisions that would otherwise be
uniquely determined by the other RDN values and/or scoping to the issuer).
Sure, but note that RFC-4514 relies on 4519 (which actually defines the
supported attributed types).
I go back to my original assertion when I first replied weeks ago. If
you want to compare DN's for equality you're going to have to do so by
breaking the DN down into it's component parts and comparing them
individually or reformat the string representation of the DN into a
canonical form and perform a string comparison (note that forming a
canonical string representation also requires breaking the components
apart so there is little actual difference between doing an equality
test between DN objects and an equality comparison on the resulting
canonical strings, the later just adds the cycles needed to format the
individual components).
Yeah, I think so. I hope this can solve the "comparison issue". Need to get
more familiar with what was discussed in the other thread.
So, based on your experience in Openstack. Is there people still using
certificates with deprecated emailAddress as part of the subject DN ? If
your answer is no, we probably want to avoid an additional configuration to
enable/disable java canonical format. Otherwise, if your answer is
yes/don't know, maybe we should keep the configuration option implemented
in the PR.
The main reason for pushing this question is that from a security
perspective, using a deprecated attribute type in subject dn is not good.
Privacy concerns may apply here too where you may not want people to put
the email (sensitive) in something that is supposed to be public.
Thanks.
--
John Dennis
10:30 p.m.
On Tue, Feb 12, 2019 at 7:26 PM Pedro Igor Silva <psilva(a)redhat.com> wrote:
On Tue, Feb 12, 2019 at 6:43 PM John Dennis <jdennis(a)redhat.com> wrote:
> On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
> > Pretty much, but not the same. The fix for this still does not seem to
> > solve the problem being discussed in the other thread.
> >
> > The change provided by Sebastian does solve this problem while still
> > backwards compatible with certificates with subject dn containing an
> > emailAddress. My point though is whether or not we should be backward
> > compatible given that emailAddress is a deprecated RDN in the subject
> DN.
> >
> > As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
> > can't have emailAddress in subject DN but prefer a SAN. So, my question
> > is ... Is OK in 2019 to assume that certificates are using RFC-4514
> ? So
> > we could just use the canonical format in our side and avoid any
> > additional configuration.
> >
> > You are right, java defaults to RFC-2253, I'm not sure if the
> > "canonical" format is related with the support for 4514 (at least
> > removing emailAddress from subject DN).
>
> No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
> in ASN.1 format is converted to a string representation. These RFC's do
> not define the permissible members of a DN in an X509 certificate. In
> fact the subject member of an X509 certificate was originally *under*
> specified leading to all sorts of compatibility problems. The usual
> solution adopted only by convention and not by specification is to
> extract the CommonName (i.e. CN) RDN value and use that as the subject
> name (usually in the scope of the issuer). But as you can imagine that
> also has it's own problems (e.g. name collisions that would otherwise be
> uniquely determined by the other RDN values and/or scoping to the issuer).
>
Sure, but note that RFC-4514 relies on 4519 (which actually defines the
supported attributed types).
>
> I go back to my original assertion when I first replied weeks ago. If
> you want to compare DN's for equality you're going to have to do so by
> breaking the DN down into it's component parts and comparing them
> individually or reformat the string representation of the DN into a
> canonical form and perform a string comparison (note that forming a
> canonical string representation also requires breaking the components
> apart so there is little actual difference between doing an equality
> test between DN objects and an equality comparison on the resulting
> canonical strings, the later just adds the cycles needed to format the
> individual components).
>
Yeah, I think so. I hope this can solve the "comparison issue". Need to
get more familiar with what was discussed in the other thread.
So, based on your experience in Openstack. Is there people still using
certificates with deprecated emailAddress as part of the subject DN ? If
your answer is no, we probably want to avoid an additional configuration to
enable/disable java canonical format. Otherwise, if your answer is
yes/don't know, maybe we should keep the configuration option implemented
in the PR.
The main reason for pushing this question is that from a security
perspective, using a deprecated attribute type in subject dn is not good.
Privacy concerns may apply here too where you may not want people to put
the email (sensitive) in something that is supposed to be public.
I mean, encourage people to use that way ....
Thanks.
>
>
> --
> John Dennis
>
11:17 p.m.
On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
Sure, but note that RFC-4514 relies on 4519 (which actually defines
the
supported attributed types).
I don't think RFC 4519 is what you're looking for, you want to be
looking at the X509 Certificate RFC's.
Ugh, the RFC's for this stuff is a tangled mess of cross references to
other RFC's. It's ugly and hard to decipher which is probably why these
issues seem to keep cropping up.
The main reason for pushing this question is that from a security
perspective, using a deprecated attribute type in subject dn is not
good. Privacy concerns may apply here too where you may not want people
to put the email (sensitive) in something that is supposed to be public.
I'm not sure that's the question. You don't have control over the certs
that are presented to you. Rather your job is to ascertain if you can
unequivocally map the cert subject to a principal in your domain. You
probably can't put a stake in the ground and demand the subject contain
certain RDN's (with the exception of the CN). And FWIW just to make
things even more confusing a common convention for client certs is to
put the users email address as the subject's CN.
I have a suggestion, I'm not the ultimate authority on this stuff. We
have a developer on the Certificate Server team who I believe has an
even more in depth understanding and is probably more current on this
topic that I am (I did this work several years ago). He is Fraser
Tweedale <ftweedal(a)redhat.com>, perhaps you might want to open a
discussion with him. FWIW the Certificate Server is also written in Java
and he might be able to share Java code snippets with you on the best
way to perform these comparisons.
--
John Dennis
12:02 a.m.
On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis(a)redhat.com> wrote:
On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> Sure, but note that RFC-4514 relies on 4519 (which actually defines the
> supported attributed types).
I don't think RFC 4519 is what you're looking for, you want to be
looking at the X509 Certificate RFC's.
Ugh, the RFC's for this stuff is a tangled mess of cross references to
other RFC's. It's ugly and hard to decipher which is probably why these
issues seem to keep cropping up.
Yes, they are ...
> The main reason for pushing this question is that from a security
> perspective, using a deprecated attribute type in subject dn is not
> good. Privacy concerns may apply here too where you may not want people
> to put the email (sensitive) in something that is supposed to be public.
I'm not sure that's the question. You don't have control over the certs
that are presented to you. Rather your job is to ascertain if you can
unequivocally map the cert subject to a principal in your domain. You
probably can't put a stake in the ground and demand the subject contain
certain RDN's (with the exception of the CN). And FWIW just to make
things even more confusing a common convention for client certs is to
put the users email address as the subject's CN.
I have a suggestion, I'm not the ultimate authority on this stuff. We
have a developer on the Certificate Server team who I believe has an
even more in depth understanding and is probably more current on this
topic that I am (I did this work several years ago). He is Fraser
Tweedale <ftweedal(a)redhat.com>, perhaps you might want to open a
discussion with him. FWIW the Certificate Server is also written in Java
and he might be able to share Java code snippets with you on the best
way to perform these comparisons.
Yeah, we can not control how people are issuing certificates. I was trying
to find someone to say "Yeah, emailAddress is really a bad practice in
subject dn. People should use SAN instead".
I think your contact may help here with both issues, for sure. Although I'm
convinced that at least the changes made in that PR are fine instead of
possibly breaking use cases by forcing canonicalization.
--
John Dennis
6:37 a.m.
The main point on this issue in my opinion is to have a reliable, provider independent DN
representation.
This is not given using the currently used Java API X509Certificate.getSubjectDN() and
X509Certificate.getIssuerDN().
The JavaDoc states here the result is "[...]an implementation specific Principal
object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.
I am wondering if this canonical config switch ON/OFF is the right way. It has no effect
on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical IssuerDN
using regular expression" and "Match canonical SubjectDN using regular
expression"?
The existing solutions are kept for backward compatibility but deprecated in the
documentation?
Best regards,
Sebastian
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-
bounces(a)lists.jboss.org> Im Auftrag von Pedro Igor Silva
Gesendet: Mittwoch, 13. Februar 2019 00:03
An: John Dennis <jdennis(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis(a)redhat.com> wrote:
> On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > the supported attributed types).
>
> I don't think RFC 4519 is what you're looking for, you want to be
> looking at the X509 Certificate RFC's.
>
> Ugh, the RFC's for this stuff is a tangled mess of cross references to
> other RFC's. It's ugly and hard to decipher which is probably why
> these issues seem to keep cropping up.
>
Yes, they are ...
>
> > The main reason for pushing this question is that from a security
> > perspective, using a deprecated attribute type in subject dn is not
> > good. Privacy concerns may apply here too where you may not want
> > people to put the email (sensitive) in something that is supposed to be
public.
>
> I'm not sure that's the question. You don't have control over the
> certs that are presented to you. Rather your job is to ascertain if
> you can unequivocally map the cert subject to a principal in your
> domain. You probably can't put a stake in the ground and demand the
> subject contain certain RDN's (with the exception of the CN). And FWIW
> just to make things even more confusing a common convention for client
> certs is to put the users email address as the subject's CN.
>
> I have a suggestion, I'm not the ultimate authority on this stuff. We
> have a developer on the Certificate Server team who I believe has an
> even more in depth understanding and is probably more current on this
> topic that I am (I did this work several years ago). He is Fraser
> Tweedale <ftweedal(a)redhat.com>, perhaps you might want to open a
> discussion with him. FWIW the Certificate Server is also written in
> Java and he might be able to share Java code snippets with you on the
> best way to perform these comparisons.
>
Yeah, we can not control how people are issuing certificates. I was trying to find
someone to say "Yeah, emailAddress is really a bad practice in subject dn.
People should use SAN instead".
I think your contact may help here with both issues, for sure. Although I'm
convinced that at least the changes made in that PR are fine instead of possibly
breaking use cases by forcing canonicalization.
>
>
> --
> John Dennis
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:42 p.m.
On 12/02/2019 22:26, Pedro Igor Silva wrote:
On Tue, Feb 12, 2019 at 6:43 PM John Dennis
<jdennis(a)redhat.com> wrote:
> On 2/12/19 3:04 PM, Pedro Igor Silva wrote:
>> Pretty much, but not the same. The fix for this still does not seem to
>> solve the problem being discussed in the other thread.
>>
>> The change provided by Sebastian does solve this problem while still
>> backwards compatible with certificates with subject dn containing an
>> emailAddress. My point though is whether or not we should be backward
>> compatible given that emailAddress is a deprecated RDN in the subject DN.
>>
>> As you mentioned, RFC-2253 was superseded by RFC-4514 and there you
>> can't have emailAddress in subject DN but prefer a SAN. So, my question
>> is ... Is OK in 2019 to assume that certificates are using RFC-4514 ? So
>> we could just use the canonical format in our side and avoid any
>> additional configuration.
>>
>> You are right, java defaults to RFC-2253, I'm not sure if the
>> "canonical" format is related with the support for 4514 (at least
>> removing emailAddress from subject DN).
> No, RFC's 2253 and 4514 *only* describe the process by which a binary DN
> in ASN.1 format is converted to a string representation. These RFC's do
> not define the permissible members of a DN in an X509 certificate. In
> fact the subject member of an X509 certificate was originally *under*
> specified leading to all sorts of compatibility problems. The usual
> solution adopted only by convention and not by specification is to
> extract the CommonName (i.e. CN) RDN value and use that as the subject
> name (usually in the scope of the issuer). But as you can imagine that
> also has it's own problems (e.g. name collisions that would otherwise be
> uniquely determined by the other RDN values and/or scoping to the issuer).
>
Sure, but note that RFC-4514 relies on 4519 (which actually defines the
supported attributed types).
> I go back to my original assertion when I first replied weeks ago. If
> you want to compare DN's for equality you're going to have to do so by
> breaking the DN down into it's component parts and comparing them
> individually or reformat the string representation of the DN into a
> canonical form and perform a string comparison (note that forming a
> canonical string representation also requires breaking the components
> apart so there is little actual difference between doing an equality
> test between DN objects and an equality comparison on the resulting
> canonical strings, the later just adds the cycles needed to format the
> individual components).
>
Yeah, I think so. I hope this can solve the "comparison issue". Need to get
more familiar with what was discussed in the other thread.
Just to refresh, the problem discussed on the other thread was
unfortunately not simply "comparison issue" (which I think is not hard
to solve with the proposal you suggested above), but "lookup user
issue", which makes things slightly more complicated.
AFAIR the use-case was, that you just received the certificate with some
Subject DN and based on that, you needed to lookup Keycloak user with
corresponding LDAP DN.
Marek
So, based on your experience in Openstack. Is there people still using
certificates with deprecated emailAddress as part of the subject DN ? If
your answer is no, we probably want to avoid an additional configuration to
enable/disable java canonical format. Otherwise, if your answer is
yes/don't know, maybe we should keep the configuration option implemented
in the PR.
The main reason for pushing this question is that from a security
perspective, using a deprecated attribute type in subject dn is not good.
Privacy concerns may apply here too where you may not want people to put
the email (sensitive) in something that is supposed to be public.
Thanks.
>
> --
> John Dennis
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:08 p.m.
What if we use the same provider in all those identity extractors? As it
stands today, it is a mix of BC and JDK.
On Wed, Feb 13, 2019 at 3:37 AM Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de> wrote:
The main point on this issue in my opinion is to have a reliable,
provider
independent DN representation.
This is not given using the currently used Java API
X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
The JavaDoc states here the result is "[...]an implementation specific
Principal object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.
I am wondering if this canonical config switch ON/OFF is the right way. It
has no effect on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical
IssuerDN using regular expression" and "Match canonical SubjectDN using
regular expression"?
The existing solutions are kept for backward compatibility but deprecated
in the documentation?
Best regards,
Sebastian
> -----Ursprüngliche Nachricht-----
> Von: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-
> bounces(a)lists.jboss.org> Im Auftrag von Pedro Igor Silva
> Gesendet: Mittwoch, 13. Februar 2019 00:03
> An: John Dennis <jdennis(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
>
> On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis(a)redhat.com> wrote:
>
> > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > the supported attributed types).
> >
> > I don't think RFC 4519 is what you're looking for, you want to be
> > looking at the X509 Certificate RFC's.
> >
> > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > other RFC's. It's ugly and hard to decipher which is probably why
> > these issues seem to keep cropping up.
> >
>
> Yes, they are ...
>
>
> >
> > > The main reason for pushing this question is that from a security
> > > perspective, using a deprecated attribute type in subject dn is not
> > > good. Privacy concerns may apply here too where you may not want
> > > people to put the email (sensitive) in something that is supposed to
be public.
> >
> > I'm not sure that's the question. You don't have control over the
> > certs that are presented to you. Rather your job is to ascertain if
> > you can unequivocally map the cert subject to a principal in your
> > domain. You probably can't put a stake in the ground and demand the
> > subject contain certain RDN's (with the exception of the CN). And FWIW
> > just to make things even more confusing a common convention for client
> > certs is to put the users email address as the subject's CN.
> >
> > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > have a developer on the Certificate Server team who I believe has an
> > even more in depth understanding and is probably more current on this
> > topic that I am (I did this work several years ago). He is Fraser
> > Tweedale <ftweedal(a)redhat.com>, perhaps you might want to open a
> > discussion with him. FWIW the Certificate Server is also written in
> > Java and he might be able to share Java code snippets with you on the
> > best way to perform these comparisons.
> >
>
> Yeah, we can not control how people are issuing certificates. I was
trying to find
> someone to say "Yeah, emailAddress is really a bad practice in subject
dn.
> People should use SAN instead".
>
> I think your contact may help here with both issues, for sure. Although
I'm
> convinced that at least the changes made in that PR are fine instead of
possibly
> breaking use cases by forcing canonicalization.
>
>
> >
> >
> > --
> > John Dennis
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:12 p.m.
The provider that generates the certificate contained in the HttpRequest ist he default
security provider of the application server. So using the same provider means using the
default provider.
That may lead to problems when the default security provider changes, as the DN format
changes at this time as well.
Von: Pedro Igor Silva <psilva(a)redhat.com>
Gesendet: Mittwoch, 13. Februar 2019 13:08
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>
Cc: jdennis(a)redhat.com; keycloak-dev(a)lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
What if we use the same provider in all those identity extractors? As it stands today, it
is a mix of BC and JDK.
On Wed, Feb 13, 2019 at 3:37 AM Lösch, Sebastian
<Sebastian.Loesch@governikus.de<mailto:Sebastian.Loesch@governikus.de>>
wrote:
The main point on this issue in my opinion is to have a reliable, provider independent
DN representation.
This is not given using the currently used Java API X509Certificate.getSubjectDN() and
X509Certificate.getIssuerDN().
The JavaDoc states here the result is "[...]an implementation specific Principal
object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.
I am wondering if this canonical config switch ON/OFF is the right way. It has no
effect on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical IssuerDN
using regular expression" and "Match canonical SubjectDN using regular
expression"?
The existing solutions are kept for backward compatibility but deprecated in the
documentation?
Best regards,
Sebastian
-----Ursprüngliche Nachricht-----
Von:
keycloak-dev-bounces@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>
<keycloak-dev-
bounces@lists.jboss.org<mailto:bounces@lists.jboss.org>> Im Auftrag von Pedro
Igor Silva
Gesendet: Mittwoch, 13. Februar 2019 00:03
An: John Dennis <jdennis@redhat.com<mailto:jdennis@redhat.com>>
Cc: keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
On Tue, Feb 12, 2019 at 8:17 PM John Dennis
<jdennis@redhat.com<mailto:jdennis@redhat.com>> wrote:
> On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > the supported attributed types).
>
> I don't think RFC 4519 is what you're looking for, you want to be
> looking at the X509 Certificate RFC's.
>
> Ugh, the RFC's for this stuff is a tangled mess of cross references to
> other RFC's. It's ugly and hard to decipher which is probably why
> these issues seem to keep cropping up.
>
Yes, they are ...
>
> > The main reason for pushing this question is that from a security
> > perspective, using a deprecated attribute type in subject dn is not
> > good. Privacy concerns may apply here too where you may not want
> > people to put the email (sensitive) in something that is supposed to be
public.
>
> I'm not sure that's the question. You don't have control over the
> certs that are presented to you. Rather your job is to ascertain if
> you can unequivocally map the cert subject to a principal in your
> domain. You probably can't put a stake in the ground and demand the
> subject contain certain RDN's (with the exception of the CN). And FWIW
> just to make things even more confusing a common convention for client
> certs is to put the users email address as the subject's CN.
>
> I have a suggestion, I'm not the ultimate authority on this stuff. We
> have a developer on the Certificate Server team who I believe has an
> even more in depth understanding and is probably more current on this
> topic that I am (I did this work several years ago). He is Fraser
> Tweedale <ftweedal@redhat.com<mailto:ftweedal@redhat.com>>, perhaps you
might want to open a
> discussion with him. FWIW the Certificate Server is also written in
> Java and he might be able to share Java code snippets with you on the
> best way to perform these comparisons.
>
Yeah, we can not control how people are issuing certificates. I was trying to find
someone to say "Yeah, emailAddress is really a bad practice in subject dn.
People should use SAN instead".
I think your contact may help here with both issues, for sure. Although I'm
convinced that at least the changes made in that PR are fine instead of possibly
breaking use cases by forcing canonicalization.
>
>
> --
> John Dennis
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:23 p.m.
I meant, use the BC API directly without depending on the installed
provider. If you look at how those identity extractors are implemented,
you'll see that some of them are using BC API. Not sure if this approach is
good though as we are removing the "portability" through JCA/JCE. In fact,
I think use BC for extracting DN will make things even more worse for the
problem discussed in the other thread ...
Back to your question, I'm OK about your PR and I'm not sure if we need
those two alternatives you proposed. The example you gave about
serialnumber does not seem to be impacted by canonicalization. Or I'm
missing something ? If others are happy too about your solution, we can
have your changes in as soon as you provide tests and docs.
Thanks.
On Wed, Feb 13, 2019 at 12:13 PM Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de> wrote:
The provider that generates the certificate contained in the
HttpRequest
ist he default security provider of the application server. So using the
same provider means using the default provider.
That may lead to problems when the default security provider changes, as
the DN format changes at this time as well.
*Von:* Pedro Igor Silva <psilva(a)redhat.com>
*Gesendet:* Mittwoch, 13. Februar 2019 13:08
*An:* Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>
*Cc:* jdennis(a)redhat.com; keycloak-dev(a)lists.jboss.org
*Betreff:* Re: [keycloak-dev] Certificate subject DN is provider dependent
What if we use the same provider in all those identity extractors? As it
stands today, it is a mix of BC and JDK.
On Wed, Feb 13, 2019 at 3:37 AM Lösch, Sebastian <
Sebastian.Loesch(a)governikus.de> wrote:
The main point on this issue in my opinion is to have a reliable, provider
independent DN representation.
This is not given using the currently used Java API
X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
The JavaDoc states here the result is "[...]an implementation specific
Principal object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.
I am wondering if this canonical config switch ON/OFF is the right way. It
has no effect on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical
IssuerDN using regular expression" and "Match canonical SubjectDN using
regular expression"?
The existing solutions are kept for backward compatibility but deprecated
in the documentation?
Best regards,
Sebastian
> -----Ursprüngliche Nachricht-----
> Von: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-
> bounces(a)lists.jboss.org> Im Auftrag von Pedro Igor Silva
> Gesendet: Mittwoch, 13. Februar 2019 00:03
> An: John Dennis <jdennis(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
>
> On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis(a)redhat.com> wrote:
>
> > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > the supported attributed types).
> >
> > I don't think RFC 4519 is what you're looking for, you want to be
> > looking at the X509 Certificate RFC's.
> >
> > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > other RFC's. It's ugly and hard to decipher which is probably why
> > these issues seem to keep cropping up.
> >
>
> Yes, they are ...
>
>
> >
> > > The main reason for pushing this question is that from a security
> > > perspective, using a deprecated attribute type in subject dn is not
> > > good. Privacy concerns may apply here too where you may not want
> > > people to put the email (sensitive) in something that is supposed to
be public.
> >
> > I'm not sure that's the question. You don't have control over the
> > certs that are presented to you. Rather your job is to ascertain if
> > you can unequivocally map the cert subject to a principal in your
> > domain. You probably can't put a stake in the ground and demand the
> > subject contain certain RDN's (with the exception of the CN). And FWIW
> > just to make things even more confusing a common convention for client
> > certs is to put the users email address as the subject's CN.
> >
> > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > have a developer on the Certificate Server team who I believe has an
> > even more in depth understanding and is probably more current on this
> > topic that I am (I did this work several years ago). He is Fraser
> > Tweedale <ftweedal(a)redhat.com>, perhaps you might want to open a
> > discussion with him. FWIW the Certificate Server is also written in
> > Java and he might be able to share Java code snippets with you on the
> > best way to perform these comparisons.
> >
>
> Yeah, we can not control how people are issuing certificates. I was
trying to find
> someone to say "Yeah, emailAddress is really a bad practice in subject
dn.
> People should use SAN instead".
>
> I think your contact may help here with both issues, for sure. Although
I'm
> convinced that at least the changes made in that PR are fine instead of
possibly
> breaking use cases by forcing canonicalization.
>
>
> >
> >
> > --
> > John Dennis
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:27 p.m.
Okay, that sound’s great! I will work on that soon.
Thanks.
Von: Pedro Igor Silva <psilva(a)redhat.com>
Gesendet: Mittwoch, 13. Februar 2019 16:24
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>
Cc: jdennis(a)redhat.com; keycloak-dev(a)lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
I meant, use the BC API directly without depending on the installed provider. If you look
at how those identity extractors are implemented, you'll see that some of them are
using BC API. Not sure if this approach is good though as we are removing the
"portability" through JCA/JCE. In fact, I think use BC for extracting DN will
make things even more worse for the problem discussed in the other thread ...
Back to your question, I'm OK about your PR and I'm not sure if we need those two
alternatives you proposed. The example you gave about serialnumber does not seem to be
impacted by canonicalization. Or I'm missing something ? If others are happy too about
your solution, we can have your changes in as soon as you provide tests and docs.
Thanks.
On Wed, Feb 13, 2019 at 12:13 PM Lösch, Sebastian <Sebastian.Loesch(a)governikus.de
<mailto:Sebastian.Loesch@governikus.de> > wrote:
The provider that generates the certificate contained in the HttpRequest ist he default
security provider of the application server. So using the same provider means using the
default provider.
That may lead to problems when the default security provider changes, as the DN format
changes at this time as well.
Von: Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com> >
Gesendet: Mittwoch, 13. Februar 2019 13:08
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de
<mailto:Sebastian.Loesch@governikus.de> >
Cc: jdennis(a)redhat.com <mailto:jdennis@redhat.com> ; keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
What if we use the same provider in all those identity extractors? As it stands today, it
is a mix of BC and JDK.
On Wed, Feb 13, 2019 at 3:37 AM Lösch, Sebastian <Sebastian.Loesch(a)governikus.de
<mailto:Sebastian.Loesch@governikus.de> > wrote:
The main point on this issue in my opinion is to have a reliable, provider independent DN
representation.
This is not given using the currently used Java API X509Certificate.getSubjectDN() and
X509Certificate.getIssuerDN().
The JavaDoc states here the result is "[...]an implementation specific Principal
object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.
I am wondering if this canonical config switch ON/OFF is the right way. It has no effect
on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical IssuerDN
using regular expression" and "Match canonical SubjectDN using regular
expression"?
The existing solutions are kept for backward compatibility but deprecated in the
documentation?
Best regards,
Sebastian
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org> <keycloak-dev-
bounces(a)lists.jboss.org <mailto:bounces@lists.jboss.org> > Im Auftrag von Pedro
Igor Silva
Gesendet: Mittwoch, 13. Februar 2019 00:03
An: John Dennis <jdennis(a)redhat.com <mailto:jdennis@redhat.com> >
Cc: keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis(a)redhat.com
<mailto:jdennis@redhat.com> > wrote:
> On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > the supported attributed types).
>
> I don't think RFC 4519 is what you're looking for, you want to be
> looking at the X509 Certificate RFC's.
>
> Ugh, the RFC's for this stuff is a tangled mess of cross references to
> other RFC's. It's ugly and hard to decipher which is probably why
> these issues seem to keep cropping up.
>
Yes, they are ...
>
> > The main reason for pushing this question is that from a security
> > perspective, using a deprecated attribute type in subject dn is not
> > good. Privacy concerns may apply here too where you may not want
> > people to put the email (sensitive) in something that is supposed to be
public.
>
> I'm not sure that's the question. You don't have control over the
> certs that are presented to you. Rather your job is to ascertain if
> you can unequivocally map the cert subject to a principal in your
> domain. You probably can't put a stake in the ground and demand the
> subject contain certain RDN's (with the exception of the CN). And FWIW
> just to make things even more confusing a common convention for client
> certs is to put the users email address as the subject's CN.
>
> I have a suggestion, I'm not the ultimate authority on this stuff. We
> have a developer on the Certificate Server team who I believe has an
> even more in depth understanding and is probably more current on this
> topic that I am (I did this work several years ago). He is Fraser
> Tweedale <ftweedal(a)redhat.com <mailto:ftweedal@redhat.com> >, perhaps
you might want to open a
> discussion with him. FWIW the Certificate Server is also written in
> Java and he might be able to share Java code snippets with you on the
> best way to perform these comparisons.
>
Yeah, we can not control how people are issuing certificates. I was trying to find
someone to say "Yeah, emailAddress is really a bad practice in subject dn.
People should use SAN instead".
I think your contact may help here with both issues, for sure. Although I'm
convinced that at least the changes made in that PR are fine instead of possibly
breaking use cases by forcing canonicalization.
>
>
> --
> John Dennis
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:01 p.m.
Hello devs,
I implemented tests and added documentation. So please have a look if something is
missing:
https://github.com/keycloak/keycloak/pull/5878
https://github.com/keycloak/keycloak-documentation/pull/587
Best regards,
Sebastian
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-
bounces(a)lists.jboss.org> Im Auftrag von Lösch, Sebastian
Gesendet: Mittwoch, 13. Februar 2019 16:27
An: psilva(a)redhat.com
Cc: keycloak-dev(a)lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
Okay, that sound’s great! I will work on that soon.
Thanks.
Von: Pedro Igor Silva <psilva(a)redhat.com>
Gesendet: Mittwoch, 13. Februar 2019 16:24
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>
Cc: jdennis(a)redhat.com; keycloak-dev(a)lists.jboss.org
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
I meant, use the BC API directly without depending on the installed provider.
If you look at how those identity extractors are implemented, you'll see that
some of them are using BC API. Not sure if this approach is good though as
we are removing the "portability" through JCA/JCE. In fact, I think use BC for
extracting DN will make things even more worse for the problem discussed in
the other thread ...
Back to your question, I'm OK about your PR and I'm not sure if we need
those two alternatives you proposed. The example you gave about
serialnumber does not seem to be impacted by canonicalization. Or I'm
missing something ? If others are happy too about your solution, we can
have your changes in as soon as you provide tests and docs.
Thanks.
On Wed, Feb 13, 2019 at 12:13 PM Lösch, Sebastian
<Sebastian.Loesch(a)governikus.de
<mailto:Sebastian.Loesch@governikus.de> > wrote:
The provider that generates the certificate contained in the HttpRequest ist
he default security provider of the application server. So using the same
provider means using the default provider.
That may lead to problems when the default security provider changes, as
the DN format changes at this time as well.
Von: Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com> >
Gesendet: Mittwoch, 13. Februar 2019 13:08
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de
<mailto:Sebastian.Loesch@governikus.de> >
Cc: jdennis(a)redhat.com <mailto:jdennis@redhat.com> ; keycloak-
dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
What if we use the same provider in all those identity extractors? As it stands
today, it is a mix of BC and JDK.
On Wed, Feb 13, 2019 at 3:37 AM Lösch, Sebastian
<Sebastian.Loesch(a)governikus.de
<mailto:Sebastian.Loesch@governikus.de> > wrote:
The main point on this issue in my opinion is to have a reliable, provider
independent DN representation.
This is not given using the currently used Java API
X509Certificate.getSubjectDN() and X509Certificate.getIssuerDN().
The JavaDoc states here the result is "[...]an implementation specific Principal
object, which should not be relied upon by portable code."
So I think providing an alternative is necessary.
I am wondering if this canonical config switch ON/OFF is the right way. It has
no effect on all other user identity source, e.g. serial number.
Wouldn't it be better to implement two alternatives "Match canonical
IssuerDN using regular expression" and "Match canonical SubjectDN using
regular expression"?
The existing solutions are kept for backward compatibility but deprecated in
the documentation?
Best regards,
Sebastian
> -----Ursprüngliche Nachricht-----
> Von: keycloak-dev-bounces(a)lists.jboss.org <mailto:keycloak-dev-
bounces(a)lists.jboss.org> <keycloak-dev-
> bounces(a)lists.jboss.org <mailto:bounces@lists.jboss.org> > Im Auftrag
von Pedro Igor Silva
> Gesendet: Mittwoch, 13. Februar 2019 00:03
> An: John Dennis <jdennis(a)redhat.com <mailto:jdennis@redhat.com> >
> Cc: keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> Betreff: Re: [keycloak-dev] Certificate subject DN is provider dependent
>
> On Tue, Feb 12, 2019 at 8:17 PM John Dennis <jdennis(a)redhat.com
<mailto:jdennis@redhat.com> > wrote:
>
> > On 2/12/19 4:26 PM, Pedro Igor Silva wrote:
> > > Sure, but note that RFC-4514 relies on 4519 (which actually defines
> > > the supported attributed types).
> >
> > I don't think RFC 4519 is what you're looking for, you want to be
> > looking at the X509 Certificate RFC's.
> >
> > Ugh, the RFC's for this stuff is a tangled mess of cross references to
> > other RFC's. It's ugly and hard to decipher which is probably why
> > these issues seem to keep cropping up.
> >
>
> Yes, they are ...
>
>
> >
> > > The main reason for pushing this question is that from a security
> > > perspective, using a deprecated attribute type in subject dn is not
> > > good. Privacy concerns may apply here too where you may not want
> > > people to put the email (sensitive) in something that is supposed to be
public.
> >
> > I'm not sure that's the question. You don't have control over the
> > certs that are presented to you. Rather your job is to ascertain if
> > you can unequivocally map the cert subject to a principal in your
> > domain. You probably can't put a stake in the ground and demand the
> > subject contain certain RDN's (with the exception of the CN). And FWIW
> > just to make things even more confusing a common convention for client
> > certs is to put the users email address as the subject's CN.
> >
> > I have a suggestion, I'm not the ultimate authority on this stuff. We
> > have a developer on the Certificate Server team who I believe has an
> > even more in depth understanding and is probably more current on this
> > topic that I am (I did this work several years ago). He is Fraser
> > Tweedale <ftweedal(a)redhat.com <mailto:ftweedal@redhat.com> >,
perhaps you might want to open a
> > discussion with him. FWIW the Certificate Server is also written in
> > Java and he might be able to share Java code snippets with you on the
> > best way to perform these comparisons.
> >
>
> Yeah, we can not control how people are issuing certificates. I was trying to
find
> someone to say "Yeah, emailAddress is really a bad practice in subject dn.
> People should use SAN instead".
>
> I think your contact may help here with both issues, for sure. Although I'm
> convinced that at least the changes made in that PR are fine instead of
possibly
> breaking use cases by forcing canonicalization.
>
>
> >
> >
> > --
> > John Dennis
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
1905
days inactive
1907
days old
23 comments
6 participants
participants (6)
-
Hynek Mlnarik -
John Dennis -
Lösch, Sebastian -
Marek Posolda -
Pedro Igor Silva -
Thomas Darimont