Configuring authentication individually for each backend service adds complexity and inconsistency. With IDaaS authentication on the cloud-native gateway, the gateway handles authentication centrally. It intercepts incoming requests, redirects unauthenticated users to your Identity as a Service (IDaaS) instance for login, and forwards authenticated requests to upstream services.
How it works
The cloud-native gateway uses the OAuth 2.0 authorization code flow to authenticate requests through your IDaaS instance:
A client sends a request to the gateway.
If no valid session cookie exists, the gateway redirects the client to the IDaaS logon URL.
The client authenticates with IDaaS and grants consent.
IDaaS redirects the client back to the gateway with an authorization code, using the configured redirect URL.
The gateway exchanges the authorization code for tokens and validates them.
After validation succeeds, the gateway sets a session cookie on the configured cookie domain and forwards the request to the upstream service.
Prerequisites
Before you begin, make sure that you have:
An activated Alibaba Cloud IDaaS instance
An OAuth 2.0 application created in the IDaaS console, with the client ID, client secret, and logon URL noted
A redirect URL determined for your gateway and configured in your IDaaS application settings
Create an authentication rule
Log on to the MSE console.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways.
In the top navigation bar, select a region.
On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose Security Management > Global Authentication.
In the upper-left corner, click Create Authentication.
In the Create Authentication panel, configure the following parameters and click OK.
Parameter Required Description Authentication Name Yes A name for this authentication rule. Use a descriptive name that identifies the purpose, such as idaas-prod-auth.Authentication Type Yes Select IDaaS. Logon URL Yes The logon URL of your IDaaS instance. Obtain this from your IDaaS application settings. Redirect URL Yes The URL that IDaaS redirects to after successful authentication. This URL must exactly match the redirect URL configured in your IDaaS application. Client-ID Yes The client ID of your IDaaS OAuth 2.0 application. Client-Secret Yes The client secret of your IDaaS OAuth 2.0 application. Do not expose this value in logs or version control. Cookie-Domain Yes The domain for the session cookie that maintains logon status after authentication. Cookie-Domain=a.example.comlimits the cookie toa.example.com.Cookie-Domain=.example.comsends the cookie to all subdomains ofexample.com. Use the narrowest scope that covers your application to reduce cookie exposure.Authorization Yes Select Whitelist or Blacklist to control which requests require authentication. See Configure authorization rules.
Configure authorization rules
The Authorization setting determines how the gateway evaluates which requests require authentication:
Whitelist: Requests that match the specified hosts and paths bypass authentication. All other requests require authentication.
Blacklist: Only requests that match the specified hosts and paths require authentication. All other requests pass through without authentication.
To add rule conditions:
Click Rule Condition.
Specify the request parameters:
Domain Name: The host that the rule applies to.
Path: The path that the rule applies to.
View authentication details
After creating an authentication rule, you can view its configuration and add authorization rules.
Log on to the MSE console.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways.
In the top navigation bar, select a region.
On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose Security Management > Global Authentication.
On the Authentication page, click the name of the authentication rule. Alternatively, find the rule and click Details in the Actions column.
Review the Authentication configuration and Authorization Info sections.
To add authorization rules to an existing configuration, click Create Authorization Info in the Authorization Info section. Configure the Request Host and Request Path parameters.
Verify the configuration
After you create the authentication rule, it appears on the Authentication page.
To confirm that IDaaS authentication works as expected:
Enable the authentication rule. See Manage authentication rules.
Open a browser and navigate to a URL protected by the rule.
Confirm that the browser redirects to the IDaaS logon page.
Log on with valid credentials and confirm that the browser redirects back to the original URL.
Manage authentication rules
On the Global Authentication page, find the authentication rule and use the Actions column:
| Action | Description |
|---|---|
| Enable | Activate the authentication rule. Requests that match the rule are subject to IDaaS authentication. |
| Disable | Deactivate the authentication rule. Requests pass through without IDaaS authentication. |
| Edit | Modify the authentication rule configuration. |
| Delete | Remove the authentication rule. Disable the rule before deleting it. |
Note: Disable an authentication rule before deleting it. Active rules cannot be deleted.
FAQ
The browser does not redirect to the IDaaS logon page
Verify that the authentication rule is enabled on the Global Authentication page.
Confirm that the request URL matches the authorization rule conditions (host and path).
If you use a Whitelist, make sure the request URL is not in the whitelist. Whitelisted requests bypass authentication.
Authentication fails with a redirect error
Verify that the Redirect URL in the MSE console exactly matches the redirect URL in your IDaaS application. A mismatch causes the OAuth 2.0 authorization code exchange to fail.
Make sure the redirect URL is reachable from the client browser.
The session cookie is not set after successful authentication
Check the Cookie-Domain value. If the cookie domain does not match the domain of the service you are accessing, the browser does not send the cookie.
Use the narrowest domain scope that covers your application. For example, use
a.example.cominstead of.example.comwhen only one subdomain needs authentication.