What is the User Token Type in OPC UA? Why is this important, how do I know the User Token Type from the server, and add this in client to connect to the server?
I will answer your question in two parts.
Part 1:
What is the User Token Type in OPC UA? Why is this important?
Part 2:
How do I know the User Token Type from the server, and add this in
client to connect to the server?
Part 1: This comes under the topic of user authentication, i.e. when a user is trying to connect from an OPC UA Client to an OPC UA Server, the OPC UA server needs to confirm the identity of the user before allowing the connection from the OPC UA client.
There are four ways in which user authentication is specified in OPC UA and ‘UserTokenType’ is an enumeration specified with the values 0, 1, 2 and 3 for those four ways:
Anonymous
Connect without any credentials – can be useful during developer test/debug sessions
Should not to be used for deployments in the field
UserIdentityToken used is ‘AnonymousIdentityToken’
UserName
Username and password
The password may be encrypted by the client depending on the UserTokenPolicy used
UserIdentityToken used is ‘UserNameIdentityToken’
Certificate
X.509 v3 certificate
The certificate can include a signature depending on the UserTokenPolicy used
UserIdentityToken used is ‘X509IdentityToken’
IssuedToken
Text or binary token issued by an external authorization service
The token data may be encrypted by the client depending on the UserTokenPolicy used
UserIdentityToken used is ‘IssuedIdentityToken’
Part 2:
This wireshark trace contains the sequence of GetEndpointsRequest/GetEndpointsResponse between an OPC UA client and an OPC UA server. As you can see, the getEndpointResponse packet provides information on userTokens supported by the server. Specifically in this image, you can see that 'Anonymous' and 'UserName' are supported in a sample implementation.
Here you can see a list of some open source OPC UA stacks that also provide related sample application code that you can try out:
open62541 – https://open62541.org/certified-sdk.html – C stack | Mozilla License | Embedded ready | TSN ready
NodeOPCUA – https://node-opcua.github.io/ – NodeJS | MIT License | Cloud ready
FreeOpcUa – https://github.com/FreeOpcUa/freeopcua – C++ | LGPL-3.0 License | Python bindings
UA .NET stack – https://github.com/OPCFoundation/UA-.NETStandard – RCL License for corporate members of OPC Foundation & GPL 2.0 for others | Standard profile | Web oriented implementation
If you are looking for more hands-on information, you can check out these resources
Free documentation: You can look at the open source documentation page: https://open62541.org/doc/current/
Paid online course: Practical introduction to OPC UA – code walk-through and examples in this course use the open62541 stack: https://opcfoundation.org/products/view/practical-introduction-to-opc-ua-part-i
UserTokenType enumerates various authentication mechanisms (anonymous, username/password, x509, etc...)
Each endpoint you get from a server contains an array of UserTokenPolicy describing an authentication mechanism supported by that endpoint.
Related
How can I configure OPC UA Server to use Username & Password?
How can I configure OPC UA Server to use Certificate? I need some sample code to Login with certificate In C#
Anonymous Login for OPC UA Server is working and able to create a session but can have alternative Login using certification authorization In C#
I am reading the OPC UA specification and there is one thing I am confused about:
When using HTTPS as a transport protocol, the secure channel is already established by the TLS.
In this case, does it make sense to use any other security mode than None?
What would be the benefit to encrypt or sign the messages over an already secured channel?
The SecurityPolicy becomes mostly irrelevant when using HTTPS transport.
From Part 6 when discussing HTTPS:
The SecurityPolicy shall be specified, however, it only affects the algorithms used for signing
the Nonces during the CreateSession/ActivateSession handshake. A SecurityPolicy of None
indicates that the Nonces do not need to be signed.
For what it's worth... the only transport you'll find widely supported in the real world is the OPC UA TCP transport with binary encoding. This is the only combination that is mandatory for implementations.
If you use HTTPS for transport, TLS will define encryption, as you have understood.
But, OPC UA is also enabling Application Authentication using Application Instance Certificates. If you use OPC UA SecurityMode=None, the Application Authentication is ignored. In order to enable Application Authentication with HTTPS, you will need to use at least SecurityMode=Sign, although the message signing or security is not really necessary on top of TLS.
I’ve written an OPC UA Client and i’m using ProSys OPC UA Simulator Server to test it. Running in Anonymous mode my client connects and i can browse the server. however when I configure my client to use a Username and Password it fails with No Suitable UserTokenPolicy found for the possible endPoints. I’ve debugged it and it appears that http://opcfoundation.org/UA/Se…..olicy#None is not in the endpoints userIdentityTokens array, although in ProSys it states it is.
I’ve set up a user in The OPC UA Simulator Username & Passord box is ticked
Security Modes = None
Security Policies = None are ticked
The list of server EndPoints
Security Mode = None
Security Policy = None
So i would expect to see it in userIdentityTokens array.
My Client is written using the Open62541 libraries
Any help would be appreciated.
Thanks
I haven't used the Open62541 libraries, but it seems the standard allows the OPC server to require that the username and password are encrypted even when the rest of the transport is not signed or encrypted.
It appears that at some point in time (and maybe still), Open62541 doesn't handle encrypting the password. Here are a couple of related github issues:
https://github.com/open62541/open62541/issues/934
https://github.com/open62541/open62541/issues/1548
https://github.com/open62541/open62541/issues/2757
I am working on a node.js OPC UA client based on the node-opcua library, and I was able to verify that I can connect to the ProSys OPC-UA simulation server with the security mode set to none and user authentication set to username & password. I do not know what type of password encryption node-opcua is doing behind the scenes, but it works.
----- Additional info -------
I found another forum with some clarification: https://forum.prosysopc.com/forum/opc-ua/clarification-on-opensecurechannel-messages-and-x509identitytoken-specifications/
The key part:
If passwords are sent, they will be encrypted as defined by the
UserTokenPolicy (which is separate from SecurityPolicy, but similar).
The Application Instance Certificates will be used for the encryption
in this case – and therefore they are required to be exchanged even
when MessageSecurityMode=None.
As I understand it,
SPN is an authenticating tool for windows services.
Kerberos is a
user authentication service
SPNEGO-GSSAPI is the third party API to
be able to use those services.
SSPI : is the Neutral layer to send
request from SPNEGO to SPN service.
Am I completely lost?
Trying to figure out how it works but information, is either too precise or not enough.
Ok a more verbose answer:-
SPN - Service Principal Name. It is an identifier associated with each account in a KDC implementation(AD, OpenLDAP etc). Basically if your account acts as a service to which a client authenticates, the client has to specify "who" it wants to communicate to. This "who" identifier is the SPN. This is the strict definition. Many people often call the client name (UPN - User Principal Name) of a service as SPN. This happens when the service itself may act as a client( google the delegation scenario ). This is not strictly correct but widely assumed true.
Kerberos is a protocol for authentication. It is a name for a framework. It involves a third party server(called KDC or Key Distribution Centre) and involves a series of steps of acquiring tickets(tokens of authentication). It is really complicated so http://en.wikipedia.org/wiki/Kerberos_(protocol)
To some extent you got this right. GSSAPI is an API but SPNEGO is not. GSSAPI is technically agnostic to the auth mechanism you use, but most folks use it for kerberos authentication. SPNEGO is a pseudo mechanism, in the sense it declares an RFC for authentication based communication in HTTP domain. Strictly speaking SPNEGO is a specification but most folks also consider it as an implementation. For instance, Sun and IBM JDK provides "mechanism providers" for SPNEGO token generation but GSSAPI is used to actually call it. This is done in many projects(Tomcat as a Server is and example that come to the top of my head and one of the folks who answered this question developed it).
SSPI is an analogue to GSSAPI in windows. Its a different API which ends up doing something very similar to GSSAPI.
Not quite.
SPN simply means 'Server Principal Name' and is the AD or Kerberos slang for the service you try to authenticate against.
Kerberos is a user authentication service, more or less yes. It also provides security for network messages and calls between services.
SPNEGO-GSSAPI* is a kind of strange beast. GSSAPI (Generic Security Service Application Program Interface) is an API to (in principle) different authentication services, it provides negotiation of the mechanisms used. Often the only mechanism available will be Kerberos though. It is the usual API to attach 3rd party programs to Kerberos when you are on Unix (defined in various RFCs, for example RFC 2743 )
On the windows platform SSPI is the generic layer, so it compares to GSSAPI.
SPNEGO is kind of a strange hybrid. It is a mechanism to be used in SSPI, HTTP Auth or GSSAPI which negotiates another auth protocol (for example Kerberos or NTLM if you are on Windows), so it basically does the same thing GSSAPI does again in a different way.
Typical uses of SPNEGO are HTTP authentication to a windows domain, for example IIS uses it if you use 'Integrated windows authentication'. It is also used when you select the 'Negotiate' options for SSPI. See for example RFC 4559
Almost all of your understandings are wrong.
Here it goes:
SPN: A specific service-class is bound to a specific account, e.g. HTTP to www.stackoverflow.com => HTTP/www.stackoverflow.com#STACKOVERFLOW.COM
Yes
3./4. GSS-API (Unix)/SSPI (Windows): Mechanism neutral API to interact with. E.g, Kerberos 5, NTLM, SPNEGO, etc.
SPNEGO: It is one of many mechnisms supported by GSS-API/SSPI. It is actually a pseudo-mech.
single sign-on (SSO) for web applications (used through a browser) is well-documented and established. Establishing SSO for Rich Clients is harder, and is usually suggested on the basis of Kerberos tickets, in particular using a Windows login towards an ActiveDirectory in a domain.
However, I'm looking for a more generic solution for the following: I need to establish "real" SSO (one identity for all applications, i.e. not just a password synchronization across applications), where on client's side (unmanaged computers, incl. non-Windows), the "end clients" are a Java application and a GTK+ application. Both communicate with their server counterparts using a HTTP-based protocol (say, WebServices over HTTPS). The clients and the server do not necessarily sit in the same LAN/Intranet, but the client can access the servers from the extranet. The server-side of all the applications sit in the same network area, and the SSO component can access the identity provider via LDAP.
My question is basically "how can I do that"? More specifically,
a) is there an agreed-upon mechanism for secure, protected client-side "sso session storage", as it is the case with SSO cookies for browser-accessed applications? Possibly something like emulating Kerberos (TGT?) or even directly re-using it even where no ActiveDirectory authentication has been performed on the client side?
b) are there any protocols/APIs/frameworks for the communication between rich clients and the other participants of SSO (as it is the case for cookies)?
c) are there any APIs/frameworks for pushing kerberos-like TGTs and session tickets over the network?
d) are there any example implementations / tutorials available which demonstrate how to perform rich-client SSO?
I understand that there are "fill-out" agents which learn to enter the credentials into the application dialogues on the client side. I'd rather not use such a "helper" if possible.
Also, if possible, I would like to use CAS, Shibboleth and other open-source components where possible.
Thanks for comments, suggestions and answers!
MiKu
Going with AD account IS the generic solution. Kerberos is ubiquitous. This is the only mechanism which will ask you for your credentials once and just once at logon time.
This is all feasable, you need:
A KDC
Correct DNS entries
KDC accounts
Correct SPN entries
Client computers configured to talk to the KDC
Java app using JAAS with JGSS to obtain service tickets
GSS-API with your GTK+ app to obtain service tickets
What did you figure out yourself yet?
Agreed with Michael that GSSAPI/Kerberos is what you want to use. I'll add that there’s a snag with Java, however: by default, JGSS uses its own GSSAPI and Kerberos implementations, written in Java in the JDK, and not the platform’s libraries. Thus, it doesn’t obey your existing configuration and doesn’t work like anything else (e.g. on Unix it doesn’t respect KRB5CCNAME or other environment variables you’re used to, can’t use the DNS to locate KDCs, has a different set of supported ciphers, etc.). It is also buggy and limited; it can’t follow referrals, for example.
On Unix platforms, you can tell JGSS to bypass the JDK code and use an external GSSAPI library by starting the JVM with:
-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so
There is no analogous option on Windows to use SSPI, however. This looks promising:
http://dblock.github.com/waffle/
... but I haven’t gotten to addressing this issue yet.