SecurityPolicy vs UserIdentityTokens

[cziebuhr]

There seems to be a slight mixup between

• security policies (None, Basic256Sha256, Aes128Sha256RsaOaep, Aes256Sha256RsaPss)
• supported UserTokenTypes (Anonymous, UserName, Certificate, IssuedToken)
  • these map 1:1 to UserIdentityTokens (AnonymousIdentityToken, UserNameIdentityToken, X509IdentityToken, IssuedIdentityToken)
• supported UserTokenPolicies (combination of UserTokenType, SecurityPolicy, etc.)

Misconceptions

• Configuring authentication
  current state: set_security_IDs(["Basic256Sha256", "Username"])
  better: set_identity_tokens([ua.X509IdentityToken, ua.UserNameIdentityToken])
  Why does "Basic256Sha256" imply to accept a client certificate?
  Where does the name of the method come from? I assume that it was originally related to UserTokenPoliciy.PolicyId
• Not using UserTokenPolicy.SecurityPolicyUri
  UserTokenPolicy.SecurityPolicyUri defines how the UserIdentityToken gets signed/encrypted when passed in ActivateSession, see https://reference.opcfoundation.org/Core/Part4/v105/docs/7.41.
  (Add policy URI to each endpoint token's SecurityPolicyUri #1720 fixes an issue with open62541 there, but that's not what I'm talking about.)
  • UserTokenType.Anonymous: Uri can always be "#None", because there is no data to sign/encrypt.
  • UserTokenType.UserName: When using a SecureChannel security policy of "None", the password will be sent in cleartext, which some clients deny by throwing BadSecurityModeInsufficient. We should explicitly set an Uri here, which allows the password to be encrypted. That also means, that ServerCertificate needs to be set for a SecureChannel security policy of "None".
    Because of the fallback mentioned in the ticket above, using a SecureChannel security policy of Aes256Sha256RsaPss currently leads to the password being encrypted (again) with rsa-oaep-sha2-256, which is currently not accepted in check_user_token()
  • UserTokenType.Certificate: For X509IdentityTokens, a signature is mandatory, otherwise the server can't verify if the client possesses the private key. That also means, that the signature should be done with the algorithm specified via Uri, not with the signature algorithm that was used for certificate generation. Currently, this signature also isn't verified in the server, leading to a security issue, because only the public(!) key is then used for authorization.
• Default PolicyId in client
  According to https://reference.opcfoundation.org/Core/Part4/v105/docs/7.42, the PolicyId is assigned by the Server. A client can't guess it, so it should default to an empty string.

I will create some PRs to address these issues.

[oroulet]

great. thanks