Discovery Page Login Errors

[bliszewski]

Greetings,

Since we support different authentication mechanisms for Canvas, we use a Discovery URL pointing to a page on our university's site to help people navigate to the appropriate place to login. Linking to the different login URLs is simple enough, but one of the things that was missed in our initial implementation was login error handling. So now we're trying to add at least some indication if there was a problem and context to provide our support folks.

We know that on a login error, Canvas will redirect back to the discovery page with a `message` URL parameter containing a message the error.

We can even find some of these possible messages from the Canvas login controllers, e.g. https://github.com/instructure/canvas-lms/blob/master/app/controllers/login/saml_controller.rb

However, our developers are, rightly, concerned about just writing any URL parameter message to the official LMS login page for fear that it could be abused to post official looking messages or direct people to malicious URLs.

While they are considering their own solutions, I just wanted to ask how others are handling the login errors that return to Discovery URL, to ensure it is an actual message returned from Canvas?

[mzimmerman]

Hi @bliszewski 

As far as I know, any login errors would be displayed the same way whether you are using a discovery page or if the user is directly using the login URL for that particular authentication provider.  

If I set up a discovery page/service, and select an auth provider from the discovery page, and I don't have a working login/password for that auth provider, it is the auth provider that displays the error about the incorrect login/password.  If I can successfully log in through the auth provider, but there's no matching login name in Canvas, I get an error message from Canvas telling me there is no account for that login name, and a link try again, which directs me back to the discovery page--with no other messages displayed.

[bliszewski]

Hi mzimmerman,

That may depend on the authentication provider or other settings?

I can confirm an error message is automatically redirected to our Discovery URL when a person successfully authenticates through our SAML provider but either doesn't have an account or has a suspended account. I believe we also saw this when testing other providers (e.g. Apple), but that was a while ago and we don't actively use those at this time to test.

Specifically in this case it will return with `?message=Canvas doesn't have an account for user: ` and the same text can also be seen in the linked saml_controller.rb in Github (line 185).

I noticed that we did not explicitly set a value for the "Unknown User URL" but it has soft-filled our Discovery URL into that field anyways.

We have enabled Just In Time Provisioning for our SAML provider, which has greatly reduced these errors, but still occurs and can be reliably tested by suspending the user. We've also discovered that with the Provisioning, deleted users will receive a Canvas error and not be redirected. We assume this is because Users are only "soft-deleted" and therefore the Login ID still exists in the database, preventing a new user from being created. But that's a separate issue (though one I'm also interested to hear how others have managed if anyone does want to get into it).

[mzimmerman]

Hi @bliszewski 

In my experience, that "Canvas doesn't have an account for user: ..." pop-up message occurs when there is not a matching login name in Canvas, whether a Discovery URL is used or if the user is simply using the direct URL for the auth provider in Canvas.  So, that part is not really related to using a Discovery URL.

[bliszewski]

Our experience seems to be different. In my experience, there is no "Canvas doesn't have an account for user: ..." pop-up. Instead that text is sent back to the Discovery URL via a URL parameter and it is up to the that page, which is not a Canvas page, to do something with that "message" parameter to indicate why the user has found themselves back there.

A pop-up from Canvas would indeed be a more preferable solution than handling a URL parameter on our discovery page. I suppose we'll have to discuss with our CSM why you are seeing different substantially different behavior and whether they can enable this behavior for our instance.

[mzimmerman]

I've been testing different scenarios, but I see that I was not testing the one that you are using. 

I had been testing with a SAML IdP discovery service, and that's where I was getting the pop-up if there was no matching user login (just the same as if they'd gone directly to the Canvas URL for the auth provider).   

I was thinking that it would work the same way with a Discovery URL, but when I was finally able to test that, I see that I was wrong and what you mean--they just get bounced back to the Discovery URL.

That said, since the message parameter is coming directly from Canvas, based on information sent from the auth provider after successfully authenticating, so I'm not sure if there's anything risky getting sent back that might present an opportunity for the kind of redirect hack you're describing?

[bliszewski]

The message from Canvas itself is fine, the concern is validating that the message actually came from Canvas so that we can display appropriate information to the user.

For example, if we naively write the `message` parameter to some sort of alert box on the page, the page would be vulnerable to content injection.

I.e. he parameter from Canvas "?message=Canvas doesn't have an account for user: ..." getting dumped into some `alert("Canvas doesn't have an account for user: ...")` would be great. Exactly what we want even!

But someone else could share a link to our page, through an email or whatever, with "?message=Please visit evil.com/login to fix your account" which would then look like an official message from our university.

We've discussed looking at referers or other request headers and properties to try to validate that it was redirected from Canvas, but concerns remain that these can also be faked and abused.

Another considered approach was looking or the exact "message=Canvas doesn't have an account for user: " text and then displaying our own message instead, but since this is all managed Canvas side and different authentication mechanisms may return different messages (for example, the OAuth2 controller seems to return an OAuth error) there are concerns about actually being able to maintain this and provide useful information.

[mzimmerman]

Hi @bliszewski 

Since the SAML Discovery Service auth option seemed to work the way we wanted--throwing up a pop-up from Canvas saying specifically "Canvas doesn't have an account for user XXX", thought I'd try just creating a SAML Discovery Service auth provider, but just pointing it to a static HTML page with links to Canvas auth provider URLs, and it actually seemed to work.  You can put that same_idp_discovery auth provider as the first one in the list, and Canvas will still default back to it, and return to it after a failure...it's worth trying to see if you see the same results?

[bliszewski]

Just to make sure I'm following, you are adding an "SAML IdP Discovery Service" to the Authentication settings, but in the Discovery Service URL you are just putting a static page (e.g. the Discovery URL)?

A quick test of that just took me to generic Canvas "Page Error" with no specific mention or reference to a login error. But maybe I need to play with that more and set things up a little more approriately.

As for actually using a SAML IdP Discovery Service instead of just the SAML option, our SAML IdP doesn't seem keen on the idea so that may take some more work.

[mzimmerman · Accepted solution]

Yep, that's pretty much what I was doing:  putting a static Discovery Page URL into the URL field for a SAML IdP Discovery Service auth provider.  If I used the Canvas login link for that SAML IdP Discovery auth provider, it just took me to that static Discovery Page.  

It is just a static HTML page, with links to the specific Canvas auth provider URLs, so if Canvas is passing along extra information when it opens the discovery page, that pretty much just gets ignored.  From the discovery page, click the appropriate link for the auth provider that you want, and it takes you to the Canvas auth provider URL, which directs you to that auth provider/SSO.  

If there's a problem with that login credentials at the auth provider/SSO stage, the SSO window stays open with the error from the SSO.  If they successfully login through the SSO, but there's no matching account in Canvas, it throws up the "Canvas doesn't have an account for user XXX" pop up, and gives them the link to try again.

Beyond that, I don't really have any problem situations to try, since we're not doing auto-provisioning, but doing it this way pretty much just gives the user a list of Canvas auth provider links to try.