Hey all! I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object. Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character. In addition to that, the whole certificate of the user is also available in another LDAP attribute. I currently see the following options to implement a solution for this: 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below) 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors. For both approaches two different implementations come to my mind: a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity. b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity. We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful. Do you have any advice on which way to go here? [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java... [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java... Regards Sven-Torben _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hey all! I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object. Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character. In addition to that, the whole certificate of the user is also available in another LDAP attribute. I currently see the following options to implement a solution for this: 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below) 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors. For both approaches two different implementations come to my mind: a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity. b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity. We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful. Do you have any advice on which way to go here? [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/java... [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/java... Regards Sven-Torben _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hey all! I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object. Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character. In addition to that, the whole certificate of the user is also available in another LDAP attribute. I currently see the following options to implement a solution for this: 1) Writing a custom Authenticator to handle that specific situation. This one would look very similar to the ootb X509 authenticator, but implements either a) or b) (see below) 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors. For both approaches two different implementations come to my mind: a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity. b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity. We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful. Do you have any advice on which way to go here? [1]https://github.com/keycloak/keycloak/blob/master/services/src/main/ java/org/keycloak/authentication/authenticators/x509/UserIdentityExtra ctor.java [2]https://github.com/keycloak/keycloak/blob/master/services/src/main/ java/org/keycloak/authentication/authenticators/x509/UserIdentityToMod elMapper.java#L57 Regards Sven-Torben _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi Marek, I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation. Regarding, solution b), yes that is what I thought about (with or without the initial/final lines). Sven-Torben -----Ursprüngliche Nachricht----- Von: Marek Posolda <mposolda(a)redhat.com&gt; Gesendet: Donnerstag, 21. März 2019 10:54 An: Sven-Torben Janus <sven-torben.janus(a)conciso.de>; keycloak-dev(a)lists.jboss.org Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple values Hi, The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )? Marek On 21/03/2019 07:48, Sven-Torben Janus wrote: > Hey all! > > I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object. > > Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character. > In addition to that, the whole certificate of the user is also available in another LDAP attribute. > > I currently see the following options to implement a solution for this: > 1) Writing a custom Authenticator to handle that specific situation. > This one would look very similar to the ootb X509 authenticator, but > implements either a) or b) (see below) > 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors. > > For both approaches two different implementations come to my mind: > > a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity. > b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity. > > We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful. > > Do you have any advice on which way to go here? > > [1]https://github.com/keycloak/keycloak/blob/master/services/src/main > /java/org/keycloak/authentication/authenticators/x509/UserIdentityExt > ractor.java > [2]https://github.com/keycloak/keycloak/blob/master/services/src/main > /java/org/keycloak/authentication/authenticators/x509/UserIdentityToM > odelMapper.java#L57 > > Regards > Sven-Torben > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hey Marek, as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e9...).

IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right?

