Is this possible In this case the
Is this possible? In this case, the advantage is that I don't need to keep track of AD groups for users. If our TS backend group configures users in ThoughtSpot, and sets up an AD Group for a user called jdoe, when jdoe logs in, he would get the TS AD Group in his Auth Token. If not...then I will need to ALSO register the AD group for jdoe in our App..which does not seem right.
16 Replies
Just to understand this more..
When you say "user auth token" you mean the token your front end gets from the BE/IdP when they log in ?
When I say User Auth Token, I mean the User Auth Token from the browser, not the Auth Token that we try to get from TS
SO our user uses a browser and logs into our application
Got it, that auth token is issued by your IdP right ? Which I guess would be Azure IdP ?
The nice way would be that: inside that Auth Token, I find the AD Group for TS
Exactly Azure
Then, we register TS SDK init() with callback to retrieve TS Auth Token. The the TS Auth Token is called by TS SDK, and at that time, we can pass our user AD Group
Ok now just curious, why are the AD groups different between what the user is supposed to have in your own application vs TS ? Cant they be the same groups ?
I guess they should, I would need to talk to our backend group. They told us: we used this AD Group for TS, record it somewhere ...but this is duplication because I don't want to put this AD Group in our user (db) just because it is coming from TS
They (backend group) basically configure the users that use TS ...
I feel the IdP should have the source of truth when it comes to what groups the user belongs to. TS should be configured to just follow those and sync with it.
If a user has groups A & B in the organization, they should have the same groups in TS. TS groups should not be different ideally
This way you can use the same fields from the "user auth token" which denote the true groups a user is in and pass it along to TS while auth.
Another question, are users also loggin in directly to full TS using SAML ?
One additional way, you can do embed auth is also using
authType: EmbeddedSSO that way you do not have to do any trusted auth setup, the IdP flow will happen inline within the embedded.I believe users using our Application should not already be logged in to TS. We don't want them to login separately. And the 'backend group' does not want to create an account (backend ) to each user
That is the reason for using auto_create=true
Got it, is TS configured to use Auzre IdP SAML at all ?
I need to ask them this question, they should know
I am guessing the answer is yes, but just pinged them, let's see what theu say
I would suggest this:
- Configure TS to use Azure IdP SAML.
- Use
authType: AuthType.EmbeddedSSO
This way you do not have to deal with tokens at all. This assumes that everyone trying to access TS has an Azure IdP creds already.I asked the backend group, and yes, they have configured it to use Azure IdP SAML.
I changed our client app from Trusted Auth to using AuthType.EmbeddedSSO and I tested, but:
-it works in desktop version,
-it does not work in iPad version.
For iPad, it keeps spinning in the iFrame, and cannot get the report to render.
A good doc is here, which agrees with what you have said, and I also agree with this:
https://developers.thoughtspot.com/docs/embed-auth
...but not sure what is happening in the iPad case...
Authentication
Define the authentication method in the Visual Embed SDK to authenticate users of an embedded instance.
This solution would make sense because in the case of AuthType.EmbeddedSSO we would not have to do any trusted auth setup... the IdP flow will happen inline within the embedded, as you said above
This is ipad safari or chrome ?
ipad edge (which is similar to safari, I believe)
laptop (macbook) with Safari also does NOT work
Only Chrome works
So not sure why AuthType.EmbeddedSSO only works on Chrome ...
Does your app have the same domain as your ThoughtSpot instance? Mac's and iOS will see your auth cookies as 3rd party and block them since AuthType.EmbeddedSSO is not "cookieless"