With Remote Authentication enabled, users can login to your site via any authorized external service and act as a regular user.
This allows you to disable anonymous comments and make it easier for people to comment (they don't have to sign up on yet another site (yours) they can use a pre-existing central account to make comments).
To enable Remote Authentication:
With Remote Authentication enabled, the user is presented with a select box on the login screen to choose the login service. This will default to your site, but allow them to choose an external service. Users are authenticated via their remote username and password, and if they pass authentication a local account is created on your site that is slaved to that remote account. These local slave accounts can be banned, have special permissions, etc. just like any regular site user. The account creation process is the same as for local accounts, so all custom functions and plugin notifications are carried out as normal. In addition, the user is added to the group 'Remote Users' allowing you to automatically grant/deny specific permissions to all remote users.
When a new account is created, the local username for that account is set to the remote username. However, if there is already a user in the system with the same username a call is made to CUSTOM_uniqueUsername passing in their remote username. This allows the admin to supply a custom function to ensure unique usernames for all users.
It is not necessary to have unique usernames. This does not break the security of a local user or remote users login, as the full remote username and service are stored locally to avoid collision and internally users are identified by a unique number. However, if you want to ensure it is clear who has posted a comment or article by the name displayed, this function allows you to ensure uniqueness.
To disable a specific service, simply remove the (servicename).auth.class.php file from /private/system/classes/authentication and that remote service will no longer be available to your users.
Currently authentication modules are available for:
If you wish to add further services you will have to write custom modules to do so. This can be done by creating a PHP file named ServiceName.auth.class.php which declares a class called ServiceName with a method called authenticate. Authenticate takes username and password as arguments and should return a boolean. The class should expose an 'email' property and attempt to provide the users valid email address if this can be aquired from the remote server. If that information is available, the class can also provide the user's full name ('fullname' property) and homepage ('homepage' property).
The idea behind OpenID is to get rid of the need to register separately with all the websites out there that require registration before you can use them. Instead of having to keep track of all the different accounts, you can use one login on every website that supports OpenID.
To quote the OpenID homepage:
OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience. You get to choose the OpenID Provider that best meets your needs and most importantly that you trust. At the same time, your OpenID can stay with you, no matter which Provider you move to. And best of all, the OpenID technology is not proprietary and is completely free.
OpenID is a free and open protocol. It is not owned by any corporation.
OpenID support in glFusion differs slightly from the Remote Authentication support, but only in that it requires a separate login prompt.
To activate OpenID support, go to the Configuration Admin panel:
Configuration > Users and Submissions > Users > User Login Method[openid] Set this option to “true”, then save the configuration change. When you log out, you will see a new login prompt in your site's User Functions block, below the normal login options:
As the “http” suggests, your OpenID is really a URL that you use for the login (hence the need for a separate login prompt). Note that you will not enter your password on the site you are about to log in to. Instead, you will be taken to your OpenID provider (the place where you registered your OpenID) and enter the password there. So the glFusion site will never see your OpenID password - it will only get an “okay” back from the OpenID provider if you authenticated successfully.
Once a user has logged in via OpenID, they are just like any other glFusion user. They can be added to groups, change their profile, do whatever else you allow your users to do on your site. And yes, OpenID users can also be banned.
Users that log in through OpenID are automatically added to the “Remote Users” group.
Currently, only OpenID 1.1 is supported (the current protocol version is 2.0, but it is mostly backward compatible).
glFusion can only act as an OpenID Consumer (i.e. allow login with an OpenID) but not as an OpenID Provider (i.e. provide OpenIDs for use with other sites).
The glFusion development team is currently working on integrating OAuth-based service integration with glFusion. This will enable users who have FaceBook, LinkedIn and/or Twitter accounts to login to glFusion using the credentials that they have established with that service. This section is a placeholder which is linked to directly by the glFusion Configuration help file.