[keycloak-dev] Certificate subject DN is provider dependent

Thu Feb 14 10:01:13 EST 2019

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 at lists.jboss.org <keycloak-dev-
> bounces at lists.jboss.org> Im Auftrag von Lösch, Sebastian
> Gesendet: Mittwoch, 13. Februar 2019 16:27
> An: psilva at redhat.com
> Cc: keycloak-dev at 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 at redhat.com>
> Gesendet: Mittwoch, 13. Februar 2019 16:24
> An: Lösch, Sebastian <Sebastian.Loesch at governikus.de>
> Cc: jdennis at redhat.com; keycloak-dev at 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 at governikus.de
> <mailto:Sebastian.Loesch at 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 at redhat.com <mailto:psilva at redhat.com> >
> Gesendet: Mittwoch, 13. Februar 2019 13:08
> An: Lösch, Sebastian <Sebastian.Loesch at governikus.de
> <mailto:Sebastian.Loesch at governikus.de> >
> Cc: jdennis at redhat.com <mailto:jdennis at redhat.com> ; keycloak-
> dev at lists.jboss.org <mailto:keycloak-dev at 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 at governikus.de
> <mailto:Sebastian.Loesch at 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 at lists.jboss.org <mailto:keycloak-dev-
> bounces at lists.jboss.org>  <keycloak-dev-
> > bounces at lists.jboss.org <mailto:bounces at lists.jboss.org> > Im Auftrag
> von Pedro Igor Silva
> > Gesendet: Mittwoch, 13. Februar 2019 00:03
> > An: John Dennis <jdennis at redhat.com <mailto:jdennis at redhat.com> >
> > Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at 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 at redhat.com
> <mailto:jdennis at 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 at redhat.com <mailto:ftweedal at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev