[keycloak-dev] X.509 Authenticator - New User Identity Source

[Marek Posolda]

Hi Martin,

On 02/07/2019 20:47, Martin Maher wrote:
> Marek:
>
> I am relatively new to this list, but I would like to respond to your conjecture about the use of “Issuer’s Common Name”.
>
> I can envision a use case within the 802.1x authentication model, specifically with EAP-TLS and EAP-TTLS, where the “Issuer’s Common Name” would be very functional as a “hint” towards the correct issuing CA against which to perform client authenticity validation.  This method would primarily be utilized where there is a hierarchical organization to the issuer CAs in an organization, by which policy could be applied based on the type of device presenting the certificate.
>
> Arguably, you are correct that “Issuer’s Common Name” would not be useful in establishing uniqueness of the presenting client, but it’s more like asking a lost child who their parents are, versus asking the child who the child is.

I agree that "Issuer's Common Name" is useful as a hint towards the 
correct issuing CA and have the knowledge of it has some benefits. 
However the proposal is to remove "Issuer's Common Name" from the list 
of sources to uniquely identify users.

To clarify, if you currently select "Issuer's Common Name" as a User 
Identity Source, it means that every user in Keycloak needs to have 
X.509 certificate with unique issuer. In other words, every user must 
have his own CA. This is kind of setup, which doesn't have too much 
sense for me and I doubt anyone can really use it in production. Hence 
the proposal of remove it. Same applies of "Issuer's email" .

Marek

>
> Hope this helps,
>
> Martin
>
>> On Jul 2, 2019, at 09:38 , Marek Posolda <mposolda at redhat.com> wrote:
>>
>>
>> On 02/07/2019 16:38, Nemanja Hiršl wrote:
>>> Hi,
>>>
>>> Current implementation of X.509 Authenticator uses a number of
>>> different mappings of a certificate to user identity.
>>> None of provided mappings can guarantee uniqueness. It is up to CA to
>>> choose which fields to include in SubjectDN and SAN and there might be
>>> some unique data. In these cases we can use provided mappers to
>>> identify users. However, if there's a need to support certificates
>>> from different CAs, with unrelated usage of SubjectDN and SAN fields
>>> those mappers are not sufficient.
>>>
>>> One way to uniquely identify user is to use certificate thumbprint.
>>> For the solution I'm working on, we have implemented SHA256-Thumbprint
>>> mapper and it is giving us expected results.
>>>
>>> Do you think sha256 thumbprint mapper would be a useful addition to
>>> already existing mappers?
>>> Should I prepare appropriate PR?
>>>
>>> The other approach might be combination of serial number and issuer.
>>> According to RFC 5280 the issuer name and serial number identify a
>>> unique certificate.This is something I haven't tried, but would like
>>> to hear your opinion.
>> +1 for the serial number + Issuer DN.
>>
>> I would vote also for remove "Issuer's email" and "Issuer's Common Name"
>> as I can't imagine that those can be ever used to uniquely identify
>> subject and I doubt that someone is using this in production for
>> uniquely identify user?
>>
>> Adding Peter Nalyvayko to CC as I believe he was the original author who
>> added those. Peter, feel free to correct me if I am wrong :)
>>
>> Thanks,
>> Marek
>>
>>> Thanks.
>>>
>>> References:
>>> 1. There's a nice explanation on stackoveroflow of what can be used to
>>> uniquely identify users:
>>> https://stackoverflow.com/questions/5290571/which-parts-of-the-client-certificate-to-use-when-uniquely-identifying-users
>>> 2. There's also a discussion here:
>>> https://issues.jboss.org/browse/KEYCLOAK-9610
>>> 3. RFC 5280: https://tools.ietf.org/html/rfc5280#section-4.1.2.2
>>>
>>>
>>> Best regards,
>>> Nemanja
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev