SOLR-17309: Enhance certificate based authentication plugin with flexible cert principal resolution

[laminelam]

https://issues.apache.org/jira/browse/SOLR-17309

Description

This contribution introduces an enhancements to the Certificate Authentication (CertAuth) plugin offering more flexibility in the principal resolution.

The CertPrincipalResolver interface has been introduced to allow implementations to extract the principal information from an X.509 certificate. This flexibility enables more granular control over which part of the certificate is used for the Principal.

The provided implementing class (PathBasedCertPrincipalResolver) uses fields paths based pattern to find the right information to extract. The current supported fields/paths are: Subject DN, Issuer DN, and SANs (Subject Alternative Name).

The list of supported SAN fields is compatible with RFC 5280: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6

Backward compatibility: The default implementation (DEFAULT_PRINCIPAL_RESOLVER) extracts the whole subject DN which makes it backward compatible with the current implmentation.

Examples:

Given a cert with SAN.email=[email protected], the following configuration resolves "admin" as the request's Principal. This is done in 2 steps:

1. Read SAN.email fields. Filter out to accept only emails ending with "@example.com" (pick the first match).
2. In the resolved email extract the string between "_" and "@".

"principalResolver": {
  "class": "solr.PathBasedCertPrincipalResolver",
  "params": {
    "path": "SAN.email",
    "filter": {
      "checkType": "endsWith",
      "values": ["@example.com"]
    }
    "extract": {
                 "after": "_",
                 "before": "@",
         }
  }
}

Tests

Test cases included.

TODO: Add documentation

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[epugh]

Could you explain a bit more what the general use case is? I read the code, and I see lots of complex words I don't understand ;-). Maybe the Ref Guide docs would make it all clear!

I do like having Solr support more types of authentications! One concern is that is this a place we should leverage another project that would insulate us from the specifics of various auth tools? (maybe something for a larger discussion).

[laminelam]

@epugh

Actually, this is not a new type of authentication. Solr already has a Certificate Authentication Plugin but it offers a very basic support. In fact, the existing code is merely more than one line that extracts the whole subject DN (ex: "CN=Solr User,OU=Engineering,O=Example Inc.,C=US") from the cert and use it as the principal (kind of username) of the received request

This PR is an enhancement to the existing plugin. It is a part of a bigger contribution to support:

• 1- Flexible Principal extraction
• 2- Identity extraction
• 3- Identity validation

More details in these 2 JIRAs: SOLR-17308 and SOLR-17309

[epugh]

Thanks for supplying some context. I looked at the code, and it all made sense, though I confess to not being an expert in this area!

1. Do we need additional Ref Guide docs at this point for folks to take advantage of this capability?

2. Is there any impact on the Admin UI? Can you set up a client certifcate (I presume in your browser?) and use it to log into Solr?

[laminelam]

@epugh

1. Yes planning to add some new entries to the ref guide.

2. Yes you can use it to login to the Admin UI. This is already the case right now. The only thing this PR does is to make the principal extraction more flexible. For ex instead of seeing "CN=Solr User,OU=Engineering,O=Example Inc.,C=US" on the left menu when you login to admin, you’d have an email or a username that you have extracted from the cert, which means a better user experience as well.

BTW, you can also use this to authenticate from the CLI, or a terminal, etc.