We already have this interface: PlcAuthentication
And two implementations: * PlcUsernamePasswordAuthentication * PlcCertificateAuthentication So far the usename password is used by the OPC-UA and the rudimentary CtrlX driver. The certificate one is not used at all. Currently (also in my toddysoft drivers) I pass everything in via the connection string. However there is no way to disguise credentials in that. So especially passwords are instantly exposed. I would like to move these types of arguments into the PlcAuthentication objects. For this I would like to introduce new Interfaces (Rename PlcUsernamePasswordAuthentication to DefaultPlcUsernamePasswordAuthentication and PlcCertificateAuthentication to DefaultPlcCertificateAuthentication and add new interfaces PlcUsernamePasswordAuthentication and PlcCertificateAuthentication) A driver could return a list of supported authentication types based on the selected transport. I think right now I could probably make use of the PlcAuthentications, I’d just love to provide the additional information for tools integrating our drivers. Chris Von: Łukasz Dywicki <[email protected]> Datum: Sonntag, 22. Februar 2026 um 10:42 An: [email protected] <[email protected]> Betreff: Re: [DISCUSS] Extend the PlcDriver and PlcTransport to return of PlcAuthentication interfaces? I think sticking with an Authentication (or rather Credentials) interface is a good start. With a basic concept of credentials we can start having common types of credentials such UsernamePassword(Authentication/Credentials), and less common ones (i.e. ClientCertificate) or driver specific (AdsPsk) will let end users to unify at least processing of access. In a way OPC-UA have some abstractions in this regard, which are not perfect but are backed by some thought and not only by coincidence. The most common secure transport I can think of is ssl/tls, which we can align across multiple drivers, as this is clear standard and negotiation can be delegated to standard library. But that part we can actually push using transport configuration, without need to customize driver itself at all. The ca/trust concept is inherent to ssl/tls and requires construction of trust manager. I am not entirely clear how the Secure ADS is going, but if you have a specific initialization sequence at transport layer which does not comply with ssl/tl, then you may not be able to run away from having some weird wiring or layering between transport and driver. Cheers, Łukasz On 2/20/26 17:15, Christofer Dutz wrote: > Hi all, > > As I’m currently implementing the first drivers that require authentication, > I was thinking of how we can make that integrate with third party systems. > > Currently we have two getConnection methods. One without any Authentication > and one that accepts Authentication. > > However, we have no way to guide a third party tool to what types of > Authentication a given combination of Protocol and Transport requires. > > With Beckhoff AMS for example: > > > * > Plain AMS doesn’t need Authentication > * > Secure-AMS (PSK) requires a set of „Identity“ and „Password“ or „Identity“ > and „Key“) > * > Secure-AMS (CA) requires a Java Keystore > * > Secure-AMS (Self-Signed) requires a Java Keystore plus an Admin username and > password. > > I would say that the last option wouldn’t make sense to have in the public > SPI parts as it’s totally dependent on the Driver. > However the normal PSK and CA TLS options would make sense to have the > Authentication type shipped along with the transport. > > So I was thinking … the way we currently also have „supported transports“ for > the driver … it would make sense to have the same on both the driver and the > transport to supply supported authentication interfaces. > > The implementations could use the same Annotations our config types use and > self-describe themselves. > > What do you think? > > Chris > >
