SAML2 Single SingOn

[imran_khatyan]

Hello, 

Getting the following error and ends in access_denied any idea: 

The signature verified correctly with the key contained in the signature, but that key is not trusted

regards, 

[rsutcliffe]

@ibra22 

Please note that a lot of your questions are outside of the scope of my knowledge. I am doing the best I can to backfill some information that I have learned in my time here. I do believe that it would be best to engage with someone at Professional Services as they will be the subject matter experts on properly configuring these types of setups within Hopex. With that being said, I have done my best below to address your open questions. 

• how this is gonna mapped to HOPEX login?
  • Users will be mapped into Hopex automatically assuming that the authentication group is configured properly on Hopex side and the associated claims are configured properly on the Idp side. If the user does not exist, it can be automatically created and assigned a predetermined profile in accordance with the desired configurations. 
• I created the authentication params and saml2 group as you suggested but what is the benefit of each?
  • These are to match the claims made on idp side and allow Hopex to know who is logging into the application. 
• Moreover, for the saml2 group, do I need to add all users to it so that they can access via SSO or what the point of having this group.
  • Users will be added to these groups as they login to Hopex, assuming that they pass the authentication step via your Idp.
• Should I use [SSL Certificate] in the SAML config?
  • I believe that the cert should be referenced in the Idp, but I cannot be certain. This is outside of my scope of knowledge. 
• If yes, can I use its friendly name?
  • I am not familiar enough with SSL tickets to be able to answer this question. I am unsure about the impacts of using friendly names vs. server names when configuring SSO.
• Lastly, do we need to configure ADFS server?
  • This would be a better question for someone in the Services Department. It may depend on the needs of the organization. 
• I have checked the UAS logs and seen that the IdP sent a response to /UAS/AuthServices/Acs but rejected due to CORS path. Any idea about that?
  • CORS errors can be related to many things. A common issue is mismatches with the URL. So, its possible that there are definitions that are not matching somewhere along the line.

I know I was not able to answer all of your questions, but I hope what I was able to answer helps you continue to make progress. From what you have mentioned, it does seem you have made progress from where we started; but I do believe we have reached the limits of my knowledge in this topic. I suggest that if you need further help to engage with someone in Professional Services. 

Thank you, and kind regards.

Ryan

[ibra22]

@rsutcliffe 

I have checked the UAS logs and seen that the IdP sent a response to /UAS/AuthServices/Acs but rejected due to CORS path. Any idea about that?

[ibra22]

@rsutcliffe 

One more thing, what about the SSL certificate? The IdP have given me a certificate and I imported it under personal & trusted certificates. Should I use it in the SAML config? If yes, can I use its friendly name?

Lastly, do we need to configure ADFS server?

[ibra22]

@rsutcliffe 

As I understand, the SSO URL is the IdP URL I need to send the users to when they login, I got this URL from IdP and put in the SAML config

Also I am getting a "sub" attribute in the SAML response, it holds the user login, my question is how this is gonna mapped to HOPEX login? I created the authentication params and saml2 group as you suggested but what is the benefit of each?

I defined Email & Name params as you showed, does the saml response have to contain the same attributes (Name & Email) cause now it contains attribures (group, sub, mail).

Moreover, for the saml2 group, do I need to add all users to it so that they can access via SSO or what the point of having this group..

Thank you

[rsutcliffe]

@ibra22 

Is the Sign on URL configured?

Additionally, did you configure the user claims on IDP side and associated authentication group on Hopex side?

I hope this helps.

Kind regards,

Ryan

[ibra22]

@rsutcliffe 

Now it worked and the request sent properly but now have an issue with the SAML response, it gives me access denied error.

In the response I am getting an attribute called "sub" with value "the user login", this attribute as per MEGA should be there holding the login to do the mapping.

Any Idea?

[rsutcliffe]

@ibra22 

I could be wrong, but I believe on the IDP side you want Acs to be https//servername/UAS/AuthServices/Acs

Kind Regards,

Ryan

[ibra22]

@rsutcliffe  @imran_khatyan  @ikn 

I turned all http to https but still not working. I checked the UAS logs and found ""AssertionConsumerServiceUrl":"http://rtaueveabpmst1/UAS/AuthServices/Acs"" I dont know from where this is coming and how to change it.

Please look at the attached screenshot to see it from the logs.

For IdP side, they have MEGA meta data which mentions the SAML issuer (https//servername/UAS) and Acs (https//servername/hopex), this information should be matched with SAML request sent by MEGA.

In the SAML request, the issuer is the same no issues but the Acs is different (http://rtaueveabpmst1/UAS/AuthServices/Acs)

[rsutcliffe]

@ibra22 

Have you also made configurations on the IDP portal side to allow the connection to complete? 

This is a little outside of my scope of knowledge, so I do not have specific information. But I do know that there is a portal on the IDP side that needs configuration as well.

It looks like the return URL is in HTTP and I would expect it to be HTTPS. I would suggest changing all URLS to be secure as to my knowledge this would be a requirement to make SSO work. 

If you continue to encounter issues after that, it might be worth engaging someone from the Professional Services department that is skilled in this area of Hopex to help resolve the configuration. 

Kind regards,

Ryan

US Support

[ibra22]

@rsutcliffe 

Now I am facing a weird behavior. In SAML config I put "http://servername/hopex" as a return URL but when I tried and check the SAML request I found another ACS URL "http://servernameUAS/AuthServices/Acs" which should be as same as the return URL http://servername/hopex.

As well as this URL "http://servernameUAS/AuthServices/Acs" is not mentioned anywhere I am not sure why it's there in the request

I attached the SAML config and decoded SAML request if you could look at it.

Thank you