Identity sources

Shield checks each password against your own MySQL database or your LDAP directory. Your users stay where they are.

MySQL#

Shield connects to your database and reads one row from your users table at sign-in.

Requirements#

A users table with a username column and a password column.
Passwords stored as bcrypt hashes. A row whose password is not a bcrypt hash cannot sign in.
A dedicated database user for VERISCO. Never give it root.
A network path from VERISCO to the database, or the connector, which carries it through a tunnel.

Connection fields#

Field	Notes
Host, port	Port 3306 unless yours differs.
Database name
Username, password	The dedicated user. The password is encrypted at rest.
Table name	Your users table.
Username column	What your users type to sign in.
Password column	The bcrypt hash.
Email column	Optional. Required for email codes and email confirmation.
Role column	Optional. Becomes the roles in the signed identity your application receives.

Access mode#

You choose how much VERISCO may do in your database.

	Read-only	Read and write
Grant needed	`SELECT` on the users table	`SELECT`, and `UPDATE` on the password column
Sign-in	Yes	Yes
"Forgot password?" on the sign-in page	Not offered. Passwords are changed in your own application.	Offered. The new password is written to your table as a bcrypt hash.
Password policy	Not applied, and the page is shown disabled with the reason.	Applied when a password is set through VERISCO.

Read-only is the default, and the reason most teams can say yes to Shield: nothing VERISCO does can alter your data.

Encryption in transit#

The connection to your database is encrypted. When the database is reached through the connector, the hostname on its certificate cannot match the tunnel's address, so VERISCO verifies the certificate's chain against the certificate authority you supply in your directory settings. On a standard MySQL installation that file is ca.pem in the data directory. Without it the connection is still encrypted, the certificate is not verified, and your integration status says so.

LDAP and Active Directory#

Shield binds to your directory with the user's own credentials. If the bind succeeds, the user is authenticated.

Connection fields#

Field	Notes
Connection URL	`ldap://` or `ldaps://`.
Users DN	The branch that contains your users.
Bind DN, bind password	The account VERISCO searches with.
Username attribute	Usually `uid` on LDAP, `sAMAccountName` on Active Directory.
Email attribute	Usually `mail`.
First and last name attributes	Usually `givenName` and `sn`.

Any LDAPv3 directory works, including OpenLDAP and Microsoft Active Directory.

Reaching your directory#

This is a separate question from your deployment mode.

	How	When
Direct	VERISCO opens the connection itself.	Your database is reachable from VERISCO.
Through the connector	The connector's tunnel carries it.	Your database is on a private network. Available in connector mode.

A tunnelled directory has to be proven once before your tenant can go live. Use Test my user directory on your onboarding page.

What Shield never does#

It does not copy your users or their password hashes.
It does not create, rename or delete a user in your directory.
In read-only mode it does not write to your database at all.

Something missing or wrong on this page? Tell us and we will fix it.