This feature requires the social-auth-app-django library to be installed. Starting with Tethys 5.0 or if you are using micro-tethys-platform, you will need to install social-auth-app-django using conda or pip as follows:
Tethys Portal supports authenticating users with several social authentication and single sign on providers such as Google, Facebook, and LinkedIn via the OAuth 2.0 method. The social authentication and authorization features have been implemented using the Python Social Auth module. Social login is disabled by default, because enabling it requires registering your tethys portal instance with each provider.
Enable Social Login
Use the following instructions to setup social login for the providers you desire.
Caution
Beginning with Tethys Platform 3.0 you must configure the social auth settings in the portal_config.yml file. See Tethys Portal Configuration for more details on how to create and configure this file. For instructions on how to configure social auth for previous versions of Tethys Platform please refer to the documentation specific to your version.
If using an Azure AD Tenant and you selected either Accounts in any organizational directory or Accounts in any organizational directory and personal Microsoft accounts:
On the Overview page of the App Registration you created in the previous step, note the Application (client) ID and Directory (tenant) ID for use in step 7.
Select Certificates & secrets from the menu on the left. Create a Client Secret and note it's value for use in step 7.
Enable the appropriate authentication backend:
If using an Azure AD Tenant and you selected either Accounts in any organizational directory or Accounts in any organizational directory and personal Microsoft accounts:
If using an Azure AD Tenant and you selected either Accounts in any organizational directory or Accounts in any organizational directory and personal Microsoft accounts:
Use b2c_ as the value of SOCIAL_AUTH_AZUREAD_B2C_OAUTH2_POLICY if you do not have a custom user flow. See: User flows in Azure Active Directory B2C for more information.
References
For more detailed information about using Azure Active Directory social authentication see the following articles:
Coordinate with the administrator of your organization's Windows server that is running AD FS to create a new App Registration for your Tethys Portal (see Step 2).
Important
Tethys Platform only supports authenticating with AD FS 2016 or later.
Note the Secret that is generated for use in Step 3.
On the Configure Web API* tab:
Add the FQDN of your Tethys Portal as an Identifier.
On the Configure Application Permissions tab:
Only the openid scope is required. However, you may consider permitting the email and profile scopes as well to allow Tethys Portal to populate its user profile.
Important
You do not need to complete the Code Configuration section.
Add the appropriate settings to the portal_config.yml file using the tethyssettings command:
Add the tethys_services.backends.adfs.ADFSOpenIdConnect backend to the AUTHENTICATION_BACKENDS setting:
Use the ClientIdentifier and Secret obtained in Step 2 to set the SOCIAL_AUTH_ADFS_OIDC_KEY and SOCIAL_AUTH_ADFS_OIDC_SECRET settings, respectively. Also, set the SOCIAL_AUTH_ADFS_OIDC_DOMAIN setting with the Fully Qualified Domain Name (FQDN) of your AD FS server (e.g. "https://adfs.my-org.com"):
You will need a Facebook developer account to register your Tethys Portal with Facebook. To create an account, visit https://developers.facebook.com and sign in with a Facebook account.
Create a Facebook App
Point to MyApps and select CreateApp.
Fill out the form and press CreateAppID button.
Setup OAuth
Scroll down and locate the tile titled Facebook Login.
Press the Setup button on the tile (or Settings if setup previously).
Specify the following for the Valid OAuth Redirect URIs field:
Follow these instructions to register your project and create a client ID: Setting Up OAuth 2.0. Provide the following as you setup OAuth2:
Provide Authorized JavaScript Origins
As a security precaution, Google will only accept authentication requests from the hosts listed in the AuthorizedJavaScriptOrigins box. Add the domain of your Tethys Portal to the list. Optionally, you may add a localhost domain to the list to be used during testing:
https://<SERVER_DOMAIN_NAME>http://localhost:8000
Note
Replace <SERVER_DOMAIN_NAME> with the value determined during the Preparation step.
Provide Authorized Redirect URIs
You also need to provide the callback URI for Google to call once it has authenticated the user. This follows the pattern http://<host>/oauth2/complete/google-oauth2/:
This feature requires the hs_restclient library to be installed. Starting with Tethys 5.0 or if you are using micro-tethys-platform, you will need to install hs_restclient using conda or pip as follows:
Name: Give this OAuth app a name. It is recommended to use the domain of your Tethys Portal instance as the name, like: www.my-tethys-portal.com
Client id: Leave unchanged. Note this value for step 3.
Client secret: Leave unchanged. Note this value for step 3.
Client type: Select "Confidential".
Authorization grant type: Select "Authorization code".
Redirect uris: Add the call back URLs. The protocol (http or https) that matches your Tethys Portal settings should be included in this url. For example:
if your Tethys Portal was located at the domain ``https://www.my-tethys-portal.com``:
https://www.my-tethys-portal.com/oauth2/complete/hydroshare/
if your Tethys Portal was on a local development machine:
http://localhost:8000/oauth2/complete/hydroshare/
or
http://127.0.0.1:8000/oauth2/complete/hydroshare/
Press the "Save" button.
Add the appropriate settings to the portal_config.yml file using the tethyssettings command:
Add the tethys_services.backends.hydroshare.HydroShareOAuth2 backend to the AUTHENTICATION_BACKENDS setting:
Once user has logged in Tethys through HydroShare OAuth, your app is ready to retrieve data from HydroShare on behalf of this HydroShare user using HydroShare REST API Client (hs_restclient).
A helper function is provided to make this integration smoother.
# import helper functionfromtethys_services.backends.hs_restclient_helperimportget_oauth_hs# your controller functiondefhome(request)# put codes in a 'try..except...' statementtry:# pass in request objecths=get_oauth_hs(request)# your logic goes here. For example: list all HydroShare resourcesforresourceinhs.getResourceList():print(resource)exceptExceptionase:# handle exceptionspass
(Optional) Link to a testing HydroShare instance
The production HydroShare is located at https://www.hydroshare.org/. In some cases you may want to link your Tethys Portal to a testing HydroShare instance, like hydroshare-beta.
Tethys already provides OAuth backends for hydroshare-beta and hydroshare-playground.
To activate them, you need to go through steps 1-3 for each backend (replace www.hydroshare.org with the testing domain urls accordingly).
At step 3:
Append the following classes in AUTHENTICATION_BACKENDS settings:
There are a few differences when enabling social login against ArcGIS Online vs ArcGIS Enterprise Portal. Pay close attention to the steps below for these differences.
Log in to your existing ArcGIS Online or ArcGIS Enterprise Portal account
Create an Application Item
Browse to your "Content"
Select "Add Item" and choose "An Application" from the dropdown
In the popup, choose "Application" as the "Type"
For the "Title", type "Tethys Platform" or anything else you choose
Type one or more tags of your choice, such as "Tethys"
Click "Add Item"
Update the Application Registration metadata
On the newly-created "Item" page, select the "Settings" tab
Scroll to the "Application" section at the very bottom of the page
Click the "Update" button under the "App Registration" subsection
For "Redirect URI", type "https://<SERVER_DOMAIN_NAME>", replacing <SERVER_DOMAIN_NAME> with the value determined during the Preparation step.
Click "Add"
Click "Update"
Take note of the AppID and AppSecret (click "Show Secret" to view the latter) for Step 5.
Add the appropriate settings to the portal_config.yml file using the tethyssettings command:
If you are configuring your Tethys Portal to authenticate users against ArcGIS Online:
Add the social_core.backends.arcgis.ArcGISOAuth2 backend to the AUTHENTICATION_BACKENDS setting:
You will need a LinkedIn developer account to register your Tethys Portal with LinkedIn. To create an account, visit https://developer.linkedin.com/my-apps and sign in with a LinkedIn account.
Tethys Platform supports two methods of Okta single sign on: OAuth 2.0 and OpenID Connect. Both methods should work and accomplish the same result. At the time of writing there were bugs in the extra dependency required by the OpenID Connect method that prevented it from working properly. Until the bugs are addressed, we recommend using the OAuth 2.0 method.
If you would like to use the OpenID Connect method, you will need to install an additional dependency (skip if using OAuth2 method):
condainstall-cconda-forgepython-jose
Warning
At the time of writing, the jose package contained syntax errors that made the OpenID Connect method unusable.
Create an Okta Developer Account
You will need an Okta developer account to register your Tethys Portal with Okta. To create an account, visit https://developer.okta.com/signup/.
Create an Okta Application
Follow the steps outlined in this document to create an Okta application: Create an Okta application. Set the callback URL as follows:
Select the General tab of the application and note the ClientID and ClientSecret for Step 5.
Navigate back to the Dashboard page of the developer console and note the Org URL, located near the top right side of the page. The Org URL is needed for step 5.
Add the appropriate settings to the portal_config.yml file using the tethyssettings command:
Currently the OneLogin backend requires an older version (4.0.2) of the social-auth-core library than is currently installed by default with Tethys. To use the OneLogin backend you will need to ensure that your environment has social-auth-core==4.0.2.
You can install the compatible version of social-auth-core into an existing environment with the following command:
A multi-tenant SSO provider is one that provides separate instances of it's SSO services for each organization or tenant that uses it. Each instance of the service is accessed via a different URL (e.g.: my-organization.onelogin.com, login.microsoftonline.com/<tenant-id>/, adfs.my-organization.com). Tethys Portal provides custom backends for some of the multi-tenant SSO providers that are able to handle multiple sets of credentials, one for each tenant. The providers supported include Okta, OneLogin, AzureAD, and AD FS.
Authentication Flow
The multi-tenant SSO authentication flow introduces an additional step in the authentication process that prompts the user for an identifier called a Tenant Key. Usually the Tenant Key is just the name of their organization or some variant of it. To illustrate the multi-tenant SSO authentication flow, consider the following example:
Jyn Erso would like to log in to a Tethys Portal that has been configured to use her company's SSO provider, OneLogin. To login, Jyn completes the following steps:
Jyn is then returned to the Tethys Portal, now logged in.
Note
The default title for the page that requests the Tenant Key (see screenshot for step 3) is "Tenant", but it can be customized via the SSO_TENANT_ALIAS setting:
SSO_TENANT_ALIAS:'Company'
Configuration
Configuring multi-tenant SSO backends is similar to configuring other SSO backends. The primary difference is that you will need to provide the required settings (i.e. KEY, SECRET, etc.) for multiple tenants instead of globally for the backend. All of these tenant settings are organized under a MULTI_TENANT setting for the backend, and settings for each tenant are grouped under a Tenant Key. For example:
A Tenant Key is a string that is used to identify a set of settings for a tenant under one of the MULTI_TENANT settings. Tenant Keys may only contain the following characters:
any lowercase letter
any number
spaces
hyphens (-)
underscores (_)
Care should be taken when selecting Tenant Keys, as users will be required to enter it whenever they login to your Tethys Portal using that tenant. The values provided by users are normalized to all lower case characters before attempting the lookup in the MULTI_AUTH settings. In other words, "Rebel Acquisitions", "rebel acquisitions" and "REBEL ACQUISITIONS" are all normalized to the Tenant Key "rebel acquisitions".
Please use the following guidelines when choosing a Tenant Key:
Choose something easy to remember and intuitive for the user.
Use the name of the organization or a short variant of it if possible.
Tenant keys may include spaces to allow for more intuitive values for users.
Users may use title case or any other case when entering the Tenant Key, but the Tenant Key must always be specified using lowercase letters in the portal_config.yml.
The following values are examples of invalid Tenant Keys for the portal_config.yml:
"Rebel Acquisitions" -> no uppercase characters allowed.
"palpatine & vaders" -> the "&" character is not allowed.
"watto's_repair" -> no apostrophes allowed.
The following values are examples of valid Tenant Keys for the portal_config.yml:
"rebel acquisitions"
"palpatine and vaders"
"wattos_repair"
"maz-kanatas"
The following is an example of a MULTI_TENANT setting with valid Tenant Keys:
The following regular expression is used to validate Tenant Keys: '^[\w\s_-]+$'. You may override this value with your own using the SSO_TENANT_REGEX setting:
Follow the normal steps for registering the Tethys Portal with the organization's AzureAD tenant and obtain the Application (client) ID, Client Secret, and Directory (tenant) ID (see: Azure Active Directory Steps 3-5).
Enable the appropriate multi-tenant backend for Azure AD:
If using an Azure AD Tenant and you selected Accounts in this organizational directory only:
Do not enable both the AzureADTenantOAuth2MultiTenant and AzureADTenantOAuth2 backends at the same time. The AzureADTenantOAuth2MultiTenant will fall back to behaving like the AzureADTenantOAuth2 if the MULTI_TENANT setting is not present, so it is not necessary to use both.
Do not enable both the AzureADB2COAuth2MultiTenant and AzureADB2COAuth2 backends at the same time. The AzureADB2COAuth2MultiTenant will fall back to behaving like the AzureADB2COAuth2 if the MULTI_TENANT setting is not present, so it is not necessary to use both.
Add the appropriate MULTI_TENANT setting with the settings for one or more tenants grouped under the desired Tenant Key:
If using an Azure AD Tenant and you selected Accounts in this organizational directory only:
Follow the normal steps for registering the Tethys Portal on with the AD FS server and obtain the Client Identifier, Secret, and Server Domain Name (see: Active Directory Federation Services (AD FS) Steps 1-2).
Do not enable both the ADFSOpenIdConnectMultiTenant and ADFSOpenIdConnect backends at the same time. The ADFSOpenIdConnectMultiTenant will fall back to behaving like the ADFSOpenIdConnect if the MULTI_TENANT setting is not present, so it is not necessary to use both.
Add the MULTI_TENANT setting with the settings for one or more AD FS servers grouped under the desired Tenant Key:
Follow the normal steps for registering the Tethys Portal with the organization's Okta instance and obtain the Client ID, Client Secret, and Org URL (see: Okta Steps 2-4).
Enable the appropriate multi-tenant backend for Azure AD:
Do not enable both the OktaOauth2MultiTenant and OktaOAuth2 backends at the same time. The OktaOauth2MultiTenant will fall back to behaving like the OktaOAuth2 if the MULTI_TENANT setting is not present, so it is not necessary to use both.
Do not enable both the OktaOpenIdConnectMultiTenant and OktaOpenIdConnect backends at the same time. The OktaOpenIdConnectMultiTenant will fall back to behaving like the OktaOpenIdConnect if the MULTI_TENANT setting is not present, so it is not necessary to use both.
Add the appropriate MULTI_TENANT setting with the settings for one or more tenants grouped under the desired Tenant Key:
Follow the normal steps for registering the Tethys Portal on with the OneLogin server and obtain the Client ID, Client Secret, and Subdomain (see: OneLogin Steps 2-4).
Do not enable both the OneLoginOIDCMultiTenant and OneLoginOIDC backends at the same time. The OneLoginOIDCMultiTenant will fall back to behaving like the OneLoginOIDC if the MULTI_TENANT setting is not present, so it is not necessary to use both.
Add the MULTI_TENANT setting with the settings for one or more OneLogin servers grouped under the desired Tenant Key:
Beginning with Tethys Platform 3.0.0 the social auth settings are configured in the portal_config.yml file. The following is a summary of all the settings that would need to be added for the various supported social auth backends.
Caution
Social authentication requires Tethys Platform 1.2.0 or later. For instructions on how to configure social auth for previous versions of Tethys Platform please refer to the documentation specific to your version.
The following settings in the portal_config.yml are used to configure social authentication:
Social Auth Settings
Beginning with Tethys Platform 3.0.0 the social auth settings are configured in the
portal_config.yml
file. The following is a summary of all the settings that would need to be added for the various supported social auth backends.The following settings in the
portal_config.yml
are used to configure social authentication:You can use the
tethys settings
command to easily set the settings in theportal_config.yml
. For example:Important
Remember to restart the Tethys servers to effect any changes to the
portal_config.yml
: