The Future of Instructure Technology with Global Identity Service

[MichaelLysaght]

As we approach InstructureCon 2025, I am reflecting upon the progress we’ve made since last year when we promised to modernize the Instructure platform to ensure that we can innovate faster and deliver the capabilities you need to keep pace with the changing landscape of education. The pace of change in the education landscape has not slowed and our commitment to modernizing the platform is steadfast. 

Today, I’ll update you on some major progress on one of these projects: the Global Identity Service. And offer details of what you can expect over the next 12-28 months.  

The Vision for a Global Identity Service

The Global Identity Service is a key part of our platform's future and will simplify how you interact with all Instructure products, starting with Canvas and expanding to all Instructure products. Imagine:

• Educators logging into both their teaching and professional development areas with just one username and password.
• Administrators easily managing users for connected apps in one centralized place. 
• Students gathering all their learning achievements across connected accounts into a single place.
• Managing users across Canvas Trusts and Consortiums becomes easier with centralized identity management.

These are just a few examples of how we envision this service could save time and add value. While they are not on our short term roadmap, the Global Identity service makes this vision a possibility in the future.  By enabling a single login across our product portfolio we're paving the way for:

• Smoother integrations and easier scalability thanks to standardized authentication.
• Quicker updates, more organized data, and the introduction of AI-powered features.
• Stronger security measures and simplified system administration.
• More insightful reporting and analytics with a unique user ID

Delivering a Global Identity Service

Our guiding principles for delivering the Global Identity service are to unlock added value and increased security for our customers while ensuring the least amount of disruption to your end users. 

To minimize any risk of disruption, we’ve done extensive testing on Instructure hosted sites such as Free for Teacher and with early adopters in a variety of regions and configurations. By the end of July, when we slowly begin redirecting logins through the identity service, we will have thoroughly tested at scale.  

Additionally, we have built in fail-safes in the event of any hiccups to ensure there are no disruptions for students during the back-to-school window.   Finally, we are taking an incremental approach to delivery, making sure that we have validated checkpoints for migration and consolidation. 

Change management Expectations for your Institution

At every step along the modernization process, we strive to minimize disruption and change for your institution.  To that end, we have taken steps to minimize any additional actions that will be required by admins, and where changes are needed, provide options for when and how to make those changes.  With that in mind, here is a big picture view of what to expect over the next 12-18 months to make global identity and high level details of what, when and why there will be change. 

• Already, we have sent out a new subprocessor notification, which includes  the benefits of deploying a new service provider, along with technical references. You can find out more in the Community.
• Currently, a login UI with a more accessible UI is available as an option now, and can be enabled at your convenience in both Beta and Production environments. More details on the new login UI can be found in the release notes.  This will be automatically turned on for all customers in July 2026.  
• Starting in July and throughout the next several months, we will begin redirecting current login workflows on the backend to go through the new identity service.  You will receive notice in advance of the redirection and will have an opportunity to validate the back-end change before the re-direction 
• After a period of successful logins at scale for your Institution, we will make available tools to help reconfigure any current SSO implementations to point directly to the new service. Expect  more information on this later this year. 
• Over time, as we release enhancements to identity and user management tools, we will make them available to admins. We will continue to communicate these via release notes and Community posts as we get closer to release.  
• If you have questions, please refer to Frequently Asked Questions or contact your customer success manager. 

We are excited to continue modernizing our technology and look forward to the benefits this will bring as we build a more flexible, seamless, and secure platform.  I look forward to meeting many of you at InstructureCon 2025 where I’ll share more about Instructure’s tech modernization plans and appreciate hearing your experience and ideas.

[dbrace]

Hi @MichaelLysaght,

In the FAQ document (https://docs.google.com/document/d/1vzEhJkLUBMTCWGeZH2nQErEGTH6EWcRIEIJxO4Rb-2A/edit?usp=sharing) in the "Technical & Integration Questions" section, there is a question (Are there any network or firewall configuration changes that might be required on our end to ensure seamless connectivity with the new identity service?) that I believe might be missing a link.

Is the text "Canvas Domain, Email, and Server Management" supposed to be a link?

-Doug

[tdw]

Hey @dbrace good catch, yes!  It's supposed to link to this guide: https://community.canvaslms.com/t5/Canvas-Resource-Documents/Canvas-Domain-Email-and-Server-Manageme....  I'll make sure the FAQ doc gets updated.  Thank you!

[LakenyaWoolridg]

Thank you 

[IanGoh]

Michael,

We recently started noticing extra CD2 Pseudonym records for our users (this week).  They have a user_Id GUID and authentication provider = 204 -- which we looked up via API and it said it was "instructure".

Are these 2nd Pseudonym records with the "instructure" auth provider due to this change? Or due to users logging into a 3rd party site (but using our auth) e.g., maybe the community?

Thanks

Ian

----

UPDATED: It's on the Known Issues page now https://community.canvaslms.com/t5/Known-Issues/OPEN-Remove-Identity-Service-Logins-from-Pseudonyms-...

[LakenyaWoolridg]

Thanks

[IanGoh]

RE: "You will receive notice in advance of the redirection and will have an opportunity to validate the back-end change before the re-direction."

We just got notice today "In 10 days, on November 30, 2025 we plan to begin redirecting your authentication traffic through our new system".   Given that we have a holiday coming up, it's really only four working days notice.

Ian

[DavidSchlater]

The login with the manual test link that was sent seems to be a bit slower than our  current SSO. Are others finding this?

Also the default login page that ends /login/canvas seems to flash in the background twice during the authentication process. We never send any customers to that default login page, so we never want them going there. The SSO works, but why pause and show that other page in the background?

[cpowell2]

Similar result as @DavidSchlater with my institution "Manual Testing URL," but the /login/canvas page briefly flashes once before showing hte normal login page.

https://d.pr/i/IAvQ0P

...for an animatedGIF of the visual experience. Hopefully this will be addressed or fixed before December 1.

Chris Powell

WWU Canvas Admin

[dbrace]

Hello @IanGoh, @DavidSchlater, and @cpowell2,

I would recommend that you reach out to Canvas Support directly and explain your concerns and show them your experiences. After that I would recommend:

1. emailing your CSM
2. provide your CSM with your Canvas Support case number
3. request that the date of the authentication cut-over be postponed so that you have more time for testing with Canvas Support and to make sure that the process goes as smoothly as possible

-Doug

[anson-henthorn]

The only difference I've found in the SAML AuthnRequest message to our IDP is the addition of a ForceAuthn="true" attribute on the request, which forces the IDP to ask the user to enter their credentials again, even if they already have an active SSO session with the IDP.

However, this is a substantial enough change that end-users (students/faculty/etc) will notice.  Our users tend to login to our University Portal first via SSO (complete with MFA, etc), and then click on the various apps they wish to access (Canvas, email, registration, etc) without having to login again (i.e. "Single" Sign-On).  This change as-is would make our users login again just because they clicked Canvas from the portal.  IMHO, this should be an option that could be disabled on a per-institution basis, since such security requirements could be managed from the IDP-side with proper session timeouts, application preferences, etc.

With the short timeframe over a holiday weekend, I doubt there will be enough traction to get this changed before launch, but if enough people bring it up, hopefully it will.

Cheers,
-Anson

[SarahBlanton]

Like @DavidSchlater , the native login screen comes up twice during logins via our SAML configs.

And I will reiterate that the timeline on this is outrageously short. In the FAQ it states that we would have a 10 day notification. I stupidly took this to mean 10 working days, which is still too short given the user UX login experience change we are seeing.

Instead of 10 days, due to the holiday week, we got 3-4 working days, and for most of those, our students, instructors, and some of our admins will be out of the office taking vacation time.

@anson-henthorn Thanks for noting that you are being forced to re-login when using the test URLs. I have checked that in our environment and I find the same thing. Even if I am already logged into Canvas, if I hit the test login URL, it forces me to log in again. 

[mzimmerman]

We are seeing that auth providers configured using InCommon metadata (IdP Metadata URI : urn:mace:incommon ) are getting an "Auth provider not found..." error, so it looks like the new service doesn't know how to pull from InCommon.

For the other auth providers, we use EPPN (eduPersonPrincipalName) as the login attribute--something that is probably not all that unheard of in higher ed--and are getting a "'eduPersonPrincipalName' not found in returned attributes" error, so the new service is not passing along all of the attributes that it gets from our IdP.

I have opened a ticket.

[IanGoh]

I think to summarize issues reported so far

1) 10 days notice -With the holidays and weekends, it's really only four working days to test.

2) those using inCommon Shibboleth - "'eduPersonPrincipalName' not found in returned attributes

3) extra, brief redirect/ hop through a Canvas-local login page

4) forced to re-login when using the test URLs e.g., if you are logged into a portal (or even Canvas), then paste in the test SSO URL, you are asked to login again.

[MiroslavLulic]

Thank you, Instructure, for the notification about the Global Identity Service deployment starting December 1st.

We appreciate the incremental approach, but we must strongly echo the community's concerns and request an immediate postponement of the deployment.

Critical Risks We Are Seeing:

1. Inadequate Notice: The timeline provides only four effective working days for testing and preparing user-facing communications for a critical login change. This is insufficient change management for higher education institutions.

2. Shibboleth Failure: The reported issue where the 'eduPersonPrincipalName' attribute is not being passed for InCommon Shibboleth users is a critical failure point that must be resolved prior to rollout.

3. UX Disruption: The added redirect/hop and the forced re-login experience will cause significant user confusion and overwhelm campus support desks.

We urge Instructure to postpone the launch until technical prerequisites (like the Shibboleth attribute issue) are fully vetted and institutions have been given a minimum 30-day window for proper testing and communication preparation in the new year.

[herbert_serrano]

This is an extremely inappropriate time to implement something as essential as authentication/login. As many have already stated we have a major US holiday approaching, but we are also about to begin the finals period. I know the plan is to start with 1% of users to test this, that is ~400 users at my campus. 

Is it necessary to RUSH this for December 1st? What is the justification to implement this now? Because the benefits provided are not a reason to do this NOW. 

I am aware that this will be beneficial in the long term, but this would be something best done with more than a couple days notice and it would be better AFTER finals period. 

[david_taylor]

As others have indicated, this is TERRIBLE timing.  We just got the email, next week we are out, and then December 1 is the first day of classes after the break.  You couldn't have timed it any more poorly if you'd tried.  We are getting an error on the test link provided, so it WILL break access on December 1 if it is not corrected.  We are seeing the "eduPersonPrincipalName" issue others have reported.  We've notified our CSM and opened a support ticket with all of the relevant information.  But as I said, if this doesn't get resolved COB today, this is going to be a major problem for our campus given the holidays.

[ahess4]

My other post was deleted or being moderated, so I'll try again...

The attribute eduPersonPrincipleName IS in the SAML response from login.instructure.com for us, but we still get the EPPN not found in attributes error. I had included a sanitized example, but maybe that's why the post is not showing?

The other concern I mentioned is our IdP encrypts the SAML response. Instructure is now taking that encrypted response, decrypting it and passing it as plain txt in their SAML response.

(Hopefully this post appeases the heavy-handed moderator gods...)

[mzimmerman]

Upon further testing, it looks like the new service does not pass "friendly names", so "eduPersonPrincipalName" is not passed but "urn:oid:1.3.6.1.4.1.5923.1.1.1.6" is...

[ahess4]

The Friendly Name is in there for our response from login.instructure.com (that is not a SAML response you see below moderators, move along)

<saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" FriendlyName="eduPersonPrincipalName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" x500:Encoding="LDAP" > <saml:AttributeValue xsi:type="xs:string">

But still getting EPPN not in attributes error. 🙃

[DGottwalt]

I also am one that has questions about the time. Not only this but the fact that the community is going to be put into a read only state tomorrow and moving to another platform? What if there are issue that need to be discussed and cannot be due to being read only in the community?

[mzimmerman]

@ahess4 , I switched login attribute in the auth provider setting to "urn:oid:1.3.6.1.4.1.5923.1.1.1.6" and the test link started working, so there's *something* about the friendly name not being passed, or at least not being recognized...

[DGottwalt]

Can you explain how you are going to point 1% of our users to this change?  With finals coming up in December I agree the timing of this change seems poorly thought out.  What if things don't go as planned and students have issues logging in and with the community being turned to read only after tomorrow that sounds like a recipe for trouble.

[ahess4]

I was able to replicate @mzimmerman . It does work with the urn. But for us, the Friendly Name is clearly in the response. I looked at our IdP response and compared with Instructure's:

Our response (works with Friendly Name):

<saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string" >[redacted]</saml2:AttributeValue>

Instructure's response (does not work with Friendly Name):

<saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
FriendlyName="eduPersonPrincipalName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
x500:Encoding="LDAP"
>
<saml:AttributeValue xsi:type="xs:string">[redacted]</saml:AttributeValue>

The namespace is different and there are a couple of different attributes.

(Please moderators, don't get delete happy. I CLEARLY redacted identifiable information. I made it all ugly so it doesn't look like XML. What more can I do?)

[ahess4]

I did some more testing. Using other attributes works using the FriendlyName. Only eduPersonPrincipleName doesn't work with the new authentication system. For example, this attribute worked with either the Name or FriendlyName:

<saml:Attribute Name="urn:oid:2.5.4.5" FriendlyName="serialNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue xsi:type="xs:string">[redacted]</saml:AttributeValue> </saml:Attribute>

I was thinking maybe the new authentication system doesn't respect FriendlyName, but that is not the case. It looks like it is specific to EPPN.

I guess we could switch over to the URN before they roll this out to prevent interruption, but we shouldn't have to. Also, if this is broken, what else is?

Judging by the response to the eduPersonPrinicpleName error, I'm guessing there is a rather large number of institutions using this attribute and referring to it by the Friendly Name.

(Moderators, you have been nice so far, only making that bad initial decision. I forgive you. I implore you to continue with this kindness.)

[IanGoh]

Good news, we've heard "The (hot)fix for any issues related to 'eduPersonPrincipalName' not found in returned attributes has been completed and deployed to production. Customers who were experiencing this issue can retest their manual links."

[DavidSchlater]

I have a ticket in - 13277125 - about the flashing screen redirect/hop and ForceAuthn request. In our case we are not using the eduPerson/Shibboleth attributes. We are sending over claims with the default Microsoft claim namespace/prefix. The login works, but it is not pretty.

[KNGoh]

Throwing my cap in on the poor timing and communications. This change is happening in the midst of my institution's ongoing finals. We need an option to delay this till a more opportune timing.

[dbrace]

Hello @KNGoh,

If you have not already, please create a support request and request that your cut-over be delayed. After doing that, contact your CSM.

-Doug