Indeed I was referring to the PlcAuthentication. While name is a bit
unfortunate (our implementations are rather credential structs), it
ships everything needed to wire driver. I'm not certain about TLS
transports, as transport most likely could utilize some of
PlcAuthentication.
For sure with what you wrote we can align authentication.
Cheers,
Łukasz
On 2/22/26 22:58, Christofer Dutz wrote:
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