Regards Sven-Torben -----Ursprüngliche Nachricht----- Von: Marek Posolda <mposolda(a)redhat.com&gt; Gesendet: Freitag, 22. März 2019 10:20 An: Sven-Torben Janus <sven-torben.janus(a)conciso.de>; keycloak-dev(a)lists.jboss.org Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values Thanks for the clarification TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it. Marek On 21/03/2019 17:18, Sven-Torben Janus wrote: > Hi Marek, > > I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation. > Regarding, solution b), yes that is what I thought about (with or without the initial/final lines). > > Sven-Torben > > -----Ursprüngliche Nachricht----- > Von: Marek Posolda <mposolda(a)redhat.com&gt; > Gesendet: Donnerstag, 21. März 2019 10:54 > An: Sven-Torben Janus <sven-torben.janus(a)conciso.de>; > keycloak-dev(a)lists.jboss.org > Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple > values > > Hi, > > The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )? > > Marek > > On 21/03/2019 07:48, Sven-Torben Janus wrote: >> Hey all! >> >> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object. >> >> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character. >> In addition to that, the whole certificate of the user is also available in another LDAP attribute. >> >> I currently see the following options to implement a solution for this: >> 1) Writing a custom Authenticator to handle that specific situation. >> This one would look very similar to the ootb X509 authenticator, but >> implements either a) or b) (see below) >> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors. >> >> For both approaches two different implementations come to my mind: >> >> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity. >> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity. >> >> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful. >> >> Do you have any advice on which way to go here? >> >> [1]https://github.com/keycloak/keycloak/blob/master/services/src/mai >> n >> /java/org/keycloak/authentication/authenticators/x509/UserIdentityEx >> t >> ractor.java >> [2]https://github.com/keycloak/keycloak/blob/master/services/src/mai >> n >> /java/org/keycloak/authentication/authenticators/x509/UserIdentityTo >> M >> odelMapper.java#L57 >> >> Regards >> Sven-Torben >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi Sven-Torben, I think that if you mark attribute as "read-only" and maybe also as "binary attribute" with the LDAP attribute mapper, then it won't be saved to the Keycloak DB at all. Then you don't need to care about the length of the field in user_attribute table. Something similar is used to save the picture in the LDAP example, which is part of keycloak-examples distribution (the deprecated one). This will work just with the LDAP, not with Keycloak DB-only setup. But isn't it what you wanted to use anyway? Marek On 15/04/2019 20:16, Sven-Torben Janus wrote: > Hey Marek, > > I need to follow up on this. > I have made a first draft of the implementation. However, it seems that certificates are much longer than currently supported by the value field in the user_attribute table. > Increasing filed length has been discussed in https://issues.jboss.org/browse/KEYCLOAK-2382, but I could not really figure out what the current status is? It does not seem to be implemented. Do you see a chance for increasing the field length? > > Regards > Sven-Torben > > -----Ursprüngliche Nachricht----- > Von: Marek Posolda <mposolda(a)redhat.com&gt; > Gesendet: Montag, 25. März 2019 12:25 > An: Sven-Torben Janus <sven-torben.janus(a)conciso.de>; keycloak-dev(a)lists.jboss.org > Betreff: Re: AW: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values > > On 22/03/2019 11:43, Sven-Torben Janus wrote: >> Hey Marek, >> >> as far as I know, RFC 2587 specifies the usercertificate attribute for exactly that purpose. Active Directory also knows something similar (see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e9... ). > Thanks for pointing this. It seems it may be useful to have OOTB UserIdentityExtractor, which will work with the MSAD "userCertificate" > attribute. So if you have a chance to contribute this, I think it will be fine. >> IMHO matching the certificate against a custom LDAP attribute should also be ok. At least that is what the custom attribute mapper for the existing "user mapping method" is doing anyways for all the other user identity sources (like subjectDN, common name etc.), right? > Maybe it is thin line, but in general, I see that having OOTB extractors, which are able to pair users based on subjectDN or commonName looks natural and will probably work for most of the people. > Having something very specific like "issuer;serialNumber" is IMO not generally useful, so I would rather avoid to have the UserIdentityExtractor in Keycloak OOTB. > > Marek >> Regards >> Sven-Torben >> >> -----Ursprüngliche Nachricht----- >> Von: Marek Posolda <mposolda(a)redhat.com&gt; >> Gesendet: Freitag, 22. März 2019 10:20 >> An: Sven-Torben Janus <sven-torben.janus(a)conciso.de>; >> keycloak-dev(a)lists.jboss.org >> Betreff: Re: AW: [keycloak-dev] X.509 User Identity Extractor - >> multiple values >> >> Thanks for the clarification >> >> TBH It seems to me that probably even (b) won't be very generally useful. Unless for example some LDAP servers store the certificate PEM in some standard LDAP attribute of the user? But if it's customization of LDAP schema specific to your environment to be able to save the certificate PEM in the LDAP attribute, then my vote is to not add it. >> >> Marek >> >> On 21/03/2019 17:18, Sven-Torben Janus wrote: >>> Hi Marek, >>> >>> I agree to your thoughts on solution a). That's basically why I wanted to discuss it here, before starting an implementation. >>> Regarding, solution b), yes that is what I thought about (with or without the initial/final lines). >>> >>> Sven-Torben >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Marek Posolda <mposolda(a)redhat.com&gt; >>> Gesendet: Donnerstag, 21. März 2019 10:54 >>> An: Sven-Torben Janus <sven-torben.janus(a)conciso.de>; >>> keycloak-dev(a)lists.jboss.org >>> Betreff: Re: [keycloak-dev] X.509 User Identity Extractor - multiple >>> values >>> >>> Hi, >>> >>> The solution (a) looks quite specific to the environment and I don't think that it will be useful to have this as a generic feature in Keycloak.. Solution (b) looks like bit more generally useful, but still not 100% sure about adding it to Keycloak... For the solution (b), are you talking about the PEM String representation of the X509 certificate, which just excludes the initial and final lines (Those with "BEGIN CERTIFICATE" and "END CERTIFICATE" )? >>> >>> Marek >>> >>> On 21/03/2019 07:48, Sven-Torben Janus wrote: >>>> Hey all! >>>> >>>> I am currently facing a situation with a customer who wants to implement mutual SSL / client cert authentication. As I understand from the UserIdentityExtractor[1] implementations, currently only returning a single value is allowed, because the UserIdentityToModelMapper[2] calls toString on the actual userIdentity object. >>>> >>>> Now my customer uses the serial number from the certificate to identify users. However, this is only unique in combination with the issuer of the certificate, since my customer supports multiple CAs. The combination of both exists in their LDAP as a single attribute where both parts are separated by a special separator character. >>>> In addition to that, the whole certificate of the user is also available in another LDAP attribute. >>>> >>>> I currently see the following options to implement a solution for this: >>>> 1) Writing a custom Authenticator to handle that specific situation. >>>> This one would look very similar to the ootb X509 authenticator, but >>>> implements either a) or b) (see below) >>>> 2) Making a contribution to Keycloak and extend the list of available UserIdentitiyExtractors. >>>> >>>> For both approaches two different implementations come to my mind: >>>> >>>> a) Adding an additional UserIdentitiyExtractor which combines the issuer and the serial number into a single string and use that as an identity. >>>> b) Adding an additional UserIdentitiyExtractor which returns the whole certificate as the user's identity. >>>> >>>> We would prefer contributing to Keycloak, if such a contribution is welcome and meaningful. >>>> >>>> Do you have any advice on which way to go here? >>>> >>>> [1]https://github.com/keycloak/keycloak/blob/master/services/src/mai >>>> n >>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityEx >>>> t >>>> ractor.java >>>> [2]https://github.com/keycloak/keycloak/blob/master/services/src/mai >>>> n >>>> /java/org/keycloak/authentication/authenticators/x509/UserIdentityTo >>>> M >>>> odelMapper.java#L57 >>>> >>>> Regards >>>> Sven-Torben >>>> >>>> _______________________________________________ >>>> 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