ā22-10-2020 06:32 PM - edited ā22-10-2020 06:58 PM
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
ā10-11-2020 11:13 PM
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 !
ā09-11-2020 09:40 PM
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?
ā06-11-2020 10:42 PM
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 !
ā06-11-2020 04:08 PM
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.
ā04-11-2020 08:52 PM - edited ā04-11-2020 08:55 PM
Hello Olivier,
Thanks for your detailed answer.
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.
ā04-11-2020 09:43 AM
Also can you try this : https://hopex.dev.uni/UAS/.well-known/openid-configuration
ā04-11-2020 09:36 AM
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.
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
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 -->
ā04-11-2020 12:14 AM
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.
ā03-11-2020 11:47 AM - edited ā03-11-2020 11:48 AM
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" ?
ā23-10-2020 03:54 PM
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.