Hello Everybody.
Introduction
This article will discuss the flow and functionality behind the process of Inviting users to Harness and how it differs depending on the Authentication mechanism being used by the Account.
Lets Get Started !
Inviting Users with Harness username/password Auth Method
This is the default Authentication method Harness uses, which is Username/Password.
When a new user is invited to the Account an email would be sent to their ID mentioned.
Once this invite is accepted the Sign up page requests for the below details:
When users are added and authenticated to an account using username/password Auth Method there is a specific password hash that is created. This allows new users who are part of the Account Admin group to be able to log into the Account even in cases where the Account is locked or the SSO or SAML Provider is down. This is done by using the local login method which is accessible from the below link.
https://app.harness.io/auth/#/local-login
Inviting Users with Harness OAuth Method
When the Account is using Single Sign-On (SSO) with OAuth 2.0 with providers like GitHub, Bitbucket, GitLab, LinkedIn, Google, and Azure. If a new user is invited then the flow of how the data for this user is created differes from normal username/password.
In case when a new user is invited the email will redirect them to the following page, in this case we are using Google as the Identity Provider. You can see that although this is the first time the customer is signing up for Harness no details like a default username or PAssword are requested fom them.
This is because all the details for the user are coming from the Provider end setup using Oauth. In this case the user is directly logged into the account via Google Credentials.
There is no Passord which is created when this method is used since no details are collected from the user.
In the event that the SSO provider is facing any downtime the users would be unable to login into Harness and Local login would not work in that since the password has was never collected.
Conclusion:
The best case considering both the options mentioned above would be to have both Methods enabled so that when a new user is invited to Harness the Sign up process requires them to provide a username and password but at the same time once they sign up they can also authenticate using OAuth like Google. This way a passwordhash is created as well.
What this method ensures is that in the event if any downtime or impact from hte SSO PRovider end the users would be able to use local login to get back into Harness.
Thank you for Reading.