More flexibility with deployment_id in Tsugi

[Charles Severance]

Hi all,

I was doing some testing between Sakai and Tsugi. I was teaching Sakai how to send multiple deployment_ids because we are working with a tool vendro that *really* needs fine grained control of deployment_id to do things like identify which department a launch is coming from. I got Sakai working sending more than one deployment id and I ended up crashing Tsugi.

I could make it work for one deployment_id - I could switch Sakai and switch Tsugi and it would work. But if I wanted Sakai to send several without changing the configuration on Tsugi it failed.

I could have added multiple tools on Tsugi, each with a different deployment_id and made it work- and for some use cases that wuld work. But what I really wanted was in effect fot Tsugi not to care about the deployment_id - but still use the right deployment_id on API calls. I wanted in effect, the ability to accept “any deployment_id” - a wild card.

I implemented this in master. All it means is that you can set deployment_id to blank (i.e. null) to tell LTIX.php to accept any deployment_id.

This wildcard is a new feature so I think that this should not break whatever you have working now.

But it might get some good flexibility for deployment - especially when an LMS is multi-tenant.

So if anyone wants to test this - particularly on single instance LMS’s like D2L, Blackboard, or Canvas - let me know - I have no access to any of these systems as admin so I have to depend on you to help me validate the new feature.

Cheers.

/Chuck

[Charles Severance]

Matt.

Thanks.  I like the UT Austin appoach .   A deployment_id is required and part of Dymamic registration bit keep life simple, accepting any deployment_id on a launch and handling registrations of new deployment_ids within a (iss, client_id) pair (if desired) is the right strategy.

On May 15, 2026, at 2:20 PM, Matthew Jones <matthe...@learnxp.com> wrote:

Seems like a good option. Most of the apps we've developed (mostly Django/Python) have either the option to trus all deployment IDs or to use a hardcoded list of specific ID's. These can either be added in an admin UI or in an env file depending on the app. (Newer all have more stuff on the Django Admin)

An interesting middle approach we saw was with the Laravel LTI library that used CeLTIc maintained by UT Austin did. They have an option for auto_register_deployment_id that just requires at least one hardcoded deployment_id but future deployment IDs for the tool on the same platform would be trusted. I've wanted to incorporate this into some of our other Python apps but have been fine with either accepting any or just adding the limited specific ones. On Canvas you can deploy to a root account, a sub-account or directly to a course, but I'd guess that 99% are added to an account for us, so they are limited.

Here is a ChatGPT discussion I had about all this stuff.

https://chatgpt.com/share/6a089c40-e50c-83ea-b0a5-47464fa11a4e

My next commit to tsugi will make any deployment_id in the tool be a “wildcard” at launch time.  Later if desired, we can move to a list of good / bad deploument ids that we accept that can be tweaked post launch if someone wants to charge multiple sub-client tenants differently.

This ne direction makes the LTI Issuer concept I put into Tsugi at the very beginning a wrong headed idea - it also meant that Tsugi could not do self-service LTI 1.3 keys.

So with that I will be deprecating and removing the lti_issuer table from Tsugi over the next few months.   As a first step, my next commit to Tsugi will run a quick scan of the lti_issuer and lti_key tables and let you know if the removal of lti_issuer would affect you.  This same check is done in the upgrade.php script so you will notice several places hopefully well before an auto conversion happens.  I attach the big warning screen shot.

If you go into admin and *don’t* see this it means you never used issuers and so the removal will be a no op.   If there are issuers that have 1 and exactly one key - the conversion will be simple and perfect.  If there are issuers that have two keys, it might be a problem.

Hopefully you will upgrade and not see this message.

You can also run this and if it is zero - you don’t have to do anything.

select count(issuer_id) from lti_key where issuer_id is not null; 

If it is zero you never used the feature and will not notice anything.  If the count is non-zero contact me - I don’t tyhink I ever used the feature so WHile I can test it artificailly I won’t know for sure unless you test it.

I have this info in a github issue  https://github.com/tsugiproject/tsugi/issues/226

Comments Welcome.

/Chuck