[keycloak-dev] Certificate subject DN is provider dependent

Wed Feb 13 10:27:28 EST 2019

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