• 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

  • Thomson Reuters Thomson Reuters staff member

    Hi Athar Agha => We are currently working with one of our integration partners to implement a POC for (more or less) this. We'll see how it goes, and if this is something we can offer more widely, it will be announced here.

    CC Dan Pryor - incase I've gotten anything wrong in my high-level summary.

  • Peter Simpson - Thanks for the reply! Any idea of timelines w.r.t to this? we've a number of use-cases that would really benefit & are trying to align them if this is something that's doable..

     

  • Hi all - any updates on this functionality? Would be really interested to see this as a feature given we're reviewing our IAM platforms at the moment & need to have integration properly configured

     

  • Following up on a part of this: "I understand that HighQ can accept identity providers 'upstream', in that placing an IDP 'before' HighQ will allow authentication into HighQ". Does that capability expand to external users? Could an external user login to Okta, for ex, and from there access our Collaborate instance?

    and how would that work if we employee Collaborate's true 2FA and also require a periodic password reset?

  • 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

  • Thanks. We have the traditional SAML SSO for our internal users, which we preconfigured with HighQ to work with our particular setup. Trying to figure out how that would be possible for external users, where there is likely no way for us to preconfigure for each client their own setup. I think of the sites you go to where you can login with MSFT or Google without preconfiguring anything.

  • Thomson Reuters Thomson Reuters staff member

    So the 'flow' described by Athar Agha as 1) is more-or-less what we currently do (as I understand it), when you have SSO configured.
     

    Mark Salamon is the kind of authentication you are talking about where you visit a webapp and it has a 'login with Facebook/Github/Whatever' button?

    FWIW on occasion, we have set up external users (i.e clients of our clients) SSO in instances. IDP discovery looks at IP address/range and seeing as 99.9999% of our clients enforce the use of a corporate vpn, its perfectly possible to have us forward users coming from different locations to different authnetication services. Would need to check with Pro Services Daniel Rahman just to be sure :-) as I might've fudged a detail here, but at a high level, I've seen it done.

  • Peter Simpson thanks!

    I wasn't sure what a specific implementation would be like.

    The "Login with MSFT or Google" (NOT Facebook!) was one idea to simplify things for our clients.

    Another idea was if we had a central login mechanism. For ex, a client comes to our web site and there is a "Login to access all Jackson Lewis Services" button. Clients login there -- perhaps we would include the "Login with MSFT" button -- and then would be shown a list of services available to them -- like Collaborate, Home Grown Services and any other third-party services we license and make available to clients -- and then could log straight in to those b/c they have already been authenticated to our central login mechanism. I guess in a sense -- and I am not being very knowledgeable about this -- our firm's central login hub would serve as the IDP?

    The approach you mention above might be workable for a small number of large clients, but the fact that we would need to set this up per client would not allow it to scale and likely does not give us the type of centralization we are looking for.