Add Support Extracting DN From X500Principal

[franticticktick]

Closes gh-16980

[rwinch]

Thanks for the PR @franticticktick

Upon review, I think that it makes more sense to deprecate and create a SubjectX500PrincipalExtractor class that extracts using getSubjectX500Principal.

What are your thoughts @jzheaux ?

[jzheaux]

Yes, @rwinch, I agree. Originally, I was trying to be a bit more conservative and reuse what we have, but I believe a new implementation will allow for a name that clearly indicates what it's for.

[franticticktick]

@rwinch @jzheaux there is one problem I would like to discuss. By default, the getName() method of the X500Principal class uses the RFC2253 format. That is, in tests, the dn will be generated:

1.2.840.113549.1.9.1=#16126c756b65406d6f6e6b65796d616368696e65,CN=Luke Taylor,OU=Open Source Development Lab.,O=Monkey Machine Ltd,L=Glasgow,ST=Scotland,C=UK

We see an oid instead of an emailaddress, which is in line with the format. At the same time, we see an encoded string instead of a value. As the specification says:

If the AttributeValue is of a type which does not have a string
representation defined for it, then it is simply encoded as an
octothorpe character ('#' ASCII 35) followed by the hexadecimal
representation of each of the bytes of the BER encoding of the X.500
AttributeValue.  This form SHOULD be used if the AttributeType is of
the dotted-decimal form.

To get a text string instead of an encoded value, we need to explicitly specify the format, this is RFC1779.

String subjectDN = clientCert.getSubjectX500Principal().getName("RFC1779");

In this case, the generated dn will look like this:

OID.1.2.840.113549.1.9.1=luke@monkeymachine, CN=Luke Taylor, OU=Open Source Development Lab., O=Monkey Machine Ltd, L=Glasgow, ST=Scotland, C=UK

In this format we can get email, but no matter what format we specify, we will still get oid in the string. Even if we leave the dn extraction by pattern, it will be very non-obvious. For example:

extractor.setFormat("RFC1779");
extractor.setSubjectDnRegex("OID.1.2.840.113549.1.9.1=(.*?),");

This is a pretty hard to understand API. At the same time, the toString() gives this result:

EMAILADDRESS=luke@monkeymachine, CN=Luke Taylor, OU=Open Source Development Lab., O=Monkey Machine Ltd, L=Glasgow, ST=Scotland, C=UK

And this will give the same result as the current implementation. If you have any ideas on how to better implement this feature, I'm ready to listen.

[rwinch]

@franticticktick Thanks for reaching out.

I do not think that we can use the toString method because it is implementation dependent. I think that we should probably allow for the format and regex to be injected. We can have an additional boolean property for extracting the email address that in turn sets the format and regex to extract the email address. This will simplify the usage for users that do not want to dig into the details of how things work under the covers. Does that work?

[franticticktick]

@rwinch I considered this solution. Provided that we provide the ability to extract dn via cn and email, this will work. Frankly speaking, I don't really like flags, they sometimes confuse, but as I understand it, in our situation there is no other solution. I will prepare a pr.

[franticticktick]

@rwinch @jzheaux Could you please review this PR? I hope I haven't missed anything.

[rwinch]

Thanks for the changes @franticticktick! I think this is getting close. I'd like to preserve the idea of having a regex for extracting the principal name and allowing the user to specify the format. The difference would be that the extractPrincipalNameFromEmail would set the correct format + the correct regex without needing to understand how it works.

I'd argue that we probably don't need any properties on the DSLs but instead just allow the user to set the properties on SubjectX500PrincipalExtractor and then the extractor on the DSL (or exposed as a Bean...however it works now)