Re: Propagating Frontend-Authenticated User Identity to EPICS CA/PVA Clients

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 3/5/26 4:54 PM, André Favoto via Tech-talk wrote:

Hi all,

TL;DR: CA allows explicit setting of CA_PROTO_CLIENT_NAME from client side (e.g. caproto).

For PVAccess with "ca" as authentication method, is there a clear interface to do the same? Could maybe p4p support it?

PVXS, and thus P4P, so far follows the convention of libca in not providing an interface to override the "username" string.  Obviously, as a security feature this is quite weak.  But then, the ca-style "voluntary" authentication scheme is already quite weak by modern standards.

I should first mention there is an ongoing Secure PVA (SPVA) project to layer on TLS transport, with strong point-to-point authentication by x509 certificate.

I would also highlight one significant difference between PVA/CA vs. HTTP protocols.  While HTTP passes authentication tokens (eg. cookies) with each request, PVA and CA authenticate with each TCP connection.  So having different PVA identities means having difference TCP connections.  Be careful when thinking about an http-to-pva bridge.  Trying to proxy through end-user identity can force significant duplication of subscription data, with consequent increases in network bandwidth and system load on IOCs.  One of the reasons that a PVA and CA gateway (aka. proxy or bridge) does not pass through identity is so that all downstream subscribers to one PV can share a single upstream subscription.  See the diagrams on:

https ://epics-base.github.io/p4p/gw.html#background

In practice, lack of proxy authentication has proven not to be an issue.  Sites which have access control rules enforce at the gateway boundary as it is simpler to update one gateway configuration than to distribute changed ACF files to hundreds of IOCs.  (The SPVA project may eventually be able to change this calculation, but not yet)

Context:

In web-based applications, users are often authenticated using the organization's credentials (LDAP, SSO, etc.) before

interacting with a shared backend service. Besides the access control from the application itself, the IOC Access

Security rules should also apply per authenticated user, especially to avoid duplication of authorization logic in the

frontend application.

However, when a backend service mediates all EPICS operations, the username seen by Access Security is the backend

server's OS user. This was already noted by ORNL PVWS as something that can break ASG enforcement.

The suggested fix is to also enforce the RBAC for the IOCs in the frontend application - which I am trying to avoid, since

the source of credentials of the FE and the AS rules is the same.

The question: with PVA and the "ca" authentication plugin, is there a supported way to propagate the already

authenticated user identity from a frontend or service layer to the IOC, so that AS rules are evaluated correctly per

user? 

Suggestions of other perspectives for looking into this are welcome.

Thanks!