4:38 p.m.
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.
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-cer...
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
6:38 p.m.
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-cer...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:47 p.m.
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.
Hope this helps,
Martin
On Jul 2, 2019, at 09:38 , Marek Posolda <mposolda(a)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-cer...
> 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(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:14 a.m.
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(a)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-cer...
>> 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(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
3:32 p.m.
Marek:
Thank you for your patient explanation. I understand what you have explained. I would
agree your proposal under those terms.
I think that potentially the only way for every user to have unique Issuer information is
in a system populated entirely with self-signed certificates.
Thank you again.
Regards,
Martin
Sent from a very small keyboard, by very large thumbs
On Jul 2, 2019, at 23:14, Marek Posolda <mposolda(a)redhat.com>
wrote:
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(a)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-cer...
>>> 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(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
12:20 a.m.
Hi Marek,
I believe in the original version the regular expression was the only mapper provided out
of the box to parse the unique identity from the subject's DN. Adding the x500
mappers (email, etc.) came up, if I recall correctly, during the PR discussion, but I
could be wrong.
None of provided mappings can guarantee uniqueness.
For on-premise deployments having a simple mapping (email from x509 cert) may be
sufficient as long as there is a single trusted CA.
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?
+1 I am not aware of any of our clients using the issuer's mappers.
Cheers,
Peter
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On
Behalf Of Marek Posolda
Sent: Tuesday, July 2, 2019 12:38 PM
To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>; keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] X.509 Authenticator - New User Identity Source
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(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:16 a.m.
On 03/07/2019 00:20, Nalyvayko, Peter wrote:
Hi Marek,
I believe in the original version the regular expression was the only mapper provided out
of the box to parse the unique identity from the subject's DN. Adding the x500
mappers (email, etc.) came up, if I recall correctly, during the PR discussion, but I
could be wrong.
Cool, Thanks for clarifying.
I think that when we add "Issuer's DN + serial number" combination, we
can remove "Issuer's email" and "Issuer's Common Name" .
Marek
> None of provided mappings can guarantee uniqueness.
For on-premise deployments having a simple mapping (email from x509 cert) may be
sufficient as long as there is a single trusted CA.
> 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?
+1 I am not aware of any of our clients using the issuer's mappers.
Cheers,
Peter
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org>
On Behalf Of Marek Posolda
Sent: Tuesday, July 2, 2019 12:38 PM
To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>; keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] X.509 Authenticator - New User Identity Source
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(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
10:34 a.m.
On 7/3/19 8:16 AM, Marek Posolda wrote:
On 03/07/2019 00:20, Nalyvayko, Peter wrote:
> Hi Marek,
>
>
> I believe in the original version the regular expression was the only
> mapper provided out of the box to parse the unique identity from the
> subject's DN. Adding the x500 mappers (email, etc.) came up, if I
> recall correctly, during the PR discussion, but I could be wrong.
Cool, Thanks for clarifying.
I think that when we add "Issuer's DN + serial number" combination, we
can remove "Issuer's email" and "Issuer's Common Name" .
Thanks.
I'll try to prepare PR in a next couple of days to remove "Issuer's
email", "Issuer's Common Name" and add "Issuer's DN and serial
number"
Best regards,
Nemanja
Marek
>
>> None of provided mappings can guarantee uniqueness.
> For on-premise deployments having a simple mapping (email from x509
> cert) may be sufficient as long as there is a single trusted CA.
>
>> 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?
> +1 I am not aware of any of our clients using the issuer's mappers.
>
> Cheers,
>
> Peter
>
> -----Original Message-----
> From: keycloak-dev-bounces(a)lists.jboss.org
> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
> Sent: Tuesday, July 2, 2019 12:38 PM
> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
> keycloak-dev(a)lists.jboss.org
> Subject: Re: [keycloak-dev] X.509 Authenticator - New User Identity
> Source
>
>
> 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(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
10:41 a.m.
Thanks!
Marek
On 03/07/2019 10:34, Nemanja Hiršl wrote:
On 7/3/19 8:16 AM, Marek Posolda wrote:
> On 03/07/2019 00:20, Nalyvayko, Peter wrote:
>> Hi Marek,
>>
>>
>> I believe in the original version the regular expression was the
>> only mapper provided out of the box to parse the unique identity
>> from the subject's DN. Adding the x500 mappers (email, etc.) came
>> up, if I recall correctly, during the PR discussion, but I could be
>> wrong.
>
> Cool, Thanks for clarifying.
>
> I think that when we add "Issuer's DN + serial number" combination,
> we can remove "Issuer's email" and "Issuer's Common Name"
.
>
Thanks.
I'll try to prepare PR in a next couple of days to remove "Issuer's
email", "Issuer's Common Name" and add "Issuer's DN and
serial number"
Best regards,
Nemanja
> Marek
>
>>
>>> None of provided mappings can guarantee uniqueness.
>> For on-premise deployments having a simple mapping (email from x509
>> cert) may be sufficient as long as there is a single trusted CA.
>>
>>> 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?
>> +1 I am not aware of any of our clients using the issuer's mappers.
>>
>> Cheers,
>>
>> Peter
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces(a)lists.jboss.org
>> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
>> Sent: Tuesday, July 2, 2019 12:38 PM
>> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
>> keycloak-dev(a)lists.jboss.org
>> Subject: Re: [keycloak-dev] X.509 Authenticator - New User Identity
>> Source
>>
>>
>> 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(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
>
>
2:44 p.m.
Hi Marek,
After having some troubles in resolving merge conflicts, I've finally
filed new PR: https://github.com/keycloak/keycloak/pull/6153
Please take a look when you have time.
Thanks.
Best regards,
Nemanja
On 7/3/19 10:41 AM, Marek Posolda wrote:
Thanks!
Marek
On 03/07/2019 10:34, Nemanja Hiršl wrote:
> On 7/3/19 8:16 AM, Marek Posolda wrote:
>> On 03/07/2019 00:20, Nalyvayko, Peter wrote:
>>> Hi Marek,
>>>
>>>
>>> I believe in the original version the regular expression was the
>>> only mapper provided out of the box to parse the unique identity
>>> from the subject's DN. Adding the x500 mappers (email, etc.) came
>>> up, if I recall correctly, during the PR discussion, but I could be
>>> wrong.
>>
>> Cool, Thanks for clarifying.
>>
>> I think that when we add "Issuer's DN + serial number" combination,
>> we can remove "Issuer's email" and "Issuer's Common
Name" .
>>
>
> Thanks.
> I'll try to prepare PR in a next couple of days to remove "Issuer's
> email", "Issuer's Common Name" and add "Issuer's DN and
serial number"
>
>
> Best regards,
> Nemanja
>
>> Marek
>>
>>>
>>>> None of provided mappings can guarantee uniqueness.
>>> For on-premise deployments having a simple mapping (email from x509
>>> cert) may be sufficient as long as there is a single trusted CA.
>>>
>>>> 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?
>>> +1 I am not aware of any of our clients using the issuer's mappers.
>>>
>>> Cheers,
>>>
>>> Peter
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces(a)lists.jboss.org
>>> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
>>> Sent: Tuesday, July 2, 2019 12:38 PM
>>> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
>>> keycloak-dev(a)lists.jboss.org
>>> Subject: Re: [keycloak-dev] X.509 Authenticator - New User Identity
>>> Source
>>>
>>>
>>> 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(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
>>
>>
>
12:45 p.m.
Hi,
did you get a chance to look into this PR?
If there's something wrong with code/logic, I'll be happy to rework
it.... Just let me know.
Best regards,
Nemanja
On 7/8/19 2:44 PM, Nemanja Hiršl wrote:
Hi Marek,
After having some troubles in resolving merge conflicts, I've finally
filed new PR: https://github.com/keycloak/keycloak/pull/6153
Please take a look when you have time.
Thanks.
Best regards,
Nemanja
On 7/3/19 10:41 AM, Marek Posolda wrote:
> Thanks!
>
> Marek
>
> On 03/07/2019 10:34, Nemanja Hiršl wrote:
>> On 7/3/19 8:16 AM, Marek Posolda wrote:
>>> On 03/07/2019 00:20, Nalyvayko, Peter wrote:
>>>> Hi Marek,
>>>>
>>>>
>>>> I believe in the original version the regular expression was the
>>>> only mapper provided out of the box to parse the unique identity
>>>> from the subject's DN. Adding the x500 mappers (email, etc.) came
>>>> up, if I recall correctly, during the PR discussion, but I could
>>>> be wrong.
>>>
>>> Cool, Thanks for clarifying.
>>>
>>> I think that when we add "Issuer's DN + serial number"
combination,
>>> we can remove "Issuer's email" and "Issuer's Common
Name" .
>>>
>>
>> Thanks.
>> I'll try to prepare PR in a next couple of days to remove "Issuer's
>> email", "Issuer's Common Name" and add "Issuer's DN
and serial number"
>>
>>
>> Best regards,
>> Nemanja
>>
>>> Marek
>>>
>>>>
>>>>> None of provided mappings can guarantee uniqueness.
>>>> For on-premise deployments having a simple mapping (email from
>>>> x509 cert) may be sufficient as long as there is a single trusted CA.
>>>>
>>>>> 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?
>>>> +1 I am not aware of any of our clients using the issuer's mappers.
>>>>
>>>> Cheers,
>>>>
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: keycloak-dev-bounces(a)lists.jboss.org
>>>> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek Posolda
>>>> Sent: Tuesday, July 2, 2019 12:38 PM
>>>> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
>>>> keycloak-dev(a)lists.jboss.org
>>>> Subject: Re: [keycloak-dev] X.509 Authenticator - New User
>>>> Identity Source
>>>>
>>>>
>>>> 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(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
5:18 p.m.
Hi,
I've just did a review of your PR and added few minor comments. Sorry
for the delay. Thanks for your contribution.
Marek
On 21. 07. 19 12:45, Nemanja Hiršl wrote:
Hi,
did you get a chance to look into this PR?
If there's something wrong with code/logic, I'll be happy to rework
it.... Just let me know.
Best regards,
Nemanja
On 7/8/19 2:44 PM, Nemanja Hiršl wrote:
> Hi Marek,
>
> After having some troubles in resolving merge conflicts, I've finally
> filed new PR: https://github.com/keycloak/keycloak/pull/6153
> Please take a look when you have time.
> Thanks.
>
> Best regards,
> Nemanja
>
> On 7/3/19 10:41 AM, Marek Posolda wrote:
>> Thanks!
>>
>> Marek
>>
>> On 03/07/2019 10:34, Nemanja Hiršl wrote:
>>> On 7/3/19 8:16 AM, Marek Posolda wrote:
>>>> On 03/07/2019 00:20, Nalyvayko, Peter wrote:
>>>>> Hi Marek,
>>>>>
>>>>>
>>>>> I believe in the original version the regular expression was the
>>>>> only mapper provided out of the box to parse the unique identity
>>>>> from the subject's DN. Adding the x500 mappers (email, etc.) came
>>>>> up, if I recall correctly, during the PR discussion, but I could
>>>>> be wrong.
>>>>
>>>> Cool, Thanks for clarifying.
>>>>
>>>> I think that when we add "Issuer's DN + serial number"
>>>> combination, we can remove "Issuer's email" and
"Issuer's Common
>>>> Name" .
>>>>
>>>
>>> Thanks.
>>> I'll try to prepare PR in a next couple of days to remove
"Issuer's
>>> email", "Issuer's Common Name" and add "Issuer's
DN and serial number"
>>>
>>>
>>> Best regards,
>>> Nemanja
>>>
>>>> Marek
>>>>
>>>>>
>>>>>> None of provided mappings can guarantee uniqueness.
>>>>> For on-premise deployments having a simple mapping (email from
>>>>> x509 cert) may be sufficient as long as there is a single trusted
>>>>> CA.
>>>>>
>>>>>> 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?
>>>>> +1 I am not aware of any of our clients using the issuer's
mappers.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter
>>>>>
>>>>> -----Original Message-----
>>>>> From: keycloak-dev-bounces(a)lists.jboss.org
>>>>> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek
Posolda
>>>>> Sent: Tuesday, July 2, 2019 12:38 PM
>>>>> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> Subject: Re: [keycloak-dev] X.509 Authenticator - New User
>>>>> Identity Source
>>>>>
>>>>>
>>>>> 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(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
1:51 p.m.
Thanks, Marek,
No worries.
I'll update this PR according to comments and prepare new documentation
PR sometime next week.
Best regards,
Nemanja
On 8/8/19 5:18 PM, Marek Posolda wrote:
Hi,
I've just did a review of your PR and added few minor comments. Sorry
for the delay. Thanks for your contribution.
Marek
On 21. 07. 19 12:45, Nemanja Hiršl wrote:
> Hi,
>
> did you get a chance to look into this PR?
> If there's something wrong with code/logic, I'll be happy to rework
> it.... Just let me know.
>
> Best regards,
> Nemanja
>
> On 7/8/19 2:44 PM, Nemanja Hiršl wrote:
>> Hi Marek,
>>
>> After having some troubles in resolving merge conflicts, I've
>> finally filed new PR: https://github.com/keycloak/keycloak/pull/6153
>> Please take a look when you have time.
>> Thanks.
>>
>> Best regards,
>> Nemanja
>>
>> On 7/3/19 10:41 AM, Marek Posolda wrote:
>>> Thanks!
>>>
>>> Marek
>>>
>>> On 03/07/2019 10:34, Nemanja Hiršl wrote:
>>>> On 7/3/19 8:16 AM, Marek Posolda wrote:
>>>>> On 03/07/2019 00:20, Nalyvayko, Peter wrote:
>>>>>> Hi Marek,
>>>>>>
>>>>>>
>>>>>> I believe in the original version the regular expression was the
>>>>>> only mapper provided out of the box to parse the unique
>>>>>> identity from the subject's DN. Adding the x500 mappers
(email,
>>>>>> etc.) came up, if I recall correctly, during the PR discussion,
>>>>>> but I could be wrong.
>>>>>
>>>>> Cool, Thanks for clarifying.
>>>>>
>>>>> I think that when we add "Issuer's DN + serial number"
>>>>> combination, we can remove "Issuer's email" and
"Issuer's Common
>>>>> Name" .
>>>>>
>>>>
>>>> Thanks.
>>>> I'll try to prepare PR in a next couple of days to remove
>>>> "Issuer's email", "Issuer's Common Name" and
add "Issuer's DN and
>>>> serial number"
>>>>
>>>>
>>>> Best regards,
>>>> Nemanja
>>>>
>>>>> Marek
>>>>>
>>>>>>
>>>>>>> None of provided mappings can guarantee uniqueness.
>>>>>> For on-premise deployments having a simple mapping (email from
>>>>>> x509 cert) may be sufficient as long as there is a single
>>>>>> trusted CA.
>>>>>>
>>>>>>> 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?
>>>>>> +1 I am not aware of any of our clients using the issuer's
mappers.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: keycloak-dev-bounces(a)lists.jboss.org
>>>>>> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Marek
Posolda
>>>>>> Sent: Tuesday, July 2, 2019 12:38 PM
>>>>>> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> Subject: Re: [keycloak-dev] X.509 Authenticator - New User
>>>>>> Identity Source
>>>>>>
>>>>>>
>>>>>> 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(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
>
3:57 p.m.
Thanks!
Marek
On 09. 08. 19 13:51, Nemanja Hiršl wrote:
Thanks, Marek,
No worries.
I'll update this PR according to comments and prepare new
documentation PR sometime next week.
Best regards,
Nemanja
On 8/8/19 5:18 PM, Marek Posolda wrote:
> Hi,
>
> I've just did a review of your PR and added few minor comments. Sorry
> for the delay. Thanks for your contribution.
>
> Marek
>
> On 21. 07. 19 12:45, Nemanja Hiršl wrote:
>> Hi,
>>
>> did you get a chance to look into this PR?
>> If there's something wrong with code/logic, I'll be happy to rework
>> it.... Just let me know.
>>
>> Best regards,
>> Nemanja
>>
>> On 7/8/19 2:44 PM, Nemanja Hiršl wrote:
>>> Hi Marek,
>>>
>>> After having some troubles in resolving merge conflicts, I've
>>> finally filed new PR: https://github.com/keycloak/keycloak/pull/6153
>>> Please take a look when you have time.
>>> Thanks.
>>>
>>> Best regards,
>>> Nemanja
>>>
>>> On 7/3/19 10:41 AM, Marek Posolda wrote:
>>>> Thanks!
>>>>
>>>> Marek
>>>>
>>>> On 03/07/2019 10:34, Nemanja Hiršl wrote:
>>>>> On 7/3/19 8:16 AM, Marek Posolda wrote:
>>>>>> On 03/07/2019 00:20, Nalyvayko, Peter wrote:
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>>
>>>>>>> I believe in the original version the regular expression was
>>>>>>> the only mapper provided out of the box to parse the unique
>>>>>>> identity from the subject's DN. Adding the x500 mappers
(email,
>>>>>>> etc.) came up, if I recall correctly, during the PR
discussion,
>>>>>>> but I could be wrong.
>>>>>>
>>>>>> Cool, Thanks for clarifying.
>>>>>>
>>>>>> I think that when we add "Issuer's DN + serial
number"
>>>>>> combination, we can remove "Issuer's email" and
"Issuer's Common
>>>>>> Name" .
>>>>>>
>>>>>
>>>>> Thanks.
>>>>> I'll try to prepare PR in a next couple of days to remove
>>>>> "Issuer's email", "Issuer's Common Name"
and add "Issuer's DN and
>>>>> serial number"
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Nemanja
>>>>>
>>>>>> Marek
>>>>>>
>>>>>>>
>>>>>>>> None of provided mappings can guarantee uniqueness.
>>>>>>> For on-premise deployments having a simple mapping (email
from
>>>>>>> x509 cert) may be sufficient as long as there is a single
>>>>>>> trusted CA.
>>>>>>>
>>>>>>>> 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?
>>>>>>> +1 I am not aware of any of our clients using the
issuer's
>>>>>>> mappers.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: keycloak-dev-bounces(a)lists.jboss.org
>>>>>>> <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of
Marek Posolda
>>>>>>> Sent: Tuesday, July 2, 2019 12:38 PM
>>>>>>> To: Nemanja Hiršl <nemanja.hirsl(a)netsetglobal.rs>;
>>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>>> Subject: Re: [keycloak-dev] X.509 Authenticator - New User
>>>>>>> Identity Source
>>>>>>>
>>>>>>>
>>>>>>> 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(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
>>
>
1715
days inactive
1753
days old
13 comments
4 participants
participants (4)
-
Marek Posolda -
Martin Maher -
Nalyvayko, Peter -
Nemanja Hiršl