Proposal 4 defines the concept of SASL termination. There are use cases for routers (written against the API defined in proposal 70) which depend on knowing the client's Subject. However some of the more useful SASL mechanisms are not compatible with SASL inspection technique (implemented by the existing SaslInspection filter). The SCRAM-SHA mechanisms are one example: Because each server issues a unique challenge it's not possible to fan out SASL Authenticate.
This means that to cater to router implementations which rely on identity we will need to implement the SASL termination technique. The natural way to do that is by writing a SaslTermination filter and configuring it on the VC's filter chain (i.e. before the first router in the DAG is reached).
Proposal 4 defines the concept of SASL termination. There are use cases for routers (written against the API defined in proposal 70) which depend on knowing the client's
Subject. However some of the more useful SASL mechanisms are not compatible with SASL inspection technique (implemented by the existingSaslInspectionfilter). TheSCRAM-SHAmechanisms are one example: Because each server issues a unique challenge it's not possible to fan out SASL Authenticate.This means that to cater to router implementations which rely on identity we will need to implement the SASL termination technique. The natural way to do that is by writing a
SaslTerminationfilter and configuring it on the VC's filter chain (i.e. before the first router in the DAG is reached).