Debugging Apigee setup for SSO

[michaelveit]

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.

[Denis_KALITVI]

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?

[michaelveit]

Hi Dennis,

it's regarding how to analyze issues during SSO setup.

Already ran into several issues, like:

• openssl in Windows creating cert format with CRLF line breaks, causing exceptions
• IdP metadata.xml not to be opened in a text editor, which might add line break at the end (does not matter of CRLF or LF), or formatting the XML for readability. If metadata.xml is not in one single line, causing SSO different error message, which does not point into any useful direction of solving the error. Even identifying WHICH of the 5 cert formats was causing the error message was a challenge, just seeing various stack traces.
• When using self-signed cert for our company root CA, specification of the exact cert formats for SSO needs to be explored based on the parameters documented for openssl command line tool, instead of describing the required format (as there are plenty of variants for certs).
• Where to use IP addresses and where to use host names is not quite obvious, have to configure hostnames where IP is mentioned.
• Enterprise setup with load balancer and standard HTTPS port 443, mapping to Apigee components Edge UI, SSO and MS in customized ports (need to use a port range which is open in our firewalls, hence having to change most of the ports).

Whole flow is always doing ping-pong with client based on redirects:

• The diagram in the documentation
  https://docs.apigee.com/private-cloud/v4.50.00/configure-your-saml-idp
  does not reflect that, and is missing EdgeUI as well.
• Each of the redirects should have a relevant snippet of the URL in the documentation, in order to identify in which step the complex setup fails.
  I am now trying to follow this diagram, which I found on a website:
  https://toolkit.okta.com/apps/generator-okta-oidc-apigee/
  which is much more useful and correct than the diagram provided by Apigee

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

[michaelveit]

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):

https://api-management-apigee-sso-mycompany.net/oauth/authorize?client_id=newueclient&redirect_uri=h...

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.

[pietjacobs]

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