Authentication Methods
Contents
There are three main types of authentication:
1) Local: The current Calpendo does the authentication. User names and encrypted passwords are stored in the Calpendo database.
2) Internal: These are built-in methods that allow Calpendo to send your user name and password to another system for authentication. Calpendo does not store your password in this case, but does handle it during login. The currently supported internal authentication methods include using an email server (SMTP or IMAP), any HTTP basic authentication system, or another Calpendo.
3) External: The web server that users connect to is configured to provide authentication, for example using a single-sign-on system or perhaps LDAP. In this case, Calpendo never sees users passwords, and authentication is solely the responsibility of the web server.
All systems automatically have Local authentication initialised but the administrator may also set up a number of non-local authentications and may switch off Local authentication. The administrator cannot switch off the authentication system they are currently logged in with, to ensure that they cannot be accidentally locked out.
Common Options For All Authentication Methods
Name |
Data Type |
Description |
Type |
String |
The type of authentication method. |
Name |
String |
The name assigned to this method. Must be unique. |
Login Allowed |
Boolean |
Whether users can login using this method. |
Hide Login Button |
Boolean |
Whether the login button is visible or not. |
New User Registration Allowed |
Boolean |
Whether new users can register using this method. If True then new users may register for this authentication method even if logins are not allowed. |
Allow Custom Nick Names |
Boolean |
Whether login nick names are allowed or are nick names identical to the login identifier. |
Local authentication has no additional options.
IMAP Authentication and SMTP Authentication
Name |
Data Type |
Description |
Host |
String |
The mail server's IP address or name. |
Security |
JavaEnum |
Choose the type of security to be used: None, STARTTLS, SSL/TLS |
Name |
Data Type |
Description |
URL |
String |
The address of the website doing the authentication. |
Realm |
String |
The name of the system, that is doing the authentication. |
Name |
Data Type |
Description |
URL |
String |
The address of the website doing the authentication. |
LDAP Options |
Data Type |
Description |
Host URLs |
String |
The address of the website doing the authentication. |
Port |
String |
The port to connect on. |
Security |
JavaEnum |
Choose the type of security to be used: None, STARTTLS, SSL/TLS |
Ldap Trust Server |
JavaEnum |
Only visible if Security is not None. Choose whether to Blindly Trust Server or Examine Security certificates as normal. |
Method |
JavaEnum |
Bind As User or Bind As Admin |
User DN |
String |
User name for access within LDAP |
LDAP Advanced |
Data Type |
Description |
Base DN |
String |
The starting point of the LDAP branch. |
Filter |
String |
Bind as User: The user provides their login name and password, and their is an attempt to connect (bind) to the LDAP server as that user and password. If a connection occurs, then the user is authenticated.
Bind As Admin: This is where a known DN and password is configured for a particular user (the admin), and then once connected to the LDAP server as that user, a search is performed for the user being authenticated. Once the user is found, the password the user provides is used along with the user DN to authenticate the user.
When choosing between these two methods, they each have advantages and disadvantages:
•bind-As-user cannot handle multiple formats of user DN, but it does not require an admin's user DN and password.
•bind-As-admin has the disadvantage of having to store an admin's user DN and password, but can handle multiple formats of user DN.
Name |
Data Type |
Description |
Login Name Header |
String |
The name of the HTTP header that will contain the user's login name (this defaults to X-Forwarded-User) |
Display Type |
JavaEnum |
How to display the frame that will contain the authentication handshake. If not hidden then choose its size. Choice of: Hidden, Inline, Popup, Redirect
Hidden, Inline and Popup all work by doing the authentication handshake in an iframe. Redirect works without an iframe, and so takes over the user's whole browser tab while the authentication is done. |
Cookies to remove on logout |
JavaEnum |
Defines which cookies will be removed at logout. Choice of : Remove no cookies, Remove all cookies, Remove some cookies.
Remove some cookies allows input to define which cookies are to be removed. |
Display Width |
String |
The width of the frame within the pop up or on the login page. |
Display Height |
String |
The height of the frame within the pop up or on the login page. |
Attribute Map |
Set |
Allows mapping from headers to user property. if multiple are mapped to the same property the first value to populate is used. |
Name |
Data Type |
Description |
Login Name Header |
String |
The name of the HTTP header that will contain the user's login name (this defaults to X-Forwarded-User) |
Display Type |
JavaEnum |
How to display the frame that will contain the authentication handshake. If not hidden then choose its size. Choice of: Hidden, Inline, Popup, Redirect
Hidden, Inline and Popup all work by doing the authentication handshake in an iframe. Redirect works without an iframe, and so takes over the user's whole browser tab while the authentication is done. |
Cookies to remove on logout |
JavaEnum |
Defines which cookies will be removed at logout. Choice of : Remove no cookies, Remove all cookies, Remove some cookies.
Remove some cookies allows input to define which cookies are to be removed. |
Display Width |
String |
The width of the frame within the pop up or on the login page. |
Display Height |
String |
The height of the frame within the pop up or on the login page. |
Attribute Map |
Set |
Allows mapping from headers to user property. if multiple are mapped to the same property the first value to populate is used. |
Name |
Data Type |
Description |
Proxy URL |
String |
The URL which will hold the proxy server information. |
Proxy Authentication Name |
String |
The external authentication name method to access the proxy server. |
Identity Provider |
Mapped Int |
The Entity ID of the identity provider to use. If not set users will be asked to select their institution. |
While you can use HTTP basic authentication using an internal authentication method, it's also possible to set up HTTP basic authentication using external authentication. The following shows an example of an excerpt from an Apache virtual host configuration that sets up HTTP basic authentication and also passes the REMOTE_USER setting that it generates to Calpendo by setting the X-Forwarded-User HTTP header. You can use any header for this, but you need to tell Calpendo which header to examine by setting the Login Name Header property. When Apache rewrites URLs, you protect /private under the rewritten URL
When installing Calpendo onto a local server, the Apache configuration is required to capture Apache environment variables and make them available as HTTP headers.
The shibboleth External Proxy authentication run by the Exprodo Software service at https://sp.exprodo.com/ exposes many standard attributes as HTTP headers, although each identity provider may choose to expose each of those attributes to Calpendo or not.
The external authentication in Calpendo can now be set up to provide a mapping from an HTTP header to any string property of a user. Multiple headers can be mapped to the same user property, in which case the first one which is actually populated with a value is the one that will be used.