|
|
|
|
|
connectDaily has a flexible authentication structure. You can pick the authentication method that makes the most sense for your organization.
Provider |
Requirements |
Benefits |
Drawbacks |
|---|---|---|---|
BCrypt Hash DEFAULT |
Database |
Passwords are stored using a salted hash. Reasonably secure against lookup tables. Transparently upgrades plaintext or MD5 passwords on successful login. |
Requires SSL to keep password from being exposed on the network. |
Cookie Based Single Signon Authenticator |
External Web Application |
Users can signin to one web application and then be transparently logged into connectDaily. |
Somewhat complicated to configure. |
LDAP/Active Directory Authentication |
LDAP directory (NDS, OpenLDAP, etc) |
Centralized password repository. User has only one password for network and application. Optionally, directory can be used to control application security. |
More complex to configure and setup. Requires SSL to keep password from being exposed on the network. |
Container Authentication |
Authentication Services provided by servlet container or Web Server |
Single Sign-on between applications. |
|
If your organization is large and has standardized on an LDAP directory service, then we recommend that you use this as the authentication provider for connectDaily.
The source code for each authentication provider is also in the cdaily-5.0.0/WEB-INF/misc/security directory. If you wish, you can create your own authentication provider that provides login services to Users.
One final thing to note about the LDAP authentication providers: you will still have to add your Users to the connectDaily database before they can login. If you want to eliminate this step, you will have to override the LDAP provider to create the Users if they do not exist.