Login
- Released At: 15-05-2026
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
Configuration Examples
Document version: 5W110-20260310
Product Version: EIA (E7303)
Copyright ©2026 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
The information in this document is subject to change without notice.
Contents
Example: Configuring EIA standard OAuth 2.0
Customizing portal authentication pages
Configuring standard OAuth 2.0
Introduction
Standard OAuth 2.0 is an authorization framework that allows third-party applications to safely access resources stored by users on service providers, with user authorization, without directly exposing user credentials (such as usernames and passwords). In EIA, OAuth 2.0 is used for unified identity authentication and authorization management, effectively enabling secure and flexible identity authentication and authorization management.
This document uses Keycloak, a third-party application, as an example. During user authentication, authorization is granted through the Keycloak third-party application. Once authorized, Keycloak users can safely access internal resources of EIA, while simplifying the user identity management process and significantly enhancing system security and scalability.
Usage guidelines
Application scenarios
Suitable for third-party application authorization scenarios, allowing external or third-party applications to securely access internal resources and ensuring controlled and secure data access permissions.
· Banking systems: Users authorize third-party financial management apps to access their systems through the bank's authorization system.
· Student online education platforms: Students authorize third-party online education platforms to access school systems.
· Corporate employee attendance systems: Employees authorize third-party tools to access the company's internal attendance system.
Prerequisites
Before the configuration, make sure the network is reachable.
Example: Configuring EIA standard OAuth 2.0
Network configuration
A company plans to enable portal authentication on the EIA server and use Keycloak as a third-party authentication server to verify user identity through the OAuth 2.0 protocol. When users access the network via portal authentication, they first complete authorization through Keycloak.
Figure 1 Network diagram
Version info:
· EIA version: EIA (E7303)
· Keycloak server: Keycloak 26.1.2
Procedures
This example uses portal authentication.
Configuring Keycloak
1. In the browser, enter the address of the Keycloak system to access the login page.
Figure 2 Login page
2. Enter the login username and password.
Figure 3 Logging in to the system
Adding an application
1. Select Clients > Clients list to access the Clients list page.
Figure 4 Clients list page
2. Click Create client to access the General settings page. Enter a client ID. In this example, test is entered.
Figure 5 General settings
3. Click Next to access the Capability config page. Enable the Client authentication and Authorization options.
Figure 6 Capability config
4. Click Next to access the Login settings page. Configure valid redirect URLs. In this example, http://10.144.195.167:9092/portal/oauth2/loginCallback is entered. The http://10.144.195.167:9092/portal portion is the address of the portal page configured in "Configuring a server."
|
|
NOTE: If you use MAC portal authentication, enter http://ip_address:30004/byod/oauth2/loginCallback. The IP address is the northbound service VIP of the cluster where Unified Platform resides. |
Figure 7 Login settings
5. Click Save to save the configuration.
Figure 8 General settings
6. Click the Credentials
tab to access the Credentials page. Click the 
icon
next to the Client Secret field to copy the
password.
Figure 9 Credentials
Adding a user
1. Select Users > User list to access the User list page.
Figure 10 User list
2. Click Add user to access the Create user page. Enter a username. In this example, test is entered.
Figure 11 Create user
3. Click Create to access the User details page.
Figure 12 Details
4. Click the Credentials tab to access the Credentials page.
Figure 13 Credentials
5. Click Set password to access the Set Password for test page. Enter a password and enable the Temporary field as needed. In this example, the option is disabled.
Figure 14 Set Password for test
6. Click Save, and click Save Password in the window that opens.
Adding an access device
Figure 15 Access device page
2. Click Add. The Add Access Device page opens.
Figure 16 Add an access device
3. Configure common parameters.
¡ Authentication Port: Port number for EIA to listen for RADIUS authentication packets. The port number is fixed at 1812. Make sure the authentication port configured on the access device is also 1812.
¡ Accounting Port: Port number for EIA to listen for RADIUS accounting packets. The port number is fixed at 1813. Make sure the authentication port configured on the access device is also 1813.
|
|
NOTE: You must use the EIA server to provide both authentication and accounting services. You cannot use the EIA server as the authentication server and another server as the accounting server. |
¡ Service Type: Select the service carried by the device from the list, including Unlimited and Device Management Service. The Unlimited option is selected for users to access and use the network and the Device Management Service option for administrators to log in and manage devices.
¡ Forcible Logout Type: Specify a method that forces users to log out. Options include Disconnect user and Shut down and bring up port. The former indicates that the EIA server sends a Disconnect Message (DM) to the NAS device to force the user to go offline. The latter indicates that the EIA server sends a Change of Authorization (CoA) message to the NAS device to force the user to go offline. After receiving a CoA message, the NAS device first brings down the port connected to the user and then brings it back up again.
¡ Access Device Type: Select the vendor and type of the access device from the list. Options include the standard, EIA-predefined, and administrator-defined vendors and types. If an access device supports the standard RADIUS protocol, you can select Standard.
¡ Shared Key/Confirm Shared Key: Specify a shared key and confirm it. When the access device works with EIA for authentication, they use this key to verify each other's legitimacy. The shared key specified on the EIA server must be the same as that specified on the access device. You need to enter the shared key only once if you selected Plaintext for the Display Keys in field on the Automation > Network Access > Access Management > Parameter Management > UAM > System Parameters page.
¡ Access Location Group: Select an access location group for the access device. Options include the existing access location groups in EIA and None. The access location group is one of the user access conditions.
In this example, the shared key is set to movie, the default settings are used for all the other parameters.
4. Click Add IPv4 Device to add the device at 10.142.2.180.
5. Click OK.
Figure 18 Access device added
Adding an access policy
Figure 19 Adding an access policy
Configure the following parameters:
¡ Access Period: Select an access period policy from the list. A user using the access policy can access the network only in the time ranges defined in the access period policy.
¡ Allocate IP: Specify whether to assign IP addresses to users.
¡ Upstream Rate (Kbps)/Downstream Rate (Kbps): Specify the maximum upstream rate and downstream rate for users that match the access policy.
¡ Priority: Specify the traffic priority during network congestion. A smaller value indicates a higher priority. Select a priority value from the priority values supported by the device. An invalid value might result in failures of users to access the network.
¡ Authentication Type/Subtype: Select an authentication type that the RADIUS server issues to the device when performing EAP authentication. If you select the EAP-TTLS or EAP-PEAP authentication type, you must select an authentication subtype.
- EAP-MD5: An EAP authentication method that uses CHAP for authentication.
- EAP-TLS: A certificate-based identity authentication method that uses PKI to manage certificates. It recommends mutual authentication between the server and client, where both parties use certificates to identify their identities. After successful authentication, the TLS-authenticated parties negotiate a shared key, a session ID, and a complete cipher suite (encryption, compaction, and data integrity verification), thereby establishing a secure and reliable data transmission channel. EAP-TLS is an identity authentication process conducted via the TLS protocol between the client and the AAA server, with the access device acting as a transparent pass-through. EAP-TLS can use the session ID for fast re-authentication, simplifying the authentication process and speeding up authentication. It also fragments larger TLS packets.
- EAP-TTLS: A certificate-based identity authentication method that uses TLS authentication to establish a secure channel between the client and the AAA server, within which subtypes are encapsulated. The authentication method protects the user identity and the EAP authentication negotiation process. The subtypes within the tunnel can be either EAP types or non-EAP types. EIA supports the EAP-MSCHAPv2, EAP-MD5, and EAP-GTC authentication subtypes. If an endpoint uses a non-EAP subtype, such as PAP, it can ignore EIA's configuration and uses the on-EAP subtype for authentication.
- EAP-PEAP: Certificate-based identity authentication, which initiates EAP authentication within the security channel set up by TLS authentication between the client and EIA. The authentication method protects the user identity and the EAP authentication negotiation process. EIA only supports EAP-MSCHAPv2, EAP-MD5, and EAP-GTC.
¡ EAP Auto Negotiate: Specify whether to enable automatic negotiation of EAP authentication type when the EAP authentication type specified on the client and that on EIA are different. With this feature enabled, EIA permits the client's authentication request without considering the EAP type configured on the client. With this feature disabled, EIA rejects the client's authentication request if the EAP authentication types specified on the client and EIA are different.
¡ Maximum Online Duration for a Logon (Minutes): Specify the maximum duration an authenticated user that uses the access policy can be online, in minutes. The value range is 1 to 1440. If you leave this field empty, the online duration is not limited. If the online duration of an access user exceeds the specified value, EIA logs off the user.
¡ Deploy Address Pool: Enter an address pool name. EIA will deploy the address pool name to the access device. The access device will use this address pool to assign IP addresses to users. For successful address assignment, make sure an address pool with the same name exists on the access device.
¡ Deploy VLAN: Enter a VLAN. If the type of the access device is H3C (General), HUAWEI (General), HP (Comware), or 3COM (General), you can enter a VLAN ID or VLAN name. EIA takes any integer in the range of 1 to 4094 as an integer-type VLAN ID and deploys it to the access device. Any other character string is taken as a string-type VLAN name and deployed to the access device. If an access device is none of the previous types, EIA always deploys the entered value to the access device as a string-type VLAN name. The user can access only resources in that VLAN after passing authentication.
¡ Deploy User Profile: Specify the name of the user profile for deployment to the device to perform user-based QoS functions. This feature takes effect only when the user profile to be deployed has been configured on the device.
¡ Deploy User Group: Specify the name of the user group to which the users belong after they pass authentication. You can enter multiple user groups, separated by semi-colon (;). This feature takes effect only when EIA works with an ACG1000 or SSL VPN device.
¡ Deploy ACL: Specify the ACL to be deployed to users.
¡ Offline Check Period (Hours): Specify the offline check interval for mute endpoints, in hours. After a mute endpoint passes authentication, EIA deploys the configuration to the device and the device checks whether the mute endpoint is offline at the specified intervals. The value must be an integer in the range of 0 to 596523. If you leave this field empty or set the value to 0, offline check will not be performed. This parameter applies to only dumb endpoints.
¡ Authentication Binding Information: The access policy module can cooperates with the access device module to check the binding information for each user account to be authenticated, including the IP address, port, VLAN, QinQ, and SN of the access device, and the IP address, MAC address, IMSI, IMEI, wireless user SSID, and the hard disk serial number of the user. The client can cooperate with the policy server to check the following binding information for the user: user IP address, MAC address, computer name, computer domain, login domain, and the hard disk serial number. Among these items, user MAC address and IMSI are mutually exclusive and cannot be both bound. The binding requirements can be set for a service which contains a binding policy. If no requirements are set for such a service, auto-learning is adopted. Auto-learning is to bind the parameters used for the first login. For example, if a user uses 10.100.10.10 for the first login through the service, the user must always use the IP address to pass authentication.
- Control Access IP/MAC Address: With this feature enabled, EIA checks the IP address or MAC address of an access user using this service when the user attempts to come online. If the IP address or MAC address is on the allowed access address list, the user can come online. Otherwise, the access is denied. For more information about the access address configuration, see Access IP/MAC Address.
- Control Hard Disk Serial Number: With this feature enabled, EIA checks the hard disk serial number of a user endpoint when the user attempts to come online. If the serial number is permitted or EIA cannot obtain the hard disk serial number, the user is allowed to come online. Otherwise, the access is denied. This feature must work with the iNode PC client.
- Enable SSID Access Control: When you enable this feature and set the SSID filter to Permit, EIA maintains an SSID allowlist. Users can access the network when they connect to an SSID on the SSID access control list. When you enable this feature and set the SSID filter to Deny, EIA maintains an SSID denylist. Users cannot access the network when they connect to an SSID on the SSID access control list. This feature must work with the iNode PC client. The client receives the SSID access control configuration from EIA and saves it to the PC. The configuration also applies to the Windows built-in 802.1X application.
|
|
NOTE: To deploy authorization information, make sure the attributes are supported on the device. For the authentication binding information to take effect, you must configure the corresponding information in the RADIUS attributes on the device. This example does not deploy any configurations to the device. Therefore, the default settings are used. |
Figure 20 Adding an access policy
3. Click OK.
Figure 21 Access policy added
Adding an access service
1. Select Automation > Network Access > Access Management > Access Service > Access Service to access the Access Service page.
Figure 22 Adding an access service
2. Click Add.
Configure the following parameters:
¡ Service Name: Specify a service name. In this example, OAuth2.0 Service is used.
¡ Default Access Policy: Select the access policy configured in "Adding an access policy."
¡ Service Suffix: Enter a service suffix, which identifies the name of the domain to be used for user authentication. The service suffix, authentication username, authentication domain, and the device's RADIUS scheme command are closely related to each other. For more information about the matrix of these elements, see the following table.
¡ Security Group: Select a security group. In this example, the default is used.
¡ Sub Security Group: Select a security subgroup. In this example, the default is used.
¡ Default Proprietary Attribute Assignment Policy: When users not restricted by access location groups come online, EIA assigns private attributes to their connected access devices based on the policy specified in this parameter.
¡ Default Max. Devices for Single Account: Specify the number of endpoints to be bound to the same user account in access scenarios that are not included in the service.
- EIA checks the maximum number of bound endpoint devices for a single account in the following order:
-Matched access scenario: Checks the number of bound endpoint devices against the maximum number limit specified in the scenario. If the number reaches the limit, EIA denies the user authentication.
Scenarios in all services: Checks the number of bound endpoint devices in scenarios of all assigned services for the account. If the number reaches the value of Max. Device for Single Account specified in user endpoint settings on the Automation > Network Access > Access Management > Parameter Management > Endpoint > User Endpoint Settings page, EIA denies the user authentication.
¡ Default Max. Number of Online Endpoints: Specify the maximum number of online endpoints using the same user account in access scenarios that are not included in the service.
¡ Daily Max. Online Duration: Total duration in a day that an account can access the network by using the service. When the limit is reached, the account is forced offline and is unable to access the network in the day. The value can be an integer in the range of 0 to 1440 minutes. A value of 0 means no limit.
¡ Description: Specify a description of the service to simplify daily maintenance for operators.
Table 1 Service suffix selection in EIA
|
Authentication username |
Authentication domain |
Command in device's RADIUS scheme |
Service suffix on EIA |
|
X@Y |
Y |
user-name-format without-domain |
Y |
|
user-name-format without-domain |
No suffix |
||
|
X |
[Default Domain] Default domain on the device |
user-name-format without-domain |
[Default Domain] |
|
user-name-format without-domain |
No suffix |
Figure 23 Adding an access service
3. Click OK.
Figure 24 Adding an access service
Configuring the portal server
This section allows you to configure the EIA server as a portal server.
Configuring a server
Select Automation > Network Access > Access Management > Portal Authentication > Portal Server to access the Portal Server page. In this example, the default settings are used.
Figure 25 Configuring the server settings
Configuring an IP group
1. Select Automation > Network Access > Access Management > Portal Authentication > Portal IP Group to access the Portal IP Group page.
Figure 26 Configuring an IP group
2. Click Add.
Figure 27 Adding an IP address group
3. Enter IP address group name OAuth2.0_Address, and enter the start address and end address. Endpoints within this address range must undergo authentication.
4. Click OK. You can view the newly added IP address group in the IP address group list.
Figure 28 Viewing the newly added IP address group
Adding a device
1. Select Automation > Network Access > Access Management > Portal Authentication > Portal Device to access the Portal Device page.
2. Click Add.
Figure 30 Adding a portal device
Configure the following parameters:
¡ Device Name: Enter the device name. In this example, the device name is OAuth2.0_Switch.
¡ Public IP: Enter the public IP address of the portal access device.
¡ Key/Confirm Key: Enter the key twice. In this example, the key is movie. Make sure the key is consistent with the one configured for the portal server on the device.
¡ Access Method: Select Directly Connected.
¡ Use the default settings for the other parameters.
3. Click OK. You can view the newly added device in the portal device list.
Figure 31 Viewing the newly added device
4. Click the port group management icon 
in the
Operation column.
Figure 32 Port group management
5. Click Add.
Configure the following parameters:
¡ Port Group Name: Enter the port group name. In this example, the group name is OAuth_Port.
¡ Authentication Type: Select CHAP.
¡ IP Group: Select group OAuth_Address created at previous steps.
¡ Use the default settings for the other parameters.
6. Click OK. You can view the newly added port group in the port group list.
Figure 34 Viewing the newly added port group
Customizing portal authentication pages
1. Select Automation > Network Access > Access Management > Web Page Customization > Authentication Page Customization > PC Page access the PC Page page.
Figure 35 PC page
2. Click the 
icon in the Actions column for Default Account
and SMS Authentication (PC). On the Copy Template
page that opens, enter name OAuth2.0.
Figure 36 Copying a template
3. Click OK to
return to the PC Page page. Click the 
icon
in the Actions column for OAuth2.0
to access the portal customization page.
Figure 37 Portal page editing page
4. Hover over the authentication control, and
click the 
icon.
Figure 38 Editing the control
5. On the Content Settings page, deselect Account Password + SMS, and select Account Password and Standard OAuth 2.0.
Figure 39 Content settings
6. Click OK.
Figure 40 Control edited successfully
7. Click Save and Deploy.
Configuring standard OAuth 2.0
1. Select Automation > Network Access > Access Management > Access Service > APP AuthN Settings > Standard OAuth 2.0 to access the Standard OAuth 2.0 page.
Figure 41 Standard OAuth 2.0
2. Configure the following basic information:
¡ App ID: Also called a client ID. It is configured when an application is created on a third-party service. In this example, it is client ID test configured in "Adding an application."
¡ App Secret: Also called a client secret. It is automatically generated when an application is created on a third-party service. In this example, it is the client secret on the Credentials tab in "Adding an application."
¡ Callback URL: In this example, it is the valid redirect URL http://10.144.195.167:9092/portal/oauth2/loginCallback on the Login settings tab in "Adding an application."
¡ Default User Group: If the system cannot match a user group that meets the criteria, the default user group will be used as the user group for access users. In this example, Ungrouped is used.
¡ Default Online User Limit: Maximum number of online users allowed. If you set this parameter to 0, the number of online users for this account is not limited. In this example, it is set to 3.
¡ Default Access Service: If the system cannot match an access service that meets the criteria, the default access service will be used as the access service for access users. In this example, OAuth2.0 Access Service in "Adding an access service" is selected.
¡ Account Type: If you select Guest User, the guest will be associated with the guest administrator specified in the page push policy. If no guest administrator is specified in the page push policy, the default guest administrator applies. If you select Guest User, the guest policy does not take effect on the guest. In this example, Access User is selected.
Figure 42 Basic information
3. Configure a user group. In this example, the default user group is used.
¡ By Attribute: If an attribute field returned by the user information endpoint can act as a user group identifier, the system will bind users matching the corresponding attribute value to the corresponding user group. If no match is found, the default user group is used.
¡ Use Default User Group: Bind all users with accounts to the default user group.
Figure 43 User group
4. Configure an access service. In this example, the default access service is used.
¡ By Attribute: If an attribute field returned by the user information endpoint can act as an access service identifier, the system will bind users matching the corresponding attribute value to the corresponding access service. If no match is found, the default access service is used.
¡ By User Group: Bind users to the corresponding access services based on their user groups.
¡ Use Default Access Service: Bind all users with accounts to the default access service.
Figure 44 Access service
5. Configure the authorization endpoint to display an authorization page on the browser.
¡ URL: URL of the authorization endpoint. In this example, it is the URL of the authorization endpoint for the Keycloak service.
¡ Request Parameters: Specify request parameters that must be carried for access to the authorization endpoint according to the requirements of third-party services. In this example, request parameters for the Keycloak service are specified.
¡ Response Parameters: Support only the response body in JSON format returned by the third party service. In this example, response parameters for the Keycloak service are specified.
Figure 45 Authorization endpoint
a. Click Test to generate a URL.
b. Use a browser to access the URL. On the authorization page, enter the user information in "Adding a user."
Figure 46 Authorization page
c. Click Sign In. If the webpage shows SUCCESS, the endpoint test passes.
Figure 47 Test succeeded
6. Configure the access token endpoint to obtain access tokens.
¡ Enable Endpoint: Select whether to enable this endpoint. For the third-party OAuth 2.0 systems that do not use this endpoint, you can disable it.
¡ URL: URL of the access token endpoint. In this example, it is the URL of the access token endpoint for the Keycloak service.
¡ Request Method: Select a method to initiate HTTP requests. Only GET and POST are supported. POST is selected.
¡ Request Header Parameters: Specify request header parameters that must be carried for access to the access token endpoint according to the requirements of third-party services. In this example, no request header parameters need to be configured for the Keycloak service.
¡ Request Content Type: Select the type for sending request parameters when this endpoint is used. Only application/x-www-form-urlencoded and application/json are supported. In this example, application/x-www-form-urlencoded is selected.
¡ Request Parameters: Specify request parameters that must be carried for access to the access token endpoint according to the requirements of third-party services. In this example, request parameters for the Keycloak service are specified.
¡ Response Parameters: Support only the response body in JSON format returned by the third party service. In this example, response parameters for the Keycloak service are specified.
Figure 48 Access token endpoint
Click Test to identify whether the endpoint can pass the test. For information about determining the test result, refer to the third-party documentation.
7. Configure the user information endpoint to obtain third-party user information.
¡ URL: URL of the user information endpoint. In this example, it is the URL of the user information endpoint for the Keycloak service.
¡ Request Method: Select a method to initiate HTTP requests. Only GET and POST are supported. GET is selected.
¡ Request Header Parameters: Specify request header parameters that must be carried for access to the user information endpoint according to the requirements of third-party services. In this example, request header parameters for the Keycloak service are specified.
¡ Request Parameters: Specify request parameters that must be carried for access to the user information endpoint according to the requirements of third-party services. In this example, request parameters for the Keycloak service are specified.
¡ Response Parameters: Support only the response body in JSON format returned by the third party service. In this example, response parameters for the Keycloak service are specified.
Figure 49 User information endpoint
Click Test to identify whether the endpoint can pass the test. For information about determining the test result, refer to the third-party documentation.
8. Configure the logout endpoint. Typically, once a user agrees with authorization, the browser will retain the authorization information for a period of time. If that user visits the authorization page again, no active authorization is required. In this case, the browser will directly go to the callback URL. Using the logout endpoint will invalidate the authorization information saved in the user's browser. This ensures that the user must actively perform authorization again when visiting the authorization page again.
¡ Enable Endpoint: Select whether to enable this endpoint. For the third-party OAuth 2.0 systems that do not use this endpoint, you can disable it.
¡ URL: URL of the logout endpoint. In this example, it is the URL of the logout endpoint for the Keycloak service.
¡ Request Method: Select a method to initiate HTTP requests. Only GET and POST are supported. GET is selected.
¡ Request Header Parameters: Specify request header parameters that must be carried for access to the logout endpoint according to the requirements of third-party services. In this example, request header parameters for the Keycloak service are specified.
¡ Request Parameters: Specify request parameters that must be carried for access to the logout endpoint according to the requirements of third-party services. In this example, request parameters for the Keycloak service are specified.
Figure 50 Logout endpoint
a. Click Test. Before you click Test, you must test the authorization endpoint and access token endpoint. Then, keep the browser open and click Test to generate a URL.
b. Use the same browser to access each URL. If the authorization page appears again, this endpoint passes the test.
Figure 51 Authorization page
Configure an access device
An access device is used for controlling user access. Only users who have passed authentication can access the network.
Telnet to the access device from the Windows CLI.
1. Enter system view.
<Device>system-view
System View: return to User View with Ctrl+Z.
2. Configure a RADIUS scheme named allpermit. Specify the EIA server as the primary authentication server and primary accounting server. Make sure the authentication port, accounting port, and shared key are the same as those configured in "Adding an access device."
[Device]radius scheme allpermit
New Radius scheme
[Device-radius-allpermit]primary authentication 10.144.195.167 1812
[Device-radius-allpermit]primary accounting 10.144.195.167 1813
[Device-radius-allpermit]key authentication simple movie
[Device-radius-allpermit]key accounting simple movie
[Device-radius-allpermit]user-name-format with-domain
[Device-radius-allpermit]quit
3. Configure domain portal and apply policy allpermit.
[Device]domain portal
[Device-isp-portal]authentication portal radius-scheme allpermit
[Device-isp-portal]authorization portal radius-scheme allpermit
[Device-isp-portal]accounting portal radius-scheme allpermit
[Device-isp-portal]quit
4. Configure EIA as the portal authentication server. In this example, the server name is myportal. Make sure the key is consistent with the one configured in "Adding a device."
[Device]portal server myportal
New portal server added.
[Device-portal-server-myportal]ip 10.144.195.167 key simple movie
[Device-portal-server-myportal]quit
5. Specify the URL of the portal Web server (http://10.144.195.167:9092/portal). Make sure the setting is consistent with the address of the portal page configured in "Configuring a server."
[Device]portal web-server myportal
New portal web-server added.
[Device-portal-websvr-myportal]url http://10.144.195.167:9092/portal
[Device-portal-websvr-myportal]quit
6. Enable direct portal authentication on Vlan-interface 108 of GigabitEthernet 1/ 0/16. Reference portal Web server myportal and set the BAS-IP attribute value in portal packets sent to the portal authentication server. Make sure the BAS-IP setting is consistent with the public IP address configured in "Adding a device."
[Device]interface Vlan-interface 108
[Device-Vlan-interface108]portal enable method direct
[Device-Vlan-interface108]portal apply web-server myportal
[Device-Vlan-interface108]portal bas-ip 10.142.9.1
[Device-Vlan-interface108]Portal domain portal
[Device-Vlan-interface108]quit
Verifying the configuration
1. In the browser, enter the address of the portal page to access the portal authentication page.
Figure 52 Portal authentication page
2. Click OAuth 2.0 to access the Keycloak authorization page, and enter the username and password configured in "Adding a user."
Figure 53 Authorization page
3. Click Sign In. You see the authentication success page if you pass the authentication.
Figure 54 Authentication succeeded
4. Enter the login address of Unified Platform (http://ip_address:30000), where ip_address is the northbound service VIP of the cluster where Unified Platform is located. Select Automation > Network Access > Access Management > Online User > Local. You can view the user information.