Login Providers are used to define who has access to something in Relativity and how to go about authenticating that user. For instance will the user be authenticated against a static list of acceptable users, or maybe against a table of users in a database.
There are three tiers of users in Relativity, each of which has different levels of access to features in the server:
- The Administrator who has full access to the server including network configurations and can create, edit, rename and delete domains & schemas. They login via the Admin Login which is handled by the Admin Login Provider.
- The Developer, who only has access to create, edit, rename and delete Schemas. They login via the Developer Login which is handled by the Developer Login Provider.
- Data Users who are typically those people using your client applications. They only have access to the data in a schema, how much access they have is defined by the business rules you define. Their login is handled by the Data Login Provider.
The Admin Login Provider, Developer Login Provider and Data Login Proivder settings define which of the login providers below is used to authenticate the user attempting to login. By default the Admin Login Provider is set to use the
StaticLoginProvider, the Developer Login Provider is set to
AdminServicesLogin and the Data Login Provider is set to
Default passwords are "Admin"/"Relativity", "Developer"/"Relativity" and "Data"/"Relativity", respectively.
The StaticLoginProvider is the simplest of the login providers, and the most useful for admin/developer login, or in the early development phase of your project. It works by simply letting you specify a list of valid usernames and passwords that will be accepted. This is the default login provider for all logins on a freshly installed Relativity Server or a freshly created domain.
The DbTableLoginProvider validates the username and password against a table in your database. It allows you to select a table from your schema, as well as two fields from that table that contain usernames and passwords, respectively. The Login will be verified by selecting from the table, and access will be granted if a row with matching username and password is found.
the DbCommandLoginProvider lets you validate the login against your database, but instead of simply querying a table, it will execute a command defined in your schema. You could implement the command to run a query, execute a stored procedure, or perform more some complex SQL. In order to qualify, the command must take two parameters (username and password) and return a Boolean.
The DbTableHashedLoginProvider validates the username and password against a table in your database, using BCrypt-hashed passwords with an optional salt. It allows you to select a table from your schema, as well as two fields from that table that contain usernames and password hashes, respectively. The Login will be verified by selecting from the table, and access will be granted if a row with matching username is found and the provided password matches the stored hash.
For password hashing to work, hashes must be stored in the database using the same system as used by the login provider itself.
To create a password hash to store, you can use the following .NET code
if (length(PasswordHashGlobalSalt) > 0) password = password+"."+PasswordHashGlobalSalt; // optional, when using salt hash = BCrypt.Net.BCrypt.HashPassword(aPassword, 11); // store this hash in db
To verify a password against the hash yourself (outside of Relativity's login), you can use:
if (length(PasswordHashGlobalSalt) > 0) password = password+"."+PasswordHashGlobalSalt; // optional, when using salt valid = BCrypt.Net.BCrypt.Verify(lPassword, PasswordHash); // true means password did match.
The latter code is what Relativity uses as well. Do note that when no Salt is configured in the provider, Relativity will verify the password "as is" (ie no trailing ".").
The LdapLoginProvider is the most complex one of the available login provider options. It can be used to connect Relativity to an existing LDAP server in your organization to validate logins. This can be very useful if you want your application to automatically share usernames and passwords with other non-Relativity, non-Data Abstract services in your company. Getting into the details of LDAP would go beyond the scope of this text, but if your organization is using LDAP, your LDAP administrator should be familiar with the required options.
Thew AdminServicesLogin option, available only for the per-domain login providers, simply indicates that rather than using separate logins, the same settings as for the server-wide Admin Login should be used here.
Note that the Admin Login Provider can only use the StaticLoginProvider and the LdapLoginProvider, as no schema and thus no database exists at that level.