Security policies

[cziebuhr]

• Removed checking if cryptography is available (it's a requirement since v0.5.1)
• Removed boilerplate code around SecurityPolicyType and SecurityLevel
• Moved and restructured some classes from ua to security_policies
  • IMHO these classes don't belong there, because they are internal classes not defined by OPC UA spec
  • Having SecurityPolicy "None" and SecurityPolicies with crypto in different files is bad and already led to issues (Fix SimpleRoleRuleset #1718)
  • Naming is bad, separated classes into abstract base classes and concrete implementations
  • server certificate can also be used with SecurityPolicyNone (needed for password encryption)
• Client: Combined server_policy_id() and server_policy_uri() to server_policy().
• Renamed check_user_token to decrypt_user_token: There is no check, it just decrypts the token. Checks are done in UserMananger.
• WIP: sign and verify X509IdentityToken (untested)

TODOS / to discuss

• It would even be better to only have crypto algorithms in the SecurityPolicy classes and not to use them as data containers for server and client objects.
  • security policies are used both in server and client code. permissions doesn't belong there, it is only used on server side and fits better into InternalServer.
  • host and peer certificates, as well as Mode could also better be stored in InternalServer and Client classes
    • this allows crypto functions to be used with both, application instance certificate (host_certificate/peer_certificate) as well as X509IdentityToken.CertificateData,
      without the need of having extra functions like encrypt_asymmetric or the newly added sign_asymmetric.
    • SecurityPolicyFactory is no longer required
• create abstract base class for CryptographyNone/Cryptography

[cziebuhr]

Solves #1727

[oroulet]

ok now you have a conflic with all the formating changes on master. Sorry for that. hopefully by formating things on your side you should manage to get it through...

[cziebuhr]

I am now on vacation and will try to proceed afterwards. Do you have any general feedback on the changes?

[oroulet]

@cziebuhr as I wrote somewhere else, I do not know really well the crypto code, it was written by someone else. But generally your code quality looks good and your goals make sense, so I have to trust you. if you do not break everything I will merge ;-)

[cziebuhr]

Rebased to master, tested and fixed code for X509IdentityToken