Maintaining user identity from SSO, within web AMI for shotgun API (and more)

Pipeline Integrations
, ,
1

Hello, this is my first post here and hope to find some help, or even simply some context.

I’ll try to be as specific as I can, to try and have more targeted responses. We have SSO setup for our shotgun installation. Our org is the identity provider. Our software within our org also uses that same provider. We are using AMIs with a web URL (https), that will show some UI, communicate back to shotgun (through either the REST or Python APIs). Though we also need to call to other systems within our ecosystem, that are also behind our SSO.

So the question within that context is:
Is it possible to do 2 things…

  1. Communicate back to the shotgun API where shotgun recognizes those requests under the same identity of the user whom clicked the AMI in the first place?
  2. Is it possible to use some context specific to the SSO, that was most likely issued at login, and forward it on so it may be used for other systems?

Even if what I described is not possible, what are my options here? Any recommendations? Is there any work that is planned or in-progress that would support something like this flow?

Thanks

2

Hey Jimi,

I’m just a member of the community, but have you looked into the lite payloads on AMI? If your target service for your AMI has an API key; it can look up the event with a bunch of metadata on the event that your lite payload passed. That might let you do what you are looking at doing.

3

Hi Jimi,

A bit of background infos regarding Shotgun’s integration with SSO.

We use SAML2, and rely on the IdP to connect to the authentication callback with a signed payload containing the username, firstname, lastname and email of the authenticated user. When Shotgun receives that information, it creates a new session for the user and they can happily interact the application. But nothing SSO related makes it out of the server process or is reported back to the client.

Once that loop is complete, there is no further interaction between the Shotgun server and the IdP.

Shotgun never talks directly to the IdP or vice-versa. All communications use the client application as the proxy to relay the signed (and potentially encrypted) data back and forth.

The TL;DR version : the Shotgun web Application does not have access to any SSO related information that it could the re-use for other purposes. It is actually not even aware that SSO is being used.

The browser used to access Shotgun (and authenticate to the IdP) will save cookies from the IdP once the user is authenticated. At a later time, when another app redirects the user to the IdP, they will likely not need to re-enter their credentials thanks to those cookie (but that will depend on the IdP settings). So redirecting (or opening a new tab) onto another one of your application should work (I guess this is what you are already doin to get into Shotgun from your custom web apps).

To answer your 2 questions, I need some clarifications as I am not sure I understand exactly what your setup is. Are you building a standalone app to communicate with Shotgun (via either the REST or Python API), or a web based app (which only has the REST API option) ?

-Patrick

4

Thanks for your response. Sorry I might have been assuming something wrong, in that the Python API was web based as well, but I realize now, it’s probably described the way it is because it’s a native application API. Either way, to avoid confusion, I’ll just say it’s a web application that communicates back to shotgun and other internal services through REST, and its purpose is to serve Shotgun AMI(s).

5

The Python API is our older solution to interact with Shotgun. It encapsulate requests using our custom query language. Purely data driven, no GUI.

The REST API is our current language agnostic solution.

While the way to use them does differ, they share the same authentication possibilities:

  1. using a script name and API key pair
  2. using a username and password pair
  3. using a session token (this is Shotgun specific, and you can see one such token in your browser if you look at your Shotgun cookies)

Script Name / API Key : these are meant to be used for service-related tasks. Not really appropriate for regular user interaction with Shotgun.

Username / Password : not possible on a SSO-using Shotgun site (see the gory details here ).

Session Token : the cookie used by Shotgun is tagged as Secure and HTTP only, so your JavaScript code will not be able to get to it.

So for a purely web based application, I do not see any current path at this time for you to make it work without first obtaining an existing and valid session token (via copy/paste or by using an external application).

In our native applications (Shotgun Desktop, Shotgun Create and RV), we leverage Qt’s WebEngine to lead the user into a login flow (details in the article I cited up), and simply get the session token out of the cookie jar. We then turn around and use that token to initiate a connection to Shotgun.

I am trying to think of a way to make things work for you, and unfortunately I cannot think anything that is not a hack and that does not require a native app to bootstrap the process.

Sorry.

-Patrick

6

I noticed there is something called a session_uuid in the POST data sent to the AMI, is - or can - that be useful for anything?

7

Also just wanted to make sure I’m on the same page as what you were saying. Would it be the right assumption that if the domain that I was accessing within the AMI was one that was shared by a cookie minted at login by the SSO provider, the cookie should easily be used to continue the session and identify the user.

Though this doesn’t solve being able to communicate back to shotgun as the current user right? So confirming that, at best right now, I could continue the internal SSO session as described, but any action back into shotgun must be service based, and can’t be identified via a user, and that’s because there’s no real way to access / use the shotgun session token outside of a native application.

This all being said, could I also ask if this was a self hosted shotgun installation (it’s not), could the domain be shared across shotgun and the AMI web application, and hence the session token be shared, and the original goal could be possible?

8

Good evening Jimi,

Regarding the session_uuid, this is used to uniquely identify a specific browser tab. No relation with the authentication process.

Regarding the same page, the domains of the different services does not matter. You could have shotgun.domainalpha.com, yourapp.domainbeta.com and idp.domaincharlie.com, each defining their own cookies and individual sessions (which makes things confusing sometimes). Once you have authenticated at the IdP, it will generate cookies for itself so that later on when you are back on it, it will be able to tell that are already logged in, and who you are.

Shotgun has its own set of cookies that are set once authenticated. If you are not, or your session has expired, you will be pushed to the IdP and lead back to Shotgun with a payload to identify you. Shotgun then issues you a session. The only information shared between the IdP and Shotgun is the authentication payload (contains you first name, last name, email and shotgun login). Your web application has probably something similar. How your IdP Identity maps the the application identity is, well, application-specific.

I am definitely not an AMI expert (actually, I know very little about those), so please bear with me.

If I understand, in one of your use case, the data flow is like: Shotgun web app -> via an AMI -> your web app -> data back to Shotgun

For the your web app part, I would assume that if the user is not already logged-in, you would redirect the user to the IdP. Given that this would be a POST call, I believe that you will have to save that to a session before redirecting the user to the IdP as it will not be posted back. In short, if your user is already logged into Shotgun from your IdP, and assuming they are not logged into your app, then going through the IdP will not require the user to type credentials. The IdP cookies will let it know that all is good, and the browser will be redirected back to you application to complete the login and be issued a new session.

For the data back to Shotgun, one solution would be a server-to-server call between your server and Shotgun. You would need to use a Script Name / API Key with admin and sudo privileges, so that your server could connect back Shotgun to do actions on the behalf of the user.

The AMI payload contains the Shotgun user login info, in order to setup the sudo_as field.

Doing anything on the frontend side of your app with a REST API calls back to Shotgun will likely not be possible without resorting to exposing sensitive Script Name / API Key information which would be easy to steal.

So I strongly recommend having your server connect to Shotgun directly. Being self-hosted or not should not change things I believe.

Hoping this is semi-clear and helpful.

-Patrick

2 Likes
9

Patrick, that is better than semi-clear and helpful. For one is it confirming a direction I was considering, and illuminates how to do other things I had already written off as impossible for now. I think I have a path forward, thank you.

11

Realized that needs to be a new thread

12

@patrick-hubert-adsk regarding the new shotgun release: 8.21.6983 release

How does that affect the sudo_as scope in scripts?
I wanted to be able to use the sudo_as scope for everything, but does this change that?

13

Hi @jimi

Yes that new flag will prevent specific users from being the target of a sudo_as, in the GUI and in scripts.

Using sudo_as all the time in the context of user interactive session seems a bit dangerous. Are you using a Script Name / Api Key combo to do those sudo_as calls ?

In my programmer-who-does-not-work-in-a-production-environment’s mind, sudo_as is meant to be used by back-office (and server-side) processes (where the name/key are well protected), or by an admin to trouble-shoot some user’s issues.

Having a script or a user being able to do a sudo_as action is a potential security risk.

-Patrick

14

Sorry I was using “script” as “server”, because that’s how I’ve seen terms used around shotgun, i.e. a “client id” is the same as a “script key”. Yes, all this is in regard to server side.

The question is more about whether the server setup (always calling sudo_as) can continue to function with this change as it was originally intended intended? Which was to correlated users actions back to shotgun, where they trigger AMIs. Or will it now break for users who have this checkbox deselected? If it is the latter, what can/should we do?

15

Thanks for the clarifications.

The new flag will impact your current workflow for users who do not have this checkbox selected.

By default, only admin users have that option turned off.

So if you do not change any of the currently set values, I would suggest that:

  • admin users be used only to perform admin tasks interactively in Shotgun, never via scripts,
  • do not turn off the Admins Can Perform Actions As flag for regular users,

The intent here with this flag is to increase security and enforce best-practices.

-Patrick