[keycloak-dev] Certificate subject DN is provider dependent

[Pedro Igor Silva]

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> 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 <keycloak-dev-
> > 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>
> > Cc: 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> 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>, 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
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>