Alpha Anywhere Alternative Login - Authentication and Authorization Using Social Network Credentials
- Configuring the System to Use Social Networks for Authentication
- Step 1 - Set up a developer project with the desired social network (provider)
- Step 2 - Set up named resource providers in Alpha Anywhere
- Step 3 - Configuring the security system for Alternative Authentication.
- Step 4 - Adding Alternative Authentication features in the UX Component
- Step 5 Configure publish profile as required
The Alpha Anywhere web security system now supports login using credentials for a social network such as Google or Facebook. This gives the user multiple ways to log into an Alpha Anywhere application.
The Alpha Anywhere web security system now supports login using credentials for a social network such as Google or Facebook. This gives the user multiple ways to log into an Alpha Anywhere application. A user can now log in to an Alpha Anywhere application using either:
Their Alpha Anywhere security credentials - the userid/user name and password assigned to the user when their account in the Security Framework was created.
Their credentials for a social network where they have an account - the user will be directed to a login page provided by the social network where they will enter their credentials.
Alpha Anywhere currently supports the following social networks that provide user authentication.
- Live Connect (Microsoft)
The login using social network credentials feature (i.e. the 'alternative' login feature) can only be used in conjunction with the built-in Alpha Anywhere web security system. You cannot use this feature if you are not using the Alpha Anywhere web security system. That's because the 'alternative' login is simply an alternative means for logging into an account in the Alpha Anywhere security system.
As a convenience, the security system exposes a feature that can automatically create a new account in the security system if a user logs in with social network credentials and no matching account is found in the security system.
If you enable the 'Alternative Login' feature then you should set the table type for your web security tables to SQL. Do not use DBF tables for your security tables.
Alpha Anywhere Community Edition applications can only be published to Alpha Cloud. Local DBF tables are automatically created for testing security in Community Edition in the development environment. The Security Data Type, Use DataLink File, and Active Directory properties are not available in Community Edition.
When using the 'alternative login' feature, the Alpha web security system is still used and the user must have an account in the Alpha Anywhere web security system. Once they are authenticated and logged in, the security system will use the permissions and information defined in the Alpha web security account.
There are options to create a new account for an authenticated user if they don't already have an account in the security framework, and to add the alternative login to an existing web security account.
The alternative authentication methods are currently only available in Action Scripting in the UX component.
When a user elects to use an alternative login, they will be redirected to a page managed by the provider. If the login is successful, the system will look for an existing account in the Alpha Anywhere web security system that is associated with that login. If one is found, they will be logged in automatically with the permissions defined for the account.
If they don't have an associated account in the Alpha Anywhere web security system, a new account can be created automatically. The new account associated with an alternative authentication will use the user identification supplied by the provider (normally an e-mail address) and attempt to create a userid based on that identifier that meets the validation rules in the web security system.
A new user added by the alternative login process will initially not have a password in the Alpha Anywhere web security system, although one can be added at a later date. The new account will use the permissions allowed by the default security group if one was defined in the security settings.
After the login is successful or cancelled, the original page that contained the UX will do a full page reload. The user may be redirected to another page if a URL is defined in the After Login Event in the security settings.
- Video 1 - Setting up the Providers
- Video 2 - Creating Named Providers
- Video 3 - Configuring Web Security
- Video 4 - Adding Alternative Login to a UX Component
- Video 4 - Testing Alternative Login
A developer project must be set up in each social network that will be used for user authentication. The developer must have an account with that network to be able to set up a project. The project provides special project credentials used by Alpha Anywhere to connect to the social network. These normally include some special keys such as a client id, also sometimes referred to as an application or app id, and a secret key. Most providers also require setting one or more URIs to use as an allowed redirect URI after login. Each Alpha Anywhere application will normally have a different redirect URI.
The developer may elect to use the same provider project for both the development system and a deployed application, or they may create a separate project for every published location. Alpha Anywhere provides a method to change the provider credentials at publish time.
The project name should be descriptive and "friendly" as it will be shown to the user on their sign on screen. It can be the name used to describe the Alpha Anywhere application.
There are notable differences between providers. For example, most providers allow multiple redirect URI addresses in a project. Twitter currently only allows one, so each published location will need a unique Twitter project. Some providers will not allow a URI that cannot be tested by their system and may reject a URI containing "Localhost", or a server name on a local network. it may be necessary to use an IP address in a redirect URL such as 127.0.0.1 in place of "localhost" when testing the system locally.
Here are some links to the provider project sites. They all include documentation on the projects as well as how to create logins, etc. Alpha Anywhere has done all of the hard work, so you only need to set up a project. To access these project sites, you will be required to log into the desired social network.
Go to the credentials menu option to get the desired keys. You will need the client Id and Client secret to configure the resource in Alpha Anywhere. Either initially leave the redirect URIs section blank or put in a placeholder URI such as http://MyApp/index.a5w to be able to save the settings.
Use 'Create a new app' to build a new application, or edit any application shown. Go to the settings menu option. The basic tab will show the App ID and secret, which will both be needed in Alpha Anywhere. The redirect URI and other options can be configured on the Advanced tab. The Valid OAuth redirect URIs can initially be left blank, and one or more URIs added later. You must set Client OAuth Login to true. It is suggested that you also set App Secret Proof for Server API calls to true. This setting is supported in Alpha Anywhere.
By default, a Facebook application is initially in development mode and only users listed as administrators, developers, or testers can use the authentication. The application must be made public to allow any user with a valid Facebook account to log in. Follow these steps to make the application public.
Go to "Settings" and make sure there is a Contact Email address entered
Go to "Status and Review", and set the "Do you want to make this app and all its live features available to the general public?" to YES.
Use 'Create a new app' to build a new application, or edit any application shown. Go to the settings menu option. Note that Twitter only allows one Callback URL (redirect URL). Some URL may be rejected , such as "localhost". In that case, use 127.0.0.1 as the server address if testing on local host. Check the option to allow the application to be used to Sign in with Twitter. Go to the API keys tab and obtain the API key and secret. They will be needed in Alpha Anywhere.
If you are asked to log into Linkedin from the address above, you may be directed to your profile home page. In that case, use the above link again to get to the developer network. Use add a new application to build a new application, or edit any application shown. Linkedin may show multiple authentication methods. Alpha Anywhere uses OAuth 2.0. Record the API key and Secret Key as they will be needed in Alpha Anywhere. The redirect URLs can be left blank. The default scopes should include r_emailaddress and r_basicprofile.
Use 'Create application' to build a new application, or edit any application shown. Click on the application name to open the information page. Click 'edit settings' to edit the settings. The Root domain is set in API Settings and must be a domain accessible from the internet. It cannot be 'locallhost' or an IP addrress of a local machine. You can enter multiple redirect URLs. You will need the client Id and Client secret from the App Settings to configure the resource in Alpha Anywhere.
See the next step on how to get the redirect URLs that are appropriate for a particular web project. The provider project accounts above must be reopened and the correct redirect URL entered when it is available.
Once the desired projects are defined, and the appropriate keys and secret keys are recorded, Alpha Anywhere can be configured to connect to the projects. This is done in the Web Project Properties by setting up "Named Providers". All published instances of the project use the same named providers, although the actual connection keys used by a named provider can be changed at publish time to point to a different project on the social network.
Click on the smart button on the right to open the genie to create Named Resources.
This will show a list of defined named resources, allow editing any resources, and adding new ones. It is permitted to have more than one Named Resource for a provider, but not currently recommended. Select Edit or New to open the window to add the credentials recorded in Step 1 from the provider. Select the provider for this resource and enter the appropriate key values.
The genie has a link to open another window that shows possible redirect URL values for the local host system. You can select one and copy it to the clipboard. This redirect URL MUST be placed in the appropriate section in each developer project following the links and instructions in the Step 1.
Security Settings Options - There are a number of options that can be set in the Security Settings.
This activates the alternative login options. A new security table will be added when the security settings are saved if the table does not already exist. (Be sure to set the 'Security Table Type' to 'SQL' when 'Alternative Login' is enabled.)
This will automatically add an authenticated user if they are not already in the web security system. A unique userid will be generated using the user identifier from the provider to meet the userid configuration requirements in the security system. If the new user information is accepted, they will be logged into the system when the information is saved.
This will link an authenticated user to an existing security account that has the same user identifier as supplied by the external authentication. This is normally an e-mail address.
For example, the user has an account in the Alpha Anywhere web security with a user id that is the e-mail address '[email protected]'. They attempt to login through Google and the e-mail associated with the Google account is also '[email protected]'. The system can automatically link the Google authentication to the existing account if this option is selected, and the user will automatically be logged in using their existing permissions.Not all providers supply a user's email address. The user can not be added automatically or linked to an existing account if an email address is not provided and the Alpha Anywhere web security uses an email address for the userid. The alternative login can be added to an existing web security account as explained in Step 4.
This defines a server-side event that can be called after login using an alternative provider. This can be used to add session variables, or redirect to a different page.
The security settings also have an option to set a default security group. This group will be added to a new account added by alternative authentication.
The UX component has a number of actions available in Action Scripting to support alternative logins. These actions can be added to a button, a hyperlink, or an image. These actions can only be added if Alternative Authentication is allowed.
Login using account credentials from an alternative login provider such as Google. This action will redirect the user to the provider's login page and after login will return to the original page, a page specified on the security settings, or a page set in the after login event for alternative logins.
Add account credentials for an alternative login provider such as Google to a current logged in user. The action will redirect to the provider login page and then reload the original page.
A control such as a list control can show a list of all alternative authentications listed for a user. The action will delete the authentication selected in the control if the authentication can be deleted.
The alternative login uses some of the existing actions and properties of the UX component.
The client side events for 'canLogin' and 'afterFailedLogin' will still fire with the alternative login. The other login related client side events and the server side events for login will not fire.
The UX properties for Login has an option for "Has integrated alternative login functionality" This will show the properties for the placeholder for login errors, and the option to customize login failure messages. Any errors found during the alternative login will show in the placeholder. If a placeholder is not defined, the errors will show in an A5 message box. The alternative login error messages can be customized.
Any action to go to an alternative authentication provider page will cause a full page reload.
The alternative login can be added to any UX component. The integrated login functionality does NOT need to be selected to add the login. The properties in the UX Login section have an option to select 'Has integrated alternative login functionality' if 'Allow Alternative Login' is set in the security settings for the project. The properties to add a placeholder for errors and the option to customize login failure messages will be shown if either 'Has integrated login functionality' or 'Has integrated alternative login functionality' is checked. If a placeholder control is not defined, any errors will show in a pop-up window.
Add a button, hyperlink or image to the UX for the alternative login. Images for Google can be found at:
Other providers can supply button images from their developer sites.
Other login controls can be added to the UX but are optional and only required if login with a userid and password will be supported.
A new user added by alternative authentication will initially use the default security group defined in the security properties.
The alternative login process will reload the original page that contained the UX component after The code in the security system 'After Login Event' will run after a successful login using an alternative provider.
The user may have logged in using a userid and password (i.e. the credentials for their account in the Alpha Anywhere security system) and desire to associate a social network login (e.g. a Google login) with their account. A UX component can be used to add an Alternative Authentication to any user currently logged into the system. This component should be on a page or panel only accessible after a user is logged into the system.
The alternative login uses the existing web security system and tables. Therefore any method used to edit users in the web security system can be used to edit users who have alterative logins. If a user has an alternative login, a password is not required when the record is edited, although one could be added is the user will be allowed to login with a regular login form.
The alternative logins for the current logged in user can be shown in a list control or similar control. A list of alternative logins for the current user can be found using the Xbasic function a5ws_GetAltLoginListForCurrentUser(). This function will return a list of alternative logins in the format 'Provider - User identifier in provider'. Typically, the user identifier in the provider is an e-mail address.
A published project can use the same provider project as the development system except in the case where the provider only allows a single redirect URL. The publish profile genie allows using a different provider project with different keys. The named resource name does not change. The option is not available in the Local Webroot profile as it will use the credentials defined in the development project. All other publish profiles include an option to edit "Named Resource Providers".
This option opens a genie that is similar to the genie used in Web Project Properties. However, a project can not be added or deleted. The redirect URL shows possible redirect URLs based on the defined Base URL in the publish profile. The edit option allows changing the key and secret key to point to a different provider project