HighQ and SSO

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

    Mark Salamon

    The 'Login with other' use-case is ultimately: you have a web app that requires a user signup and you want to delegate that to something more established because ultimately, entering your (for instance) Google login again is less of a PITA than filling out a new long form.

    In the context of a webapp integration with our product, the bonus here is that if you leverage a pre-existing package/module/whatever for this type of thing, you generally also happen to get the token management side of things taken care of. Most web app frameworks will have something which easily lets you surface a 'login with...' button on a page, and then they'll do the Oauth dance for you under the hood. They then hit a 'get user details' api endpoint and you have an authenticated session in your integrated app, a user account persisted to your DB and also a token and its associated details. This is whats going on when you 'login' to HighQ Drive (approximately).

    I have done this, but it only makes sense if you are building webapps where you want your users to be 1:1 with their associated account in Collaborate.

    I think its fair to say what you are describing its building your own IDP plus a bit more (IAM?), because you want to both have other apps delegate the authorization of users to your system, but also provide those users with a jumping off point to all apps to which they have access! It would be an incredibly non-trivial thing to build from the ground up and I wonder if those are two different use-cases which are potentially bad to mix?

    The most complete (and open source) tool for this type of thing that I can think of would be Keycloak, but I am legally obliged to point out that this isnt a reccomendation and I will stop typing now as I am not a developer :D !