Identity source management

About identity sources

Identity sources integrate existing account systems, allowing users from these systems to access applications built with Moflow.

Each identity source is configured with a default permission group. When a user logs on through an identity source, the user is automatically mapped to that default permission group.

Identity source interface

Identity source list

On the Identity Sources page, you can view all identity sources in the current space and their details, including the following:

• Identity source name

• Type

• Status

• Default permission group

• Callback address

• Description

This information helps you understand the identity sources in the current space. After you create an identity source, a callback address is automatically generated. This address is permanent and cannot be modified. You can use this callback address to configure the callback address of your OpenID Connect (OIDC) server.

Identity source operations

Moflow supports enabling, disabling, editing, and deleting custom OIDC and JSON Web Token (JWT) identity sources. On the Identity Sources page, you can select the desired operation for an identity source from the list.

• The Enable and Disable operations adjust the status of the identity source to control its usage.

• The Edit operation modifies the configuration of the identity source.

• The Delete operation removes the selected identity source.

Configure a platform logon method for a Moflow application

After you configure the identity source, go to the Moflow application editor. In the lower-left corner, click Application Settings. In the Logon Configuration -> Platform Logon Configuration section, you can select an identity source as the default logon method for a specific platform or environment:

Default identity sources

The Moflow platform has two built-in identity sources: Alibaba Cloud Account Logon, which is associated with the END_USER default permission group, and Test Account Logon, which is associated with the TEST_USER default permission group. You cannot create, edit, disable, or delete default identity sources.

• Alibaba Cloud Account Logon: Log on using an Alibaba Cloud Resource Access Management (RAM) account. For more information, see What is RAM?.

• Test Account Logon: On the logon page, you can select Test Account and log on with a test username and password.

OIDC/JWT identity sources

Introduction to OIDC identity sources

The Moflow platform supports adding one OIDC identity source. After you add an OIDC identity source, a logon option for that source is added to the logon page of applications built with Moflow. For more information, see How Connect Works.

Introduction to JWT identity sources

The Moflow platform provides a JWT identity source authentication method based on Alibaba Cloud OpenAPI. You can call the Moflow OpenAPI to complete user logon and issue the corresponding token. A JWT identity source is suitable for integration scenarios where a host application already has a logon state and you want to sync this state to a Moflow application by calling an API.

For information about how to integrate a native host application using the Moflow SDK, see Android SDK integration and iOS SDK integration. For a web host application, you can inject a JWT token into the iFrame using the URL parameter named auth_code. Web host integration also supports automatic JWT token keepalive. You can inject a token refresh credential and refresh epoch using the URL parameters named refresh_token and expires_in. You can obtain the content for auth_code, refresh_token, and expires_in by calling the GenerateJWTUserToken API.

JWT identity authentication flow

You can complete JWT identity source authentication by calling the Moflow GenerateJWTUserToken API. The authentication flow is as follows.

During authentication, Moflow verifies the space permission based on the Alibaba Cloud ID used to call the OpenAPI. After the verification passes, Moflow verifies the JWT identity source. To complete JWT identity source authentication, you must correctly configure and enable the JWT identity source information on the Moflow platform.

Maintain token validity

Moflow provides two OpenAPI operations: GenerateJWTUserToken and RefreshJWTUserToken. These operations generate and refresh tokens for accessing Moflow services. During integration, you must periodically call the refresh token API to prevent the token from expiring.

Configuration method

On the Identity Sources page, you can add one OIDC identity source and one JWT identity source. After adding them, you can enable, disable, edit, or delete them. The procedure for adding and configuring a new identity source is as follows:

1. Basic Configuration: After you click Add Identity Source, a dialog box appears. In the Basic Configuration step, you can configure the alias, display name, type, and description, and select the enabling status.

2. OIDC Configuration: If you select OIDC Identity Source as the type, click Next to proceed to the OIDC Configuration step. Fill in the parameters according to the OIDC protocol. If you select JWT Identity Source, you can skip this step.

3. Permission Mapping: If you select OIDC Identity Source, you can configure attribute mapping and permission groups in this step. You can also add permission mapping rules in the permission group configuration. If you select JWT Identity Source, you can only configure the default permission group.

DingTalk identity source

On the Identity Sources page, you can add a DingTalk identity source.

First, follow the instructions in the DingTalk third-party logon document to go to the DingTalk developer platform to create and configure an application. Complete "Step 1: Create and configure an application" and "Step 2: Add API permissions".

To enable the DingTalk logon-free feature, you must enable the qyapi_get_member permission:

You must enable the Contact.User.Read permission:

Then, in Security Settings, enter https://accounts.mobiapp.cloud/ in the Redirect URL (Callback Domain Name) input box:

In the Server Egress IP section, you must enter the egress IP address that you use to access this application. Otherwise, the IP address will be blocked.

Then, in the Credentials and Basic Information menu item, you can obtain the Client ID, Client Secret, Agent ID, and Corp ID values.

After you obtain these four values, return to the Moflow platform and click Add Identity Source:

In the Type section, on the DingTalk tab, enter the required information and proceed to the next step:

Enter the credential values obtained from the DingTalk developer platform in the input boxes and click Next:

After you select a permission group, click Confirm to add the DingTalk identity source.

To enable DingTalk logon-free, return to the application editor. In the application settings, you can enable the logon-free button for the DingTalk identity source:

To access the Moflow application from the Enterprise Workbench in the DingTalk client, you can enter the application home page in the Application Home Page Address field:

WeCom identity source

On the Identity Sources page, you can add a WeCom identity source.

First, go to the WeCom developer platform:

In the top menu bar, click Application Management. Then, in the Self-built section, select Create Application. Fill out the form and go to the application details page.

On the My Company tab, you can obtain the Client ID:

Return to the application page. In the application details, you can obtain the Client Secret and Agent ID:

Then, you can grant authorization in the Developer API section below.

First, click WeCom Authorization Logon:

In the Authorized Callback Domain field, enter the domain name accounts.mobiapp.cloud.

Then, return and click Web Authorization and SDK:

Enter the custom domain name in the Trusted Domain Name field. Then, click Download File as shown in the figure above. Save the file name and content, and then return to the Moflow platform:

In the Add Identity Source form, select the WeCom tab, fill in the required information, and click Next:

In this form, enter the information obtained from the WeCom developer platform and click Next:

After you configure the permission group information, you can add the WeCom identity source.

Then, return to the WeCom console. In the Set Trusted Domain Name section, click OK. A message indicating that the domain name is verified appears. The configuration is successful.

Then, in the Enterprise Trusted IP section, you must configure the Moflow authentication request server IP address 101.200.211.106. Otherwise, the logon process cannot be completed.

SAML 2.0 identity source

On the identity source list page, you can click the Add Identity Source button to open the identity source configuration page and create a SAML 2.0 identity source.

Basic configuration

In the basic configuration panel, you can configure the alias (a unique identifier within the space), display name (the name shown on the logon page), description, and enabling status of the SAML 2.0 identity source.

Advanced configuration

In the advanced configuration panel, you can import metadata provided by the SAML identity provider (IDP) into Moflow. From the metadata, you can extract the IDP's Entity ID (a unique IDP identifier), Signing Certificate, Single Sign On Service Url, and Single Logout Service Url.

In addition to this basic information, you can specify other settings in the SAML 2.0 protocol:

• Post Binding Authn Request/Post Binding Response/Post Binding Logout

In the SAML 2.0 protocol, communication between the service provider (SP) and the IDP is divided into HTTP Redirect Binding, HTTP POST Binding, and HTTP Artifact Binding. HTTP Artifact Binding is not commonly used and is not currently supported. Each method uses a different type of HTTP request to communicate with the other party at different stages. If you select the Post Binding option, Moflow uses the HTTP POST Binding method to communicate with the IDP. Otherwise, it uses the HTTP Redirect Binding method.

• Allow Create

If this option is set to true, the SP allows the IDP to generate a new Name ID for the user. This means the IDP can create a new unique identifier for the user, even if the user already has an identifier in the IDP. Note that to use this parameter, Name ID Format must be set to PERSISTENT.

• Force Authn

In the SAML 2.0 protocol, ForceAuthn is used to indicate whether the IDP needs to force the user to re-authenticate, even if the user already has a valid session on the IDP. This property is disabled by default in Moflow.

• Validate Signature

This option controls whether to validate the digital signature of the SAML assertion from the IDP. If this option is set to true, Moflow validates the digital signature of the SAML assertion sent from the IDP. If the signature validation fails, Moflow rejects the assertion.

• Name ID Policy Format

NameID Policy Format specifies the format of the NameID in a SAML assertion. The SAML 2.0 specification defines several standard NameID formats for different scenarios. Keycloak supports the following common NameID formats:

TRANSIENT

Generates a temporary, non-repeatable identifier. This format is suitable for scenarios that do not require a persistent identifier, such as a single session or anonymous access.

PERSISTENT

Generates a persistent, reusable identifier. This format is suitable for scenarios that require a persistent identifier, such as uniquely identifying a user across multiple sessions.

EMAIL_ADDRESS

Uses the user's email address as the NameID. This format is suitable for scenarios that require using an email address as the identifier.

UNSPECIFIED

Does not specify a NameID format. The IDP determines the format. This format is suitable for scenarios that have no specific requirements for the NameID format.

• Principal Type

Principal Type defines how to determine the user's identity. Moflow provides several different Principal Type options:

SUBJECT

Uses the user's username as the NameID.

ATTRIBUTE

The NameID is the value of the user property whose name is specified by Principal Type.

FRIENDLY_ATTRIBUTE

The value of a user attribute is used as the NameID. The Principal Type specifies the friendly name of the attribute.

• Principal Attribute

This specifies the name of the user attribute or friendly attribute whose value is used as the NameID.

Permission mapping

Basic attribute mapping

In the basic attribute mapping configuration, you can map user attributes from the SAML assertion to Moflow user attributes. Moflow supports mapping by Attribute Name and Friendly Name. The configuration for Attribute Name takes precedence.

The `Name Format` has three forms:

ATTRIBUTE_FORMAT_BASIC

This is the simplest attribute name format. It directly uses the attribute's name as a string. For example, if you have an attribute named email, its name format is email.

ATTRIBUTE_FORMAT_URI

Uses a Uniform Resource Identifier (URI) to represent the attribute name. This format is typically used for attributes that require a specific namespace or URI. For example, if you have an attribute named email, its format might be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email.

ATTRIBUTE_FORMAT_UNSPECIFIED

Does not specify a particular attribute name format. The sender determines the format. Select this type if you are unsure or do not need a specific format.

Permission group mapping

The SAML 2.0 identity source supports setting a default permission group. You can also map attributes from the SAML assertion to permission groups in Moflow.

OAuth 2.0 identity source

You can connect your OAuth 2.0 identity source through the Moflow identity source system. First, add an identity source and select OAuth 2.0 for the Type:

Then, you can fill in the OAuth 2.0 configuration information:

The fields are described as follows:

• Client Id is the client ID assigned to the Moflow identity source by your OAuth 2.0 system.

• Client Secret is the client secret assigned to the Moflow identity source by your OAuth 2.0 system.

• Authorization Url is the authorization URL path of your OAuth 2.0 system.

• Token Url is the token URL path of your OAuth 2.0 system.

• Response Type is the response_type parameter in the authorization URL request that Moflow sends to your OAuth 2.0 system. The default value is code.

• Scope is the scope parameter in the authorization URL request that Moflow sends to your OAuth 2.0 system. This is optional and empty by default.

• Grant Type is the grant_type parameter in the token URL request that Moflow sends to your OAuth 2.0 system. The default value is authorization_code.

• User Info Url is the user information URL path of your OAuth 2.0 system.

• User Info Method is the method Moflow uses to request the user information URL path of your OAuth 2.0 system. The options are GET and POST.

• Username Json Path is the JSONPath statement used to locate the username information in the return value of your OAuth 2.0 system's user information URL.

• User Id Json Path is the JSONPath statement used to locate the user ID information in the return value of your OAuth 2.0 system's user information URL.

• User Email Json Path is the JSONPath statement used to locate the user email address information in the return value of your OAuth 2.0 system's user information URL. This is optional.

After you finish, click Next. You can then specify a default permission group for users of this identity source:

Finally, click Confirm to add the OAuth 2.0 identity source.

WeChat identity source

On the Identity Sources page, you can add a WeChat identity source. A WeChat identity source allows end users to use their WeChat accounts to log on to Moflow runtime applications. Moflow supports logon services for two scenarios: WeChat Official Accounts Platform and WeChat Open Platform.

  /**
   * Lifecycle function--Called when the page is first rendered.
   */
  onReady() {
    // Get the WeChat Mini Program authCode
    wx.login({
      success: (res) => {
        // Get the WeChat Mini Program user information
        wx.getUserInfo({
          success: (info) => {
            // Customize the Moflow application for the production environment / development environment
            const baseUrl = 'https://{{your_production_environment_domain_name}}/xxxxxxxxx/apps/xxxxxxxxxx/';

            this.setData({
              // Control the display of webViewSrc and webView
              webViewSrc: `${baseUrl}?iv=${encodeURIComponent(info.iv)}&encryptedData=${encodeURIComponent(info.encryptedData)}&auth_code=${res.code}`,
              showWebView: true,
            })
          }
        })
      },
      fail: (err) => {
        console.log(err)
      }
    })
  }