• Replies 11 replies
  • Subscribers 0 subscribers
  • Views 71 views
  • Users 0 members are here
Options
3sides - Social sharing widget
Related

HighQ and SSO

Athar Agha
27289

Not sure if this is possible but curious as to current capabilities..

I understand that HighQ can accept identity providers 'upstream', in that placing an IDP 'before' HighQ will allow authentication into HighQ ("You've logged into Okta, so you can now access HighQ").  Is there any capabilities that will allow HighQ to act as an IDP?   ("You've logged in to HighQ so you can now access site x") ? 

i.e. we want to be able to validate a user login request at HighQ and pass that SAML response downstream instead of it stopping at HighQ so we can authenticate other systems..

I know this wasn't possible last year as it looked like there was no way to pass that response downstream, but wondering if things have changed now that TR are at the helm?

Thanks

Parents

  • I think there are two kinds of use cases in this - though hopefully someone from HighQ itself can comment specifically...

    1) users who have an upstream account - i.e. managed in AAD or Okta, in this case HighQ should delegate authentication upstream to the IDP.. i.e. if you log in to HighQ and it's an SP initiated SSO request, it'll punch out to AAD/Okta & perform validation there, returning a SAML assertion with the user details, which can then be used in HighQ.. that is: "oh you're trying to log on but I see you're managed by AAD/Okta? ok i'm redirecting you and if everything checks out ok when you prove yourself to them (and they let us know its ok), we can carry on".

    This is how "normal" SP initiated SSO works - we've built this for a few non HighQ Platforms & it's an established pattern ... SSO initiated in this way should delegate up to your IDP (Okta) which will do the actual authentication, which then flows back to HighQ to carry on...

    2) users who have a HighQ account - i.e. managed in HighQ itself (with it's own conditional MFA etc. if enabled). In this case what we're looking for is being able to use this HighQ user in our downstream systems ... that is: "Oh you're accessing a system downstream? well let me just check with HighQ that you are who you say you are.. if it checks out, we can talk" ..

    Like I said, 1) is how it works in traditional SAML SSO setups, though i'm not sure of the specifics in how HighQ itself is configured to work.. & 2) is what we'd like to do moving forward..

    HTH

Reply

  • I think there are two kinds of use cases in this - though hopefully someone from HighQ itself can comment specifically...

    1) users who have an upstream account - i.e. managed in AAD or Okta, in this case HighQ should delegate authentication upstream to the IDP.. i.e. if you log in to HighQ and it's an SP initiated SSO request, it'll punch out to AAD/Okta & perform validation there, returning a SAML assertion with the user details, which can then be used in HighQ.. that is: "oh you're trying to log on but I see you're managed by AAD/Okta? ok i'm redirecting you and if everything checks out ok when you prove yourself to them (and they let us know its ok), we can carry on".

    This is how "normal" SP initiated SSO works - we've built this for a few non HighQ Platforms & it's an established pattern ... SSO initiated in this way should delegate up to your IDP (Okta) which will do the actual authentication, which then flows back to HighQ to carry on...

    2) users who have a HighQ account - i.e. managed in HighQ itself (with it's own conditional MFA etc. if enabled). In this case what we're looking for is being able to use this HighQ user in our downstream systems ... that is: "Oh you're accessing a system downstream? well let me just check with HighQ that you are who you say you are.. if it checks out, we can talk" ..

    Like I said, 1) is how it works in traditional SAML SSO setups, though i'm not sure of the specifics in how HighQ itself is configured to work.. & 2) is what we'd like to do moving forward..

    HTH

Children
No Data