Skip to main content

Managing the Passwords

Password Management Features provided by IDHub​

1. Single Sign-On (SSO):

SSO eliminates the need for users to remember multiple passwords for different applications and services, thereby reducing password fatigue and improving user experience. IDHub offer robust SSO functionality, integrating seamlessly with diverse applications and platforms. This centralized authentication streamlines access and strengthens security by eliminating the risk of password reuse across multiple accounts.

2. Multi-Factor Authentication (MFA):

MFA adds an extra layer of security beyond passwords, requiring users to provide additional verification factors like biometrics, one-time passwords, or security tokens. IDHub offers a variety of MFA options, catering to different user preferences and security needs. This multi-layered approach significantly reduces the risk of unauthorized access even if a user's password is compromised.

3. Password Complexity Enforcement:

IDHub can enforce password complexity requirements to ensure users create strong and difficult-to-crack passwords. This includes setting minimum password length, requiring a mix of character types, and prohibiting dictionary words or personal information. By enforcing strong password policies, IAM solutions help mitigate the risks associated with weak passwords.

5. Password Expiration and Rotation:

IDHub can require users to change their passwords periodically, further mitigating the risks of password compromise. This feature can be configured to specific timeframes based on organizational security policies. By enforcing regular password changes, IDHub helps ensure passwords remain secure even if they are exposed inadvertently.

6. Password Vaulting via KeyCloak:

IDHub offers secure password vaulting functionality, allowing users to store their passwords in a centralized and encrypted location in KeyCloak. This eliminates the need for users to store passwords in insecure locations like plain text files or personal documents. Password vaults are often integrated with SSO and MFA, providing convenient and secure access to all user passwords.

7. Password Auditing and Reporting:

IDHub can generate comprehensive reports on password usage, strength, and compliance with organizational policies. This allows administrators to identify weak passwords, potential security vulnerabilities, and enforce password hygiene practices. By providing actionable insights into password management, IDHub empower organizations to proactively address security risks.

Vault​

Overview - What is Vault and Hashicorp​

Vault is an identity-based secrets and encryption management system that securely stores, manages, and protects sensitive data. It provides a centralized platform for managing secrets, ensuring that only authorized users can access them. Vault also offers encryption services, enabling organizations to encrypt data both at rest and in transit.

How IDHub uses Vault​

When the user purchases the vault subscription, then IDHub allocates a vault instance to the user. When you visit the connector onboarding page for the 1st time, it would give a pop-up as shown below and prompt you to get IDHub Cloud as shown below:

All the secrets for the connector is stored in that vault instance at the secret mount path. IDHub uses the secrets stored in the vault instance for onboarding the connector. For accessing this vault instance, IDHub generates a RoleID and secretID. Therefore the user who have these roleID and secretID will only be able to access or modify the secrets for the connector stored in the vault instance.

Privacy Policy of Vault​

IDHub generates a policy for each RoleID and secretID in the secret mount path for every connectors in the vault instance. The objective of the privacy policy of vault is that, the primary admin of the vault instance (the one who has purchased and installed the vault for the first time and have access to the root token) can provide the vault URL to another user and using that vault URL other user can onboard other connectors in the vault instance.

So, in this case, the other user need not to be provided the root token, just providing the vault URL would suffice, which the other user can leverage for onboarding connectors in that vault instance. Therefore when the other user uses the vault URL for onboarding connectors, he would get the RoleID and secretID which would be mapped to the secret mount path for the connector in the vault instance. He will be able to manage the secrets of his on-boarded connector using the connector manager UI.

note

The user would be able to view and manage the secrets of his onboarded connector and will not be able to access and manage the secrets of the other connectors in the vault instance. Basically the user would have restricted access to the vault instance, limiting him to only the secret mount path of the connector that the user have onboarded.

info
  • When IDHub gets the api call for connector setup, IDHub stores all the secrets for the connector in the secret mount path, sets up the policy, generates and provides the roleID and secretID to the user.
  • IDHub do not stores any secrets related to the connector. All secrets to the connector is provided to the user along with an imitation to keep the information safely.

Add external vault​

If you already have your own vault instance, then IDHub allows you to add your own vault while onboarding the connectors. You have to click on the Use External Vault button on the Connector onboarding page as is shown below:

After this, IDHub would ask you to enter your vault user name and password.

If you have your own vault, then in that case you do not need to purchase additional vault subscription. You would have to purchase the IDHub cloud tenant subscription and the connector subscription.

How does IDHub utilize an external vault?​

When the user provides the vault URL, IDHub would first validate the vault URL by running a health check on the vault. If the health check is successful, then IDHub would store the secrets of the connector in the given vault instance. The user would be notified that the vault setup has been finished and he can proceed with the next steps.

Subscription and usage​

There are 3 types of subscriptions in the flow which are discussed below:

  • IDHub Cloud tenant
    • This is the subscription for IDHub cloud. In order to onboard connectors you must have a IDHub cloud instance. IDHub is providing 30 days of free usage on cloud deployment of connectors hosted in IDHub platform. Post 30 days, active connector subscriptions will incur monthly charges.
  • Vault subscription
    • This is the primary subscription for the vault, which you need to subscribe to, in order to create a new vault instance. IDHub is providing 30 day free usage of vault. Post 30 days free usage charges would be $1,140.00 / month

  • Connector Subscription
    • After the successful installation of the connector, a separate subscription for the connector would be applicable as well.

How does IDHub provide authentication for connected application​

RoleID and SecretID is basically a username and password to access the vault instance, where IDHub stores the secrets for the connector.

Authentication can be done in 2 ways in the vault. When the vault instance is allocated to the user, IDHub provides the vault URL and the root token. When the vault is installed for the first time, a file is created and automatically downloaded, which would have the root token, unseal key and the vault URL. Root token for the vault is like admin password for the vault. Leveraging the root token, one can access all the data and secrets stored in the vault instance, all of it, can be easily accessed and modified.

note

The user who have installed the vault instance for the first time, he would have access to the root token of the vault.

Another way of authentication is using the RoleID & Secret ID. User might have multiple connectors in his vault instance. Then all the secrets for those connectors are stored in the secret mount path of the vault instance. In other words, in simple terms it can be said that all the connectors for every connector is stored in a separate folder in the vault instance. Therefore, essentially the folders are called secret mount path in the vault. The purpose of the RoleID & SecretID, for each secret mount part, IDHub allocates a RoleID & SecretID. If the user onboards another connector, then for that, secret mount part would be different and a different RoleID & SecretID would be allocated for the same.

In some scenarios, you might have different admin level users for different connectors. You can provide the roleID and secretID to those different administrators, so each admin user have access to the secrets of the connector to which he/she is authorized to access and manage. For instance: If one of the admin has onboarded AWS connector in your vault instance, then he would have the roleID & secretID of the secret mount path of the AWS connector, therefore he would have access to the secrets of the AWS connector only. And if another user has onboarded Entra ID connector in the vault instance, then he would have access to the roleID & SecretID of the Entra ID connector, thereby giving him authorization to manage the secrets of the Entra ID connector only (not for AWS connector or other connectors in the vault instance)

How are secrets stored in connector manager​

IDHub stores the secrets by writing the same on the vault. For accessing the secrets using the connector manager (stored in the vault), one needs to have the roleID and the secretID. When the user is on-boarding the connector using the quick onboarding wizard and the target system credentials (secrets) are entered into the wizard by the user, at that time, IDHub’s orchestrator engine gets the target system secrets in the request body and using the root token, it writes the secrets to the vault for that connector to do the connector set-up. And authentication to the secrets by the connector manager is handled by the roleID & secretID.

note

If you provide the RoleID and secretID to someone else, then that person would also be able to view or manage the secrets for the connector, using the connector manager. There is no further encryption currently implemented for the secrets.

How can secrets be edited​

Goto your account management dashboard (test) and then click on the connectors section. You will see the list of connectors that you have onboarded for your tenant. Now click on the Manager menu.

You will be redirected to the following page:

Now login using the RoleID and SecretID that has been downloaded automatically in a file during the connector on-boarding. You’ll see the following screen:

Now click on the arrow, and then you will get to see the secret.

Here you need to click on the eye icon

Click on the Add version button. Now the secrets would be editable. And then you can change the change or updates the secrets (if you want) and then click on the submit button. After making the required changes, click on the Update/Health check button and then click on the update config button.

Once that is done, system will automatically update the connector configuration with the new secrets will be updated in the vault accordingly.

Difference between Vault and Connector Manager​

Vault is the place where the secrets of all the connectors for your tenant is stored by IDHub. Only administrators of your organization can have access to the vault, which they can access using the root token. However, using the connector manager provides the granular access to every connector that you have onboarded for your tenant. Each connector on-boarded has it’s own secret mount path and you can provide the RoleID and secretID for each connector to multiple users depending which connector secrets you want them to manage. This enables you to give granular permissions to manage the secrets for each connector, eradicating the need to give the root token to all users.