Redirect URL does not match
One usual Identity Provider (IdP) misconfiguration is the incorrect setting of the redirect URI in your IdP. You will encounter the IdP error page in such instances:
For Azure AD
By default, Datawiza Access Proxy utilizes the following format for the IdP login redirect URL:
public domain + /datawiza/authorization-code/callback. Please verify this value in your IdP settings console to ensure it aligns correctly.
Datawiza Access Proxy configuration applied failed
Once the initiation or updates to the Datawiza Access Proxy (DAP) are complete, the status of this process can be tracked on the Datawiza Cloud Management Console Deployments page.
This page displays Notifications updates related to configuration application outcomes, encompassing both DAP launch and configuration updates.
If DAP applied the new configurations successfully, you could see the Notifications and Status below:
However, if the DAP fails to apply the new configurations, different Notifications and Status updates will be visible, as illustrated below:
A common instance of failure could be due to the provided domain name for the upstream server not being resolvable. The tool nslookup can verify domain name resolution:
Alternatively, Docker's exec command can also be used:
docker exec -it datawiza-access-proxy nslookup your-service-domain-name.
In a scenario where the upstream server's DNS name can be resolved, but the IP address remains inaccessible, a 5xx error will be displayed after login. On the DCMC, this issue does not display under Notifications as "configuration applied failed". Instead, it is manifested under Status as a WARNING situation. Moreover, you can scout for a note that reads
Upstream is unavailable:
For a more comprehensive troubleshoot, you can access more details by clicking on the deployment. This will provide granular information such as the specific upstream of the DAP that is unreachable:
It's essential to note that this type of situation may occur if the resolved address of the upstream service undergoes changes. Restarting the DAP can help update the resolving address.
If you encounter difficulties receiving headers or configuring user attributes, you can utilize the following debug endpoints to assist with your diagnosis:
|/datawiza/.auth/me||Return the basic user info including username, groups, email, first name, and last name.|
|/datawiza/.auth/me?includeToken=true||Return access token, access token expire time, id token, and refresh token besides basic user info.|
|/datawiza/ab-userinfo||Return two types of user info: oauth_user_info returns all user profiles DAP can get, and user_info returns basic user info.|
Build-in testing application and Attribute Pass debugging
We offer a built-in service on port 9902 specifically designed for attribute pass testing. To proceed, modify the upstream server configuration to point to
http://localhost:9902, and ensure that you include the necessary attribute pass in your setup.
After a successful login, the user information should be displayed. Additionally, you'll find an option to view the raw request headers that will be sent to the upstream services by clicking on Raw.
In addition, it is possible to verify header-based authentication for your applications leveraging browser extensions like ModHeader. Alternatively, the
-H command-line option in Curl can also be employed to carry out this task. By using the 'Key: Value' format, you can easily send an HTTP header within your Curl request. Here's an illustrative example:
curl -H 'x-dw-user: true' -H 'email: firstname.lastname@example.org' http(s)://your-application
In this command,
email@example.com which are sent along with the request to your application.
Since we do not provide any HTTPS configuration other than the public domain from getting-started, you need to set HTTPS after finishing the getting-started configuration:
If you did not set SSL but accessed the application URl, you would see the error page:
On the flip side, if you configure the SSL settings but attempt to access the URL using the
http://your-host protocol, you'll encounter a 400 error. This error will be accompanied by an error page resembling the following:
You can see SSL Configuration for more details.