...
Info |
---|
title | Proper SSO certificate not in place |
---|
|
When: - Accounting Service authorised user tries to access the browser end-points like
https://accounting.example.com/accounting/report (example URL) - Browser redirects to the SSO login page where user is supposed to authenticate with the configured authentication method to the OAuth2 application created during the installation process
What: Code Block |
---|
| 2019-11-13 15:06:47.677 ERROR 4100 --- [http-nio-8084-exec-10] c.u.i.a.oauth2.IntrospectingJwtDecoder :
Token: eyJjdHkiOiJKV1QiLCJhb...6Gfpp6GF877syj7OIo8oA introspection failed: ResourceAccessException:I/O error on
POST request for "https://sso.example.com/uas/oauth2/introspection": sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path
to requested target; nested exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path
to requested target |
Why: - Account Service can not complete the authentication flow as it does not trust SSO server when accessing it from server side
- SSO server is not added to the Java trust store or the owner of the certificate is not correct
- In the case above IP address has been used instead of the host name, which is not possible for the certificate subject
How to fix: - If the certificate is missing from the Java trust store, add it by following the instructions in here, and restart Accounting Service
- If the host name in the certificate is not correct, fix settings in
win32.config /unix.config file, remove the already created certificate from the installation directory before continuing with the installation
|
...
Info |
---|
title | Redirect URI mismatch during OAuth2 flow |
---|
|
When: - Accounting Service authorised user tries to access the browser end-points like
https://accounting.example.com/accounting/report (example URL)
- Browser redirects to the SSO login page where user is supposed to authenticate with the configured authentication method to the OAuth2 application created during the installation process
What: Authentication succeeds but the report is not downloaded, there is this kind of [invalid_redirect_uri_parameter] error page: Image Modified |
---|
or this kind of [Invalid credentials] error page: Image Modified |
---|
Why: - Behind a proxy OAuth2 redirection requires a link to the proxy and not to the physical address of the machine hosting your application
- The property name to define the log file location changed in SSO 8.7 and is now
server.forward-headers-strategy which you may have missed when doing upgrade
- Account Service redirect URI needs to be exactly the same in the browser and in the configuration
- Browsers tend to change an uppercase hostname to lowercase and checking on Spring framework side is case sensitive
How to fix: - In case of proxy check that you have not overridden or removed
server.forward-headers-strategy (earlier server.use-forward-headers ) setting in Accounting Service additional configuration and configured your reverse proxy / load balancer to send X-Forwarded-For and X-Forwarded-Proto headers- Fix the custom configuration file in this location:
ubilogin/custom/accounting/config/application.yaml and update service by running ubilogin /config/tomcat/update script.
- Check that access URL (in lowercase) matches with
accounting.url setting in win32.config /unix.config file, and that the network configuration supports this properly
|
...
Info |
---|
title | Hostname changes during OAuth2 flow |
---|
|
When: - Accounting Service authorised user tries to access the browser end-points like
https://accounting.example.com/accounting/report (example URL)
- Browser redirects to the SSO login page where user is supposed to authenticate with the configured authentication method to the OAuth2 application created during the installation process
What: Why: - Account Service can not complete the authentication flow as the session cookie (
JSESSIONID ) has expired or does not have a matching hostname - Spring framework creates the session cookie with the hostname from the original request URL and tries to find the cookie with the hostname in the redirect URL and if they differ the problem occurs
How to fix: - Session expires by default in 10 minutes, try again if the error persists
- Check that access URL matches with
accounting.url setting in win32.config /unix.config file, and that the network configuration supports this properly
|
...
Info |
---|
title | SSO server changes during OAuth2 flow |
---|
|
When: - Accounting Service authorised user tries to access the browser end-points like
https://accounting.example.com/accounting/report (example URL)
- Browser redirects to the SSO login page where user is supposed to authenticate with the configured authentication method to the OAuth2 application created during the installation process
What: Why: - In a clustered environment OAuth2 flow starts with one SSO server node but once SSO session is created the flow continues on another SSO server node which is not aware of the existing SSO session and rejects the authorization code
- You must configure either active-passive setup or use Redis as session storage for your cluster
How to fix: - Fix clustered SSO configuration like explained here SSO Cluster installation
- With IIS, check the SSO server load balancing and server affinity for sticky sessions, you need to have different client cookie name for different server farms, it is a good idea to restart your site after the configuration has been changed
- As a temporary solution you can try several times and may succeed, or you can disable all but one SSO node in order to get the report you need. However, note that incorrect cluster configuration may also affect your customers in regular SSO usage.
|
...
NOTE that the detailed information is by default shown only to the authenticated users, see Accounting Service management / Health endpoint detailed information.
The following screen snapshot of Accounting Service health check is captured in a situation when the Accounting Service has first succesfully started but then PostgreSQL server has stopped. Processing the health check request takes 30 seconds which is the connection timeout length. HTTP response code 503 is returned with the following kind of JSON data:
Image Modified |
---|