Restrict pulling additional attributes from authentication providers

Idea created by Tom Rosenberger on Jul 31, 2018
    Open for Voting
    Score4
    • Casey Rowley
    • Lillian Shafer-Lahnum
    • Abi Johnson
    • Tom Rosenberger

    At my institution, our actual email addresses are 123@mail.XYZ.edu (due to network architecture that cannot be changed) but our users don't use that format. Instead, they use an alias, 123@XYZ.edu. That is what they know, that is what they type, that is what they tell their friends their address is. Most of our systems that are secondary to the SIS are provided with the 123@XYZ.edu version of the address when fed data from the SIS. This is true for Canvas, where we send username "123" and email address 123@XYZ.edu. We send this because that is the format that people know and use. Authentication uses LDAP, which checks for the username, not the full email address, so all is well...

     

    ...except for one thing. When users log into Canvas, Canvas sees 123@mail.XYZ.edu as the email attribute in LDAP (even though we didn't tell it to look at that attribute) and steals that data (because it thinks it's being helpful). Now, the user's Canvas account has two address: 123@XYZ.edu (set via SIS) and 123@mail.XYZ.edu (stolen from LDAP).

     

    This is problematic because a) the users are confused and troubled by the presence of the second address in their notification settings page, and b) LTI providers may duplicate user accounts (on their side) for people who have changed their default address in Canvas (which we cannot restrict them from doing). For LTI providers whom we pay per user, this causes a licensing issue.

     

    I would like the ability to control what attributes are read when Canvas authenticates externally. And, I would like the ability to restrict users from adding additional email addresses or from changing their default address. I realize these are separate requests but the backstory and rationale are the same.