[SLING-9622] Avoid registration of auth requirements for aliases and vanity paths

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: Auth Core 1.5.0
• Component/s: Authentication
• Assignee: Carsten Ziegeler
• Reporter: Carsten Ziegeler
• Created: 30/Jul/20 15:07
• Updated: 02/Mar/22 17:03
• Resolved: 25/Aug/20 08:57

Description

Right now when auth requirements are registered, they need to be registered for the resource path, as well as all vanity paths and potentially all combinations of aliases for that path. First of all, this creates potentially a lot of auth requirements for a single path, but as well requires that the registrar of the auth requirement to be aware of vanity paths and aliases and do the right thing and update the auth requirements whenever there are changes.
We should avoid these additional registrations and processing.
The SlingAuthenticator is currently checking the request path against the auth requirements. We could change this with checking the resolved path. So the authenticator could use a service user resolver and resolve the path and then check the auth requirements.
This avoids all the extra work for the registrar of the auth requirements, but comes with the additional cost of a resolve call per request

Issue Links

• causes: SLING-10368 Add service user mapping for Auth Core
• is related to: SLING-11171 WARN "The provided service user id 'serviceuser--org.apache.sling.auth.core' is not a known JCR system user id and therefore not allowed in the Sling Service User Mapper."
• is related to: SLING-9689 Handle authentication requirements for children of protected resources when internal mappings
• is related to: SLING-9672 Expose vanity paths from ResourceMapper.getAllMappings()
• is related to: SLING-9676 Improve Javadoc for MapEntriesHandler
• relates to: SLING-9620 ResourceMapperImpl.getAllMappings does not respect multi-valued sling:alias
• relates to: SLING-9623 ResourceMapperImpl.getAllMappings is incomplete for nested alias