UAS Strange behavior since upgraded to V4CP1HF01

[RGenin]

Hello, 

Since we have installed V4 CP1 HF01 (straight from V4) in our DEV environment, we have a problem with UAS authentification we did not have before:

1/ If we go to URL https://hopex.dev.uni/Hopex/ it is going as it should to https://hopex.dev.uni/Hopex/uaslogin.ashx . However, there is a 404 status:

If we refresh the page on the same url, the error code changes (from 404 to IDX20803) :

2/ If we go directly to https://hopex.dev.uni/Hopex/login.aspx it is going to to https://hopex.dev.uni/Hopex/uaslogin.ashx again and we get the same 404 error page.

However, if we go directly  to https://hopex.dev.uni/Hopex/login.aspx again (as many times as we want within the same session in the browser), then we can correctly login:

We have double checked everything : permissions, rights on certificates (we even reimported them according to the UAS procedure, ect)

Any clue ?

Thanks

[RGenin]

Hello Joseph, 

So I can confirm we double/triple checked, and still no luck.

So we have taken another approach:

- We have completely removed Mega Hopex from our VM

- We have redownloaded the V4  (now embedding CP1) and reinstalled it , and installed the hotfix as well. 

-=> it works well now (without doing anything else)

So going the fresh V4CP1 + hotfix route worked for us, whereas the V4 + CP1 + hotfix did not.

Thanks for your assistance !

[jcamara]

Hello,

Ok, thanks for the reply and information. Another thing to check would be consistency of the case sensitivity of the URLs in the Megasite.ini and Hopex Administration.exe "Site" Options. In standing up an installation of V4 CP1 on a virtual machine (leveraging Hopex's Native authentication for a test user)

I had to confirm that all URLS in the Megasite.ini

and specific settings in the extended view of the Options were identical (using an Upper Case "H") 

        

Could you take a look and confirm?

[RGenin]

Hello Joseph, 

Here is the screenshot of the registry key:

Indeed in our installation is not clustered and we used CNAME.

We are always using the supervisor tool (swl 6 mode) to restart all the suite after ay modification.

Thanks !

[jcamara]

Hi RGenin,

What does the MWAS URL in the registry look like on the server? It is located here:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MEGA\WEB ACCESS SERVER\7.1

If your deployment is not clustered (All on a Single Server) you can set it to leverage the CNAME as well (if it isn't already).

Also, when changing/updating URLs, I'd recommend leveraging the Supervision Utility to stop all services/IIS then Restart IIS followed by Server Supervision Services (Microsoft Services) then the Watchdog.

[RGenin]

Hello Olivier, 

Thanks for your detailed answer.

• Did you change the URL when moving from V4 to V4 CP1 HF1 ? => No changes is IIS or in the configs
• Does the URL of the SSL certificate is aligned with the URL we see in this post ? => yes
• Are you sure of the option of the web.config of HOPEX ? => yes

Here is the content of openid-configuration :

{
    "issuer": "https://hopex.dev.uni/hopex/UAS",
    "jwks_uri": "https://hopex.dev.uni/hopex/UAS/.well-known/jwks",
    "authorization_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/authorize",
    "token_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/token",
    "userinfo_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/userinfo",
    "end_session_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/endsession",
    "check_session_iframe": "https://hopex.dev.uni/hopex/UAS/connect/checksession",
    "revocation_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/revocation",
    "introspection_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/introspect",
    "frontchannel_logout_supported": true,
    "frontchannel_logout_session_supported": true,
    "scopes_supported": ["phone", "email", "address", "roles", "openid", "profile", "offline_access", "hopex", "write", "read"],
    "claims_supported": ["phone_number", "phone_number_verified", "email", "email_verified", "address", "role", "sub", "name", "family_name", "given_name", "middle_name", "nickname", "preferred_username", "profile", "picture", "website", "gender", "birthdate", "zoneinfo", "locale", "updated_at"],
    "response_types_supported": ["code", "token", "id_token", "id_token token", "code id_token", "code token", "code id_token token"],
    "response_modes_supported": ["form_post", "query", "fragment"],
    "grant_types_supported": ["authorization_code", "client_credentials", "password", "refresh_token", "implicit"],
    "subject_types_supported": ["public"],
    "id_token_signing_alg_values_supported": ["RS256"],
    "code_challenge_methods_supported": ["plain", "S256"],
    "token_endpoint_auth_methods_supported": ["client_secret_post", "client_secret_basic"]
}

As for the  https://hopex.dev.uni/Hopex/uaslogin.ashx , I believe it comes from our megasite.ini  (I don't remember having that many values configured in it before, but I don't have a copy on hand) (check Client.DTPX.AllowedRedirectUris)

[Authentication]
Client.DTPX.AllowedRedirectUris=https://hopex.dev.uni/hopex/uaslogin.ashx;https://hopex.dev.uni/hopex2/uaslogin.ashx
Client.DTPX.PostLogoutRedirectUris=https://hopex.dev.uni/hopex/Default.aspx
Provider.Windows.ServerUrl=https://hopex.dev.uni/WindowsAuthenticationService
Client.DTPX.RedirectUris=https://hopex.dev.uni/hopex/uaslogin.ashx;https://hopex.dev.uni/hopex2/uaslogin.ashx
Authentication.InvalidSignInRedirectUrl=https://hopex.dev.uni/hopex/Default.aspx
Client.Swagger.RedirectUris=https://hopex.dev.uni/hopexapi/api/v1.0/uasproxy
Client.Swagger.AllowedRedirectUris=https://hopex.dev.uni/hopexapi/api/v1.0/uasproxy
PublicOrigin=https://hopex.dev.uni/hopex
Cookie.AllowRememberMe=1
SigningCertificate.Password= REDACTED
SigningCertificate.Name=hopex.dev.uni

Thanks, 
Raphaël.

[oguimard]

Also can you try this : https://hopex.dev.uni/UAS/.well-known/openid-configuration

[oguimard]

Hello,

Looking at the error message "PII is hidden" it refers to issues with URL not being aligned across all the layers of the call.

• Did you change the URL when moving from V4 to V4 CP1 HF1 ?
• Does the URL of the SSL certificate is aligned with the URL we see in this post ?

I'm also suprised by the URL of UAS.

---

@RGenin wrote:

If we go to URL https://hopex.dev.uni/Hopex/ it is going as it should to https://hopex.dev.uni/Hopex/uaslogin.ashx .

---

If a UAS properly configured installation

• If you write : https://hopex.dev.uni/Hopex/
• You should go to : https://hopex.dev.uni/UAS/login?signin=******
• You should not go to Hopex/uaslogin.ashx

Are you sure of the option of the web.config of HOPEX ?

Particularly the keys :

<add key="AuthenticationUrl" value="https://hopex.dev.uni/UAS"/>
<!-- Authentication service url -->

[RGenin]

Hi Asim, 

Indeed points 1/2/3 are correct.

If we enable Mega auth, it will work without any issue.

If we enable UAS, the problems shown above arise. It was working fine before CP1/HF1.

All paths/links are correct in every web.config subfolders, as well as a matching SSP key.

Thanks, 

Raphaël.

[AHassan]

Hi Raphaël,
Regarding your 1st post, I am assuming that:

1. It is working fine when you change the authentication to "Mega" in web.config file ("C:\inetpub\wwwroot\HOPEX")

2. There is no Single Sign on configured

3. This address (https://hopex.dev.uni) seems to me a CNAME to actual server name

So, to start with, if you do the point 1, does it work?

If yes then check the megasite.ini file, does it has the correct paths/links with "hopex.dev.uni" and also in web.config files for "C:\inetpub\wwwroot\HOPEX" and "C:\inetpub\wwwroot\UAS" ?

[RGenin]

Hi @oguimard , 

No, we haven't : our migration path is to upgrade directly from V2R1CP7 to V4CP2 when it will be out, and we have already spent too much time trying to test this version or make it work. This post was more a FYI / raise concern for Mega in case something was broken (or a security issue in our example) 

Other then that the problem mentioned above, in this version:

* Service-Now integration is also broken (was working on V4), all jobs failing at tRESTClient step.

This was an improvement, as Talend was showing a java error message before. 

This was solved by adding certificates (mega + our own sub-domain where Mega runs)  to the cacerts file in the java folder(s).

EG: 
keytool -importcert -file "C:\temp\mega.com.cer" -alias mega.com -keystore "C:\Program Files (x86)\MEGA\HOPEX V4\java\jre\lib\security\cacerts"

The cacerts trick also solved the "UAS - Refresh Bearer token" that was broken in Postman as well.

Best, 

Raphaël.