English

Authentication and User Accounts

Phdhub suppors a number of authentication mechanisms:
  • Shibboleth
  • Social networks
  • OpenID
  • a combination of username and password
Note that your administration might decide to support only some of the items above.

This page describes in details each of the authentication mechanisms.

Shibboleth

Our support for Shibboleth-based systems is done via IDEM identity and access federation. This is the best way to connect users of an organization with PhdHub service if your university already has a Shibboleth service running.
When user chooses to authenticate using this method, PhdHub passes the request to the underlying Identity Provider (in Shibboleth terminology it is called IdP) and "forgets" about that user for a moment, until she comes back from the IdP (normally upon successful authentication). While coming back to PhdHub (or SP, Service Provider, using Shibboleth terms), the user "drags" with her some additional information created and encrypted by the IdP. It is said that IdP releases requested attributes (or assertions) to the SP. This is the key point: exactly this information allows user's Identity Provider and PhdHub to "connect" together. 

The minimum information PhdHub requests from an IdP is eduPersonTargetedID which can be described as "A persistent, non-reassigned, privacy-preserving identifier for a principal shared between identity provider and service provider".

Some Identity Providers might give up additional information (attributes) about a user. Although PhdHub recognizes such additional attributes as First Name, Given Name and Email, our service does not require an IdP to release this information. If, however, the additional information was indeed released by an IdP, PhdHub takes it into consideration and uses it to help users pre-compile known fields. For instance, a text field prompting a user to type in their email address would be already filled in should the IdP provide this information along with eduPersonTargetedID attribute during the authentication flow. No other use of the provided information is being made. For more details on users privacy topic please consult our Privacy Policy.

To sum up, Shibboleth authentication has a number of advantages:
  • The authentication is delegated to your university so you are in complete control of the user credentials.
  • Passwords are never being stored within PhdHub service.
  • Your users are not required to remember a yet-another-password.
If your university is already a member of IDEM AAI, no additional setting required to connect PhdHub with your university accounts and is a preferred method of connecting your Shibboleth service with PhdHub. Otherwise, if your university cannot make it to IDEM AAI members for some reason but has already a Shibboleth service setup, please contact support@phdhub.it and we will work something out together.

If your university does not currently have a Shibboleth service running, there might be a drawback of using this authentication mechanism as your tech staff will get additional workload with setting up and maintaining additional in-house service.

Social Network Accounts

This method is a perfect solution in cases where your organization does not currently have a Shibboleth service running and your internal policy allows usage of external accounts.
 
PhdHub supports authentication against the following social networks:
  • Google+ (Google Accounts)
  • LinkedIn
  • Twitter
  • Facebook
It is sufficient that your school administration enables External Account Providers option in the School Settings. Once enabled, your users will see an additional section on a Sign in page:


The above list is based on OAuth 2.0 and OAuth 1.0a flows behind the scenes. If your organization already has an internal OAuth 2.0/1.0a compliant service, please contact support@phdhub.it and we will be happy to help you connect the both systems together.

OpenID

OpenID is in a development state. If your university has an internal OpenID provider please contact support@phdhub.it for a specific inquiry.

A username/password pair

This is a standard username/password authentication mechanism and is enabled by default as we realize not every entity has their own centralized accounts system. In this case administration office of your Phd school will have to set an initial password for every user. Subsequently, users will be able to modify their passwords.

In this scenario passwords are stored within PhdHub service internally. We take security very seriously so passwords are never stored in "clear text" and always being encrypted with strong algorithms. Additionally, we are using timestamps to "rotate" encrypted password bits. This way, passwords stored internally are impossible to decrypt, not even for PhdHub technical staff.

We recommend using this method only if none of the other methods described above suits your setup.