sis_login_id

[Brent Putman]

On 8/23/21 3:11 PM, Cantor, Scott wrote:
> On 8/23/21, 2:48 PM, "users on behalf of IAM David Bantz" <users-bounces at shibboleth.net on behalf of dabantz at alaska.edu> wrote:
>
>> A newly licensed vended service Is requesting I release “sis_login_id” attribute. Is this more than a blinkered
>> “We’ll make it up as we go along” integration policy?
> No, but in their defense, that's an awfully specific semantic. Not even clear what it would mean in a world where most SIS systems are really long past doing direct authentication so what would such a thing even be?


Fwiw, that is exactly the name of a field on a Canvas LMS user account 
object.  Its value is how Canvas matches users when doing authN into 
Canvas using an external mechanism, e.g. via SAML SSO. I.e. it's how it 
maps from inbound SAML to a Canvas user.  (Its name follows the 
convention of many other attributes on various object types related to 
external identifiers used in import of data from SIS or other external 
sources, like sis_user_id, sis_course_id, etc.)

So if this app has some aspect of integration with the Canvas LMS, then 
probably they want that attribute so they can then lookup the user via 
the Canvas API, or something like that.

I agree, for all the reasons mentioned, that the vendor is being lazy, 
and they should be the ones mapping a standard SAML attribute to use 
for the app-specific case, rather than making the IdP send a 
non-standard attribute like that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210823/623fcf06/attachment.htm>