12:48 p.m.
Hey Sven-Torben,
I understand your concern. The cert path validation happens during SSL handshake, so that
should not be an issue. As for other information, for example Key Usage and Extended Key
Usage - those fields can either be replicated into an "substitue" certificate or
their validation can be turned off, again, depending on a particular use case. Obviously,
if your requirements include CRL validation or OCSP cert validation, then the suggested
approach may not work for you.
The client cert authentication is mostly concerned with mapping an existing user using the
information from client certificate, cert validation is somewhat secondary (for example,
the authenticator leaves the PKIX path validation to the container), and this strategy can
be an alternative, rather than adding something to ootb that is specific to a particular
vendor.
My $0.02
________________________________________
From: Sven-Torben Janus [sven-torben.janus(a)conciso.de]
Sent: Thursday, March 21, 2019 12:25 PM
To: Nalyvayko, Peter; Marek Posolda; keycloak-dev(a)lists.jboss.org
Subject: AW: [keycloak-dev] X.509 User Identity Extractor - multiple values
Hey Peter,
I am not sure, if I understand all the implication, especially when it comes to
certificate validation. When I manipulate or replace the client cert, how can the existing
X509 Client Cert User Authentication ensure the validity of the new/manipulated
certificate then?
Regards
Sven-Torben
-----Ursprüngliche Nachricht-----
Von: Nalyvayko, Peter <pnalyvayko(a)agi.com>
Gesendet: Donnerstag, 21. März 2019 15:43
An: Marek Posolda <mposolda(a)redhat.com>; 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 Sven-Torben,
You may also take a look at x509 lookup SPI responsible for returning a client
certificate's certificate chain. One strategy/workaround for what you are trying to do
is to actually substitute the client cert with another cert with a subjectDN that you can
format any way you need based on your requirements. Essentially, the approach will allow
to normalize any incoming certificate's subjectDN and still rely on the existing X509
Client Cert User Authentication that comes out of the box
Cheers,
Peter
________________________________________
From: keycloak-dev-bounces(a)lists.jboss.org [keycloak-dev-bounces(a)lists.jboss.org] on
behalf of Marek Posolda [mposolda(a)redhat.com]
Sent: Thursday, March 21, 2019 5:53 AM
To: Sven-Torben Janus; keycloak-dev(a)lists.jboss.org
Subject: 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/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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev