Overview
Federated Authentication is a method of site login that utilizes established account credentials from a trusted authentication provider for logging into another site. The benefit is that users can login to a BLOX site using their Apple, Google or other credentials, instead of creating a BLOX User Account. As site registration is required for readers to post comments, submit content, and manage their User Dashboard, this simplifies the process. Additionally, our endpoints accept open ended referer_url parameters, but they are not followed until after the federated authentication process is completed.
BLOX CMS currently supports Apple ID, Facebook, Google, Newzware, OpenID 2.0, OpenID Connect, SAML, and Syncronex as Authentication Providers.
Apple ID Authentication
The following is required for setting up Federated Authentication using Apple ID.
Label: This is the provider display name that users will see within user login prompts.
Client ID: OAuth 2.0 Client Identifier valid at the Authorizations server.
Team ID: Enter the Team Identifier that is connected to the account that will generate the ID.
Key ID: The Key ID that is provided with the key created in the Apple Developer screen.
Apple Key File: Upload the Apple .p8 file.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Do not require signup verification (provider-verified accounts only): Users who authenticate through this provider and who the provider reports as verified will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
Follow these instructions to set up your credentials for Apple.
Facebook Authentication
The following is required for setting up Federated Authentication using Facebook. Federated Authentication supports one Facebook account. Users must have an already established Facebook account prior to utilizing this method of authentication.
Label: This is the provider display name that users will see within user login prompts.
App ID: The App ID value from the Settings panel of the Facebook app created to host authentication for the site.
App Secret: The App Secret value from the Settings panel of the Facebook app created to host authentication for the site.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
If you do not already have a Facebook Application set up, please refer to the following instructions: Facebook App ID for Connected Services AND Federated Login.
WARNING: If you get an error message called Embedded Browser OAuth Login, you will need to follow these steps:
- Navigate to https://developers.facebook.com and login.
- Click on the "Settings" button in the left navigation bar.
- Click on the "Advanced" button on the very top of the page. It is directly below the header.
- Scroll down to the "Client OAuth Settings" section.
- Turn on "Embedded Browser OAuth Login".
- Verify that "http://www.example.com/";;; is added to the "Valid OAuth redirect URIs" input.
- Scroll down to the bottom of the page and click on "Save Changes".
Google Authentication
The following is required for setting up Federated Authentication using Google. Federated Authentication supports one Google account.
Label: This is the provider display name that users will see within user login prompts.
Client ID: The Client ID value from the Google project credentials screen.
Client Secret: The Client ID value from the Google project credentials screen.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Do not require signup verification (provider-verified accounts only): Users who authenticate through this provider and who the provider reports as verified will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
To create a Google API Console project and client ID, refer to the following instructions: Creating a Google API Console project and client ID.
When completing Authorized JavaScript origins, enter the full domain path, for example: https://www.domain.com
For the Authorized redirect URIs, enter the following URL, while replacing www.domain.com with the BLOX site URL: http://www.domain.com/tncms/auth/google/
To obtain the Client ID and Client Secret, select the name of the project. Client ID and Secret will be located at the top of the page.
Newzware Authentication
The following is required for setting up Federated Authentication using Newzware.
Name: A unique name for this provider.
Label: This is the provider display name that users will see within user login prompts.
Template URL: This is the base URL of template.jsp, without any query parameters.
For example: https://example.com/ss70v2/site/common/template.jsp
Authentication URL: The XML authentication end-point of Newzware.
For example: https://example.com/authentication/auth70_xml.jsp
Login URL: This is the base login URL for login.jsp without any query parameters and without site.
For example: https://example.com/ss70v2/common/login.jsp
Site: The Newzware site identifier that users authenticate against. This is typically a 3-4 letter code.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
OpenID 2.0 Authentication
The following is required for setting up Federated Authentication using OpenID 2.0.
Name: A unique name for this provider.
Label: This is the provider display name that users will see within user login prompts.
Identifier URL: identifier is the domain name of the BLOX site, or would be the url of the endpoint as defined by the provider
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
A BLOX site can be used as an OpenID provider for other BLOX sites. You can also set up another BLOX site as your OpenID provider. The steps are the same as above. Clicking on the button will take you to the third-party BLOX site, where you verify your data, then it redirects you back to the BLOX site you were originally trying to sign in at.
OpenID Connect Authentication
The following is required for setting up Federated Authentication using OpenID Connect.
Name: A unique name for this provider.
Label: This is the provider display name that users will see within user login prompts.
Hostname: The domain or host name of the OpenID Connect server.
Client ID: OAuth 2.0 Client Identifier valid at the Authorizations Server.
Client Secret: OAuth 2.0 Client Secret valid at the Authorizations Server.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Automatically updated account details: Automatically update account that logs in with this provider. User account details such as First Name, Last Name, and Screen Name are now automatically synchronized. The provider must supply an email address and screen name. If this information is not supplied, or it it conflicts with another account on the site, the standard signup process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
SAML Authentication
The following is required for setting up Federated Authentication using Security Assertion Markup Language (SAML).
Name: A unique name for this provider.
Label: This is the provider display name that users will see within user login prompts.
Metadata URL: URL pointing to SAML 2.0 metadata XML file for the identity provider.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
Syncronex Authentication
The following is required for setting up Federated Authentication using Syncronex.
Name: A unique name for this provider.
Label: This is the provider display name that users will see within user login prompts.
Client ID: Syncronex Client Identifier valid at the Authorizations Server.
Client Secret: Syncronex Client Secret valid at the Authorizations Server.
Portal Path: XXXXXXX no tool tip.
Host URL: Host URL is typically formatted as https://synaccess--.syncronex.com/
Company: XXXXXXX no tool tip.
Property: XXXXXXX no tool tip.
Screen Name Prefix: Prefix for generated Screen Names for users.
Do not require signup verification (all accounts): Users who authenticate through this provider will not be required to complete a CAPTCHA to sign up for an account on your site.
Automatically sign up new users: Automatically sign up new users who log in with this provider. The provider must supply an email address and screen name. If this information isn't supplied, or conflicts with another account on the site, the standard sign up process will be presented.
Disable this provider: Temporarily prevent this provider from being used, without deleting its configuration information.
Disambiguation - is this still a thing? what creates this tab?
Disambiguation is the process by which an arbitrary identifier entered by the user during authentication is resolved to a specific provider. In a common disambiguation scenario, a user entering an identifier of "example@gmail.com" would be seen as a candidate for OpenID authentication with Google as the provider. Each provider may be given one or more patterns on the Disambiguation section. A disambiguation pattern delimited by forward slashes (/) will be checked against the identifier as a regular expression. All other patterns will be checked as case-insensitive substrings.
Alternative End-Points - is this still a thing? what creates this tab?
For an authentication request to succeed this check the end-point URL declared when the user is redirected back to the consumer must be equal to the identifier URL or one of the URLs under End-Points of a configured provider. End-point URLS will generally start with https://.
NOTE: Not all users will have permission to access this setting.
You can determine what happens when the user reaches their maximum number of login slots. If the first (default) option is selected, the oldest login will be forced closed when a new login is attempted. If the second option is selected, the oldest login will only be forced closed if the maximum 'age' has been exceeded. If it has not been, then the new login attempt will be denied.