If you think Harness NextGen is great, but you are not sure what is the best login method to choose, you are reading the right post. Keep reading to learn about what login options are available and what is the control level it offers.
First, we need to make sure we agree on some terms:
Authentication - Confirms the identity of the person (or service) making the login. Is the person saying that they are Jane Smith are Jane Smith, or someone else pretending to be Jane Smith?
Authorization - Getting permission to act. After we establish that you are Jane Smith, authorization will determine what actions you are allowed to do (like create, delete, etc.)
Directory - A database for users, their passwords, and security settings.
The Harness NG platform authenticates users and provides authorization using groups and roles. Let’s discuss the many methods for Authentication and authorization supported by Harness in greater detail.
Authentication Methods
Local Authentication
Users are created in the Harness application directory and are authenticated with a password. Users can be created in the web user interface or using the rest APIs. The user’s unique identifier (the user name) is an email address.
Harness Local Authentication allows an account administrator to enforce many security features, including password strength, Periodic password expiration, lockout policy, and two-factor authentication.
For more details on local authentication security mechanisms, see the authentication overview page in the Harness documentation.
oAuth
Per Wikipedia, OAuth (Open Authorization) is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
With oAuth, users and passwords are managed by the OAuth provider, and Harness trusts that source. Harness uses oAuth APIs to verify users’ identities against the oAuth provider directory.
The user object needs to be created in Harness, but the password and password policy are managed in the oAuth provider directory. The end-user does not have to set a password in Harness and can use the existing OAuth password.
Harness supports the following OAuth providers: Azure, BitBucket, GitHub, Gitlab, Google, and LinkedIn. For more information on setting up oAuth, read Enable Public oAuth providers in the Harness documentation.
SAML
Per Wikipedia, SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
With SAML, users are created in the Harness directory, but passwords and password policy are managed in the SAML provider directory. One advantage. In addition to managing users, passwords, and policies, many SAML providers can automatically create users in Harness using the SCIM protocol.
Some common SAML providers are Azure, OKTA, OneLogin and PingFederetaed.
LDAP
LDAP stands for Lightweight directory access protocol. It is a protocol that allows Harness to query existing directory services like Active Directory or LDAP servers. With LDAP, the LDAP provider manages users, passwords, and policies.
Harness queries the LDAP provider and can automatically create users in its local directory. These users will authenticate using the LDAP password.
Let’s compare Authentication methods
Local login | OAuth | SAML | LDAP | |
---|---|---|---|---|
User creation in Harness | Manual or API | Manual or API | Manual, API, or automatic | Automatic |
what happens when user leave | Admin must manually disable the user (or via API) | User cannot log in | User can not log in, and can be automatically removed | User is automatically removed |
Where are passwords managed? | In Harness | At provider | At provider | At provider |
2FA support | Yes | Done by oAuth provider | Done by SAML provider | No |
User invitation | Required | Required | Optional | Optional |
User delete | Manual or API | Manual or API | Manual, API, or automatic | Automatic |