In IT, an entity refers to a single and uniquely identifiable information object. It can be an existing or an abstract object. The following entities are used in Engity.
Organization
At the beginning there is the organization, and within the organization the administration of the respective directories used, the authorizations (for connecting external IdPs), the customization (the look and feel of the access solution) and other cross-organization properties takes place, whereby there can be 0-n directories, 0-n authorizations and exactly one customization object within the organization.
Directory
Within the directory there is exactly one specification represented by Spec (see DirectorySpec), 0-n Users, 0-n Applications, 0-n Sessions, as well as 0-n Authorizations and one DirectoryCustomization Object.
DirectorySpec
DirectorySpec is used to display how the directory behaves and its basic rules.
- Does it recognize email addresses or usernames and what other fields are defined (first name, last name ...)?
- Is there only one email address or others (User contacts)?
- What encryption is used for the password and what characters are allowed?
- How is the password strength mechanism set?
- How does a password reset page behave (does it reveal the existence of an email address or a username - default = no)?
- etc.
User
The User element contains information about the end users who will have access to the applications. This includes the username (optional), contact information such as email address or phone number, and the password, which is stored in encrypted form (by default using the current industry standard Argon2 ).
Application
As described in the previous overview, the application refers to the applications and contains the URLs that are used during the authentication and authorization process, as well as the secrets that an application needs to communicate with the IdP.
Session
The session always contains a reference to a logged in user. A reference to this session is stored by means of a unique ID (session ID) on the server side and in the browser cache. With each request made by the user, this is referenced to the server (IdP) and checked for validity on the server side (other features can be used for a high level of security). A session is valid until the user manually logs out, the session expires, or other situations occur that invalidate the session. The Engity IdP session is explicitly not an OIDC or OAuth2.0 standard.
Authorization
Authorizations define the integration of a third party IdP. Information is exchanged using OIDC or SAML, for example. These authorizations can be used to implement social logins to Google, Apple, Microsoft, Facebook, and LinkedIn, as well as enterprise logins to other IdPs such as the company's own Azure Active Directory or Office 365.
Permissions are defined at the organizational level and can then be referenced by each directory individually. Alternatively, each directory can be customized separately and given its own authorization as needed.
Customization
These are the pages the user sees, for example, during registration, login, and password reset. They are also the emails that the user receives when they go through or have completed one of these steps. The pages are defined by the organization, and each directory has a reference (via DirectoryCustomization) to these pages. For example, the same login page can be used for a test environment as well as for the production environment, allowing quick customizations for all directories/pages. However, it is also possible for each directory to have its own pages, if desired.
