In order to be able to reverse engineer the behavior of SSO / New Edge UI config for private cloud, I need to enable deep debugging in the Apigee internals of setup.sh and apigee-service, in order to determine how public / non-public hosts / ports get replaced in all the Apigee internal config files.
Is there any generic swith to configure, e.g. in customer properties or in the Apigee config files, to massively increase the log level to tracing?
The documentation is quite incomplete / inconsistent, and i am not able to costruct of host/IP/port combinations based on the tiny incomplete documentation snippets provided by Apigee.
Due to complexity, we need to set up everything in one shot, otherwise config of Apigee gets even more complex:
- SSO with IdP
- New Edge UI
- TLS for MS / New Edge UI / SSO
- Load balancers (non-terminating), having standard HTTPs ports 443, in contrast to components having some custom ports (need to modify all of them in order to be able to test due to company firewall restrictions.
In our test environment, we're using 4.50.00.08 in on-premise, with a global 49 node setup across 9 data centers, in 5 different network zones separated by firewalls.
I am already struggling since 7 days, trying different permutations of using LB DNS alias, replacing IP with host or DNS alias, reverse-engineering Java / SpringBoot libraries used by Apigee based on the errors observed in the log, reverse engineering placeholder replacements in the setup.
However, always ending up with inconsitent host/port combinations, sometimes empty host name, sometimes setup getting stuck during server restart.
I had to fully uninstall sso / ui including manual removal of non-deleted artifacts in e.g. tokens folder, somtimes had to kill -9 some orphaned processes.
I need at least a trace from the provided Apigee config file up to the files populated in the component's config folders, in order to see where something wrong was catched up or not refreshed or silently ignored.
Hi Michael,
Your request is on how-to more debug the SSO module, or you need actual help with the SSO installation, based on your architecture?
Hi Dennis,
it's regarding how to analyze issues during SSO setup.
Already ran into several issues, like:
Whole flow is always doing ping-pong with client based on redirects:
Currently ending up with something like:
url: https://api-management-apigee-sso-myhost.org/oauth/token?code=jD9VABCDEFG123456789, Status: 400 and Response: {"error":"invalid_grant","error_description":"Redirect URI mismatch."}
Invalid redirect uri {https://myhost:33001/oauthCallback} for client {newueclient}, did not match one of the registered values
Especially mixup of public and internal DNS name / port is causing big trouble.
Using load balancer for all public URLs, mapping port 443 to Apigee ports.
However, somewhere in the SSO flow, an URL like this is constructed, after returning from IdP (whis is of course registered with the load balancer URL):
I had to provide
HOSTFQDNNAME=$(hostname -f) MANAGEMENT_UI_IP=$HOSTFQDNNAME MANAGEMENT_UI_PORT=33001
The redirect URI is using the INTERNAL port.
UI would have expected that it's using these settings for redirects:
UI_LB=api-management-apigee.mycompany.net MANAGEMENT_UI_PUBLIC_PORT=443 MANAGEMENT_UI_PUBLIC_HOSTNAME=$UI_LB
Furthermore it's not obvious, which redirect_URL Apigee is verifying for that error message against which expected value.
Manually replacing the redirect_url with load balancer DNS alias and port in the browser's URL seems to be the way to go, hence next step will be modifying the Apigee internal created config files with some URLs which could be resolved from the user's browser.
However, still not having a clue how to set it up properly for full SSO flow being successful.
Hi @michaelveit
You probably don't need help with this anymore, but I will provide the solution (I received from Apigee Support) for this issue anyway in case someone else needs it:
---
The redirect_uri value can be overriden by adding following entries to /opt/apigee/customer/application/management-ui.properties on the node where edge-management-ui component is installed.
conf_uebe_defaulturl="https://<LB hostname>”
conf_uebe_callbackurl="https://<LB hostname>/oauthCallback”
Make sure apigee user and group has ownership of the file. Then restart the management-ui component. Please make sure the value of conf_uebe_defaulturl property matches MANAGEMENT_UI_SSO_REGISTERED_PUBLIC_URIS value in the silent config file.
---
Kind regards,
Piet
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |