Hi - I’m setting up authentication for
Hi - I’m setting up authentication for an embedded TS Liveboard and trying to figure out a solution to authenticate the full range of users that will be accessing the feature. All users will need to be added to a group that will allow them to access the Liveboard. Accordingly, I am currently passing the following parameters in the api token request:
{ username, auto_create: true, secret_key: env.THOUGHTSPOT_SECRET_KEY, group_identifiers: [env.THOUGHTSPOT_LIVEBOARD_GROUP_IDENTIFIER], },This successfully sets up a first-time user and enables the embedded Liveboard which is great. However, we also need to manage authentication for users who already have an account. This will include: - app users who have already been authenticated via the above just-in-time provisioning - internal users who have been set up with an account, but have not yet been added to the Liveboard group - internal users who have been set up with an account and are in a range of groups such as Admin and Engineering So far it seems like there is no single authentication solution that will work for all of these scenarios. For instance, if a pre-existing user has Admin access, the above request body overrides that group access and replaces it with the Liveboard group. The auto_create parameter in such cases should also be set to false. It seems like I need to dynamically set the token request body based on the user properties, which in turn I would need to access via the /users/search endpoint. This endpoint requires bearerAuth though, which would first require authentication. I am therefore struggling to figure out where to go from here. This seems like it would be a common requirement for embedded TS features so I am wondering if there is a simpler solution.
4 Replies
You can fetch the bearer token for the admin and perform the /users/search API. This will give you all the properties of the user you searched for and then make another call to /token api depending on the results of the above call..
Does this approach not work for you?
I'm sure that will provide the solution we need, just wasn't sure what the standard approach would be for this. I'll get to work on that, thanks for your assistance!
Also you don't need to provide group_identifiers if not creating a user
Just search if the user is present, if not create the user with fetch call with groups you want and auto_create true. But if present just fetch token with auto_create false and no groups
Hi @ferg.rose:
Currently, the /api/rest/2.0/auth/token API endpoint supports JIT (Just-In-Time) provisioning only with the REPLACE logic. An enhancement is planned to provide greater flexibility by allowing both appending and replacing groups during token generation. However, this enhancement is scheduled for the 10.7 release.
Until, then the approach which is mentioned by @shikharTS can be followed to unblock your use-case.
Hope this helps.