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
