Jump to: navigation, search

Service Logins


Revision as of 13:01, 11 November 2021 by MKR (Talk | contribs) (Created page with "Service Logins allow for easy management of credentials to third-party systems. == Problem == Service Logins are an easy solution to one problem, that occurs almost every tim...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Service Logins allow for easy management of credentials to third-party systems.

Problem

Service Logins are an easy solution to one problem, that occurs almost every time an interface to a third-party system is required: Where to put the credentials? If the interface makes use of Windows Authentication, it's no issue, as WebClient.UseDefaultCredentials will make use of the user the program/service opened. However, in almost all other cases, there's no way around either putting the credentials into the custom code (insecure, as it can be decompiled rather easily...) or creating properties on some MetaClass (that will be plain-text). EncryptedText properties won't work, as there's no way of getting to the plain-text password (that's required for the login to the external system) without using Reflection.

Features

`SERVICE_LOGIN` is the root class of the system, deriving directly from `SYSTEM_OBJECT`. Below that, there are the following derivates:

  • TOKEN_AUTH_SERVICE_LOGIN
 * TOKEN* 
  • BASIC_AUTH_SERVICE_LOGIN
 * USERNAME
 * PASSWORD* 
  • WINDOWS_AUTH_SERVICE_LOGIN
 * USERNAME
 * PASSWORD*
 * DOMAIN 
  • OAUTH2_AUTH_SERVICE_LOGIN
 * TENANT_ID
 * CLIENT_ID
 * CLIENT_SECRET*
 * CLIENT_CERTIFICATE*
 * IDP_URL
 * GRANT_TYPE
 * SCOPE

The fields with the asterisk (*) are password fields that encrypt the text and store the result in the database. To get the decrypted counterpart, the C# field <SECRETNAME>_DECRYPTED (e.g. TOKEN_DECRYPTED) needs to be accessed.