RADIUSdesk

Trace:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
user_guide:social_login [2016/05/09 20:14] – [RADIUSdesk side] adminuser_guide:social_login [2019/06/25 13:53] (current) – [Facebook side] admin
Line 1: Line 1:
 ====== Social Login overview ====== ====== Social Login overview ======
   * Social Logins are also supported in RADIUSdesk and is configured as part of the **Dynamic Login Pages**.   * Social Logins are also supported in RADIUSdesk and is configured as part of the **Dynamic Login Pages**.
-  * Unlike some hardware vendors which **Only** support Facebook (https://www.facebook.com/business/facebook-wifi), RADIUSdesk makes use of **Opauth** which is a Multi-provider authentication framework. +  * Unlike some hardware vendors which **Only** support Facebook (https://www.facebook.com/business/facebook-wifi), RADIUSdesk makes use of **Hybridauth** which is a Multi-provider authentication framework. 
-  * This allow you to include other providers besides Facebook. +  * This allows you to include other providers besides Facebook. 
-  * Opauth refer to these providers as **Strategies** and include support for: +  * **Hybridauth**  includes support for many providers.  
-    * Bitbucket, Facebook, Flickr, Github, Google, Instagram, LinkedIn, (Windows)Live, IopenID, Twitter etc.+    * The lastest list of supported providers can be found on this page: [[https://hybridauth.github.io/providers.html|Hybridauth Supported Providers]]
   * Using this approach we are now <wrap em>free</wrap> to use the hardware of <wrap em>our choice</wrap>. This include any hardware which can run a CoovaChilli captive portal or any Mikrotik captive portal.   * Using this approach we are now <wrap em>free</wrap> to use the hardware of <wrap em>our choice</wrap>. This include any hardware which can run a CoovaChilli captive portal or any Mikrotik captive portal.
  
Line 16: Line 16:
 ===== The basics ===== ===== The basics =====
  
-  * RADIUSdesk supports three **Strategies** out-of-the-box.+  * RADIUSdesk supports three **Providers** out-of-the-box.
     * Facebook     * Facebook
     * Google+     * Google+
     * Twitter     * Twitter
-  * Each Dynamic Login Page has an option where we can configure zero or more of the supported Strategies. +  * Each Dynamic Login Page has an option where we can configure zero or more of the supported Providers. 
-  * If one is configured there will appear a Social Login button for that Strategy on the Dynamic Login Page.+  * If one is configured there will appear a Social Login button for that Provider on the Dynamic Login Page.
   * When the user then click on the **Login with Facebook** button they will be:   * When the user then click on the **Login with Facebook** button they will be:
     * Authenticated to the captive portal with a temporary account and redirected to the authentication provider's login page.     * Authenticated to the captive portal with a temporary account and redirected to the authentication provider's login page.
Line 32: Line 32:
  
   * The user used for the temporary session.   * The user used for the temporary session.
-  * The configuration of the Strategies+  * The configuration of the Providers
     * Common to all     * Common to all
     * Facebook     * Facebook
Line 41: Line 41:
  
 ====== The user used for the temporary session ====== ====== The user used for the temporary session ======
-  * Because we can make use of multiple Strategies we decided to rather not going the route of providing a large and ever changing list in the Walled garden for each strategy of the captive portal in order for you to reach the authentication provider.+  * Because we can make use of multiple providers we decided to rather not going the route of providing a large and ever changing list in the Walled Garden for each provider of the captive portal in order for you to reach the authentication provider.
   * We make use of a temporary user account which will log the user into the captive portal and then redirect them to the authentication provider's login page.   * We make use of a temporary user account which will log the user into the captive portal and then redirect them to the authentication provider's login page.
   * You can choose per Dynamic Login Page which temporary user to use.   * You can choose per Dynamic Login Page which temporary user to use.
Line 61: Line 61:
   * Click **Save** to commit your selection.   * Click **Save** to commit your selection.
   * At his stage we have not defined any providers and there will thus not be any Social Login buttons displayed on the Login Page.   * At his stage we have not defined any providers and there will thus not be any Social Login buttons displayed on the Login Page.
-  * Next we will cover the common elements among the Strategies which you can define.+  * Next we will cover the common elements among the Providers which you can define.
  
 ------------------- -------------------
  
-====== Common to all Strategies ====== +====== Common to all Providers ====== 
-  * Each Strategy which you define has some common elements.+  * Each Provider which you define has some common elements.
   * You have to choose:   * You have to choose:
     * Whether to auto-create a **Voucher** or **Permanent User** the first time a user authenticated with success using the authentication provider.     * Whether to auto-create a **Voucher** or **Permanent User** the first time a user authenticated with success using the authentication provider.
     * Specify the **Realm** this Voucher or Permanent User should belong to.     * Specify the **Realm** this Voucher or Permanent User should belong to.
     * Specify the **Profile** this Voucher or Permanent User should belong to.     * Specify the **Profile** this Voucher or Permanent User should belong to.
-    * Specify if the Strategy is **Enabled** or not.+    * Specify if the Provider is **Enabled** or not.
     * Specify if the system should record / update the personal info obtained from the authentication provider.     * Specify if the system should record / update the personal info obtained from the authentication provider.
  
Line 87: Line 87:
   * To implement Facebook integration you need to create a Facebook application on Facebook and then also use those details in RADIUSdesk.   * To implement Facebook integration you need to create a Facebook application on Facebook and then also use those details in RADIUSdesk.
 ===== Facebook side ===== ===== Facebook side =====
-  * Active the Developer side of Facebook and create a Facebook application. +  * Active the Developer side of Facebook and create a Facebook application. ([[https://developers.facebook.com/apps|https://developers.facebook.com/apps]])
-  * Go to the **Settings** of the application and specify the URL of the server where you will serve the login pages from. +
-  * Beware that Facebook require that the redirected URL be precisely the same as the one specified. This means that if your login page on the captive portal looks like http://69.30.244.107/ you also have to mirror that. If on the other hand you use a hostname, be sure that they also match e.g http://rd01.wificity.asia/+
  
-{{ :user_guide:social_fb_fb1.png |}} +  * Below you can see how it looks when we have not yet defined any applications. Go to **My Apps** -> **Create New App**. 
-  * Record the application's **App ID** and **App Secret** since we will need it in RADIUSdesk. + 
-  * Select the **Status and Review** menu item and make sure the application is live and available to the general public.+{{:user_guide:facebook:fb_new_ap1.png?nolink|}} 
 + 
 +  * You will need to specify a name for the App and also a valid contact email address. 
 + 
 +{{:user_guide:facebook:fb_new_ap2.png?nolink|}} 
 + 
 +  * You will also be required to verify that you are human 
 + 
 +{{:user_guide:facebook:fb_new_ap3.png?nolink|}} 
 + 
 +  * Facebook will now generate your App with a unique ID which you will later use in RADIUSdesk's config. 
 +  * The App itself will have settings which you can access. Under the **Basic** settings you will find the **App Id** and **App Secret**.  
 +   * Record the application's **App ID** and **App Secret** since we will need it in RADIUSdesk. 
 + 
 +{{:user_guide:facebook:fb_new_ap6.png?nolink|}} 
 + 
 +  * You can now go to the **Products** menu in the bottom left. Click on add a  **Product**. We need to add **Facebook Login**. This product will allow for **OAuth2** based authentication which is what we need for Social Logins. 
 + 
 +{{:user_guide:facebook:fb_new_ap7.png?nolink|}} 
 + 
 +  * Ignore the **Quickstart** options and go to the **Settings** menu on the left for the **Facebook Login** 
 + 
 +{{:user_guide:facebook:fb_new_ap8.png?nolink|}} 
 + 
 +  * Facebook tighten their security a lot and one now have to explicitly specify the URL's which OAuth will redirect back to. (Our RADIUSdesk server) 
 +  * They also force you to use **https** on the server you specify that you will be redirecting back to. 
 +  * Our server here is **dev.radiusdesk.com**. Please change this in order to fit your environment. 
 +  * The URI in our deployment is https://dev.radiusdesk.com/cake3/rd_cake/third-party-auths/index.json 
 +  * This is the value we specify in the **Valid OAuth Redirect URIs** item. The other items we leave as is (Defaults). 
 + 
 +{{:user_guide:facebook:fb_new_ap9.png?nolink|}} 
 + 
 +  * After you saved this there is one item outstanding before you can configure the RADIUSdesk side. 
 +  * Top left is a switch to take the App out of development and make it live. Make the App live by toggling the switch to the **On** position
 <WRAP center round alert 90%> <WRAP center round alert 90%>
-Failing to make the application available to the general public will render the Facebook authentication useless.+Failing to make the application live  will render the Facebook authentication useless.
 </WRAP> </WRAP>
-{{ :user_guide:social_fb_fb2.png |}} 
  
  
Last modified: 2016/05/09 20:14