Discussion:
[Building Sakai] Can Sakai roles be mapped to LTI roles?
(too old to reply)
Ward, Lynn E.
2014-01-22 13:38:13 UTC
Permalink
Hi everyone,

I have a quick question about Sakai’s LTI implementation that I am hoping someone can answer. Is there a mechanism for mapping Sakai roles to LTI roles? We’ve received a report that the observer role in our course sites cannot access one of our external tool providers (Echo360). In Piazza and VoiceThread that observer role seems to have the same rights as students. In some other LMS platforms, there is an interface for mapping locally defined roles to LTI roles…wondering whether Sakai offers something similar. I’ve read through the LTI documentation in Confluence and haven’t come up with anything.

Lynn


==========================
Lynn Ward, Principal Systems Analyst
Instructional Technology Systems and Services
University Information Technology Services<http://uits.iu.edu/>
Indiana University
Information Technology and Communications Complex (IT 342K)
535 West Michigan Street, Indianapolis, IN 46202
Phone: 317-278-5713 E-mail: ***@iu.edu<mailto:***@iu.edu>
Stephen Marquard
2014-01-22 15:09:45 UTC
Permalink
Hi Lynn

I believe that is the use case expressed here:

https://jira.sakaiproject.org/browse/SAK-24185

Regards
Stephen

________________________________
From: sakai-dev-***@collab.sakaiproject.org [sakai-dev-***@collab.sakaiproject.org] on behalf of Ward, Lynn E. [***@iu.edu]
Sent: 22 January 2014 03:38 PM
To: sakai-***@collab.sakaiproject.org
Subject: [Building Sakai] Can Sakai roles be mapped to LTI roles?

Hi everyone,

I have a quick question about Sakai’s LTI implementation that I am hoping someone can answer. Is there a mechanism for mapping Sakai roles to LTI roles? We’ve received a report that the observer role in our course sites cannot access one of our external tool providers (Echo360). In Piazza and VoiceThread that observer role seems to have the same rights as students. In some other LMS platforms, there is an interface for mapping locally defined roles to LTI roles…wondering whether Sakai offers something similar. I’ve read through the LTI documentation in Confluence and haven’t come up with anything.

Lynn


==========================
Lynn Ward, Principal Systems Analyst
Instructional Technology Systems and Services
University Information Technology Services<http://uits.iu.edu/>
Indiana University
Information Technology and Communications Complex (IT 342K)
535 West Michigan Street, Indianapolis, IN 46202
Phone: 317-278-5713 E-mail: ***@iu.edu<mailto:***@iu.edu>
________________________________
UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
Ward, Lynn E.
2014-01-22 15:37:41 UTC
Permalink
Thanks Stephen. This is helpful.

From: Stephen Marquard [mailto:***@uct.ac.za]
Sent: Wednesday, January 22, 2014 10:10 AM
To: Ward, Lynn E.
Cc: sakai-***@collab.sakaiproject.org
Subject: RE: Can Sakai roles be mapped to LTI roles?

Hi Lynn

I believe that is the use case expressed here:

https://jira.sakaiproject.org/browse/SAK-24185

Regards
Stephen

________________________________
From: sakai-dev-***@collab.sakaiproject.org<mailto:sakai-dev-***@collab.sakaiproject.org> [sakai-dev-***@collab.sakaiproject.org] on behalf of Ward, Lynn E. [***@iu.edu]
Sent: 22 January 2014 03:38 PM
To: sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
Subject: [Building Sakai] Can Sakai roles be mapped to LTI roles?
Hi everyone,

I have a quick question about Sakai's LTI implementation that I am hoping someone can answer. Is there a mechanism for mapping Sakai roles to LTI roles? We've received a report that the observer role in our course sites cannot access one of our external tool providers (Echo360). In Piazza and VoiceThread that observer role seems to have the same rights as students. In some other LMS platforms, there is an interface for mapping locally defined roles to LTI roles...wondering whether Sakai offers something similar. I've read through the LTI documentation in Confluence and haven't come up with anything.

Lynn


==========================
Lynn Ward, Principal Systems Analyst
Instructional Technology Systems and Services
University Information Technology Services<http://uits.iu.edu/>
Indiana University
Information Technology and Communications Complex (IT 342K)
535 West Michigan Street, Indianapolis, IN 46202
Phone: 317-278-5713 E-mail: ***@iu.edu<mailto:***@iu.edu>
________________________________
UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
Charles Severance
2014-01-22 15:40:29 UTC
Permalink
Lynn,

While SAK-24185 is a valid use case, for me it has always been a low priority because tool providers seldom understand roles beyond Instructor and Learner anyways and things are pretty specialized.

My general approach is to send the *actual* Sakai role in this field:
ext_sakai_role=CIG Coordinator
This way if a tool really wants to get tricky they can look at the exact role instead of a mapping which can get confusing or be mis-configured.

Others might write the code and I would not be opposed to it - but I don't plan on implementing SAK-2418 - because it feels too "Rube Goldberg" to me.

/Chuck

On Jan 22, 2014, at 10:09 AM, Stephen Marquard <***@uct.ac.za> wrote:

> Hi Lynn
>
> I believe that is the use case expressed here:
>
> https://jira.sakaiproject.org/browse/SAK-24185
>
> Regards
> Stephen
Schauer, Christopher R
2014-01-22 23:10:19 UTC
Permalink
Hi Lynn,

We implemented configurable role mapping for an attendance tracking LTI tool we wrote last year. We needed a way for the instructor to allow other roles (e.g. TA, Grader) to take attendance. What we did was add a rolemap property for the LTI tool that contains a comma-separated list of values of the form '<sakai role>:<LTI role>'. The property can be added in sakai.properties or as part of the tool registration in IMSBLTIPortlet.xml. An example from our attendance tool registration:

<configuration name="imsti.rolemap" value="ta:TeachingAssistant,maintain:Learner/Instructor,access:Member,Guest:Learner/GuestLearner,Site Assistant:Instructor/GuestInstructor,Site Collaborator:Instructor/ExternalInstructor,Grader:TeachingAssistant/Grader" />

The mapped value will be used for the LTI role in the launch parameters and in the roster service. I will attach a patch to SAK-24185 with the changes we made and you can see if it will work for your use case.

-Chris

On Jan 22, 2014, at 9:40 AM, Charles Severance <***@umich.edu<mailto:***@umich.edu>> wrote:

Lynn,

While SAK-24185 is a valid use case, for me it has always been a low priority because tool providers seldom understand roles beyond Instructor and Learner anyways and things are pretty specialized.

My general approach is to send the *actual* Sakai role in this field:

ext_sakai_role=CIG Coordinator

This way if a tool really wants to get tricky they can look at the exact role instead of a mapping which can get confusing or be mis-configured.

Others might write the code and I would not be opposed to it - but I don't plan on implementing SAK-2418 - because it feels too "Rube Goldberg" to me.

/Chuck

On Jan 22, 2014, at 10:09 AM, Stephen Marquard <***@uct.ac.za<mailto:***@uct.ac.za>> wrote:

Hi Lynn

I believe that is the use case expressed here:

https://jira.sakaiproject.org/browse/SAK-24185

Regards
Stephen

_______________________________________________
sakai-dev mailing list
sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-***@collab.sakaiproject.org with a subject of "unsubscribe"
Steve Swinsburg
2014-01-22 23:31:44 UTC
Permalink
You might be able to use this feature:
https://jira.sakaiproject.org/browse/SAK-24186

This allows incoming arbitrary roles to be mapped to Sakai roles.

cheers,
Steve


On Thu, Jan 23, 2014 at 10:10 AM, Schauer, Christopher R <
***@txstate.edu> wrote:

> Hi Lynn,
>
> We implemented configurable role mapping for an attendance tracking LTI
> tool we wrote last year. We needed a way for the instructor to allow other
> roles (e.g. TA, Grader) to take attendance. What we did was add a rolemap
> property for the LTI tool that contains a comma-separated list of values of
> the form '<sakai role>:<LTI role>'. The property can be added in
> sakai.properties or as part of the tool registration in IMSBLTIPortlet.xml.
> An example from our attendance tool registration:
>
> <configuration name="imsti.rolemap"
> value="ta:TeachingAssistant,maintain:Learner/Instructor,access:Member,Guest:Learner/GuestLearner,Site
> Assistant:Instructor/GuestInstructor,Site
> Collaborator:Instructor/ExternalInstructor,Grader:TeachingAssistant/Grader"
> />
>
> The mapped value will be used for the LTI role in the launch parameters
> and in the roster service. I will attach a patch to SAK-24185 with the
> changes we made and you can see if it will work for your use case.
>
> -Chris
>
> On Jan 22, 2014, at 9:40 AM, Charles Severance <***@umich.edu> wrote:
>
> Lynn,
>
> While SAK-24185 is a valid use case, for me it has always been a low
> priority because tool providers seldom understand roles beyond Instructor
> and Learner anyways and things are pretty specialized.
>
> My general approach is to send the *actual* Sakai role in this field:
>
> ext_sakai_role=CIG Coordinator
>
> This way if a tool really wants to get tricky they can look at the exact
> role instead of a mapping which can get confusing or be mis-configured.
>
> Others might write the code and I would not be opposed to it - but I
> don't plan on implementing SAK-2418 - because it feels too "Rube Goldberg"
> to me.
>
> /Chuck
>
> On Jan 22, 2014, at 10:09 AM, Stephen Marquard <
> ***@uct.ac.za> wrote:
>
> Hi Lynn
>
> I believe that is the use case expressed here:
>
> https://jira.sakaiproject.org/browse/SAK-24185
>
> Regards
> Stephen
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-***@collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-***@collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-***@collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-***@collab.sakaiproject.org with a subject of
> "unsubscribe"
>
Ward, Lynn E.
2014-01-23 00:06:29 UTC
Permalink
I was under the impression that SAK-24186 was meant for situations in which Sakai is functioning as the tool provider (as, for example, when OAE was pulling in CLE tools via LTI), not as the tool consumer. for example. We have a custom roles like called librarian+, that has privileges more or less identical to a TA. Tool providers that recognize the TA role won't know what to do with a librarian+. I think Chris's solution is more along the lines of what we need.

Lynn

Sent from my iPad

On Jan 22, 2014, at 6:31 PM, "Steve Swinsburg" <***@gmail.com<mailto:***@gmail.com>> wrote:

You might be able to use this feature:
https://jira.sakaiproject.org/browse/SAK-24186

This allows incoming arbitrary roles to be mapped to Sakai roles.

cheers,
Steve


On Thu, Jan 23, 2014 at 10:10 AM, Schauer, Christopher R <***@txstate.edu<mailto:***@txstate.edu>> wrote:
Hi Lynn,

We implemented configurable role mapping for an attendance tracking LTI tool we wrote last year. We needed a way for the instructor to allow other roles (e.g. TA, Grader) to take attendance. What we did was add a rolemap property for the LTI tool that contains a comma-separated list of values of the form '<sakai role>:<LTI role>'. The property can be added in sakai.properties or as part of the tool registration in IMSBLTIPortlet.xml. An example from our attendance tool registration:

<configuration name="imsti.rolemap" value="ta:TeachingAssistant,maintain:Learner/Instructor,access:Member,Guest:Learner/GuestLearner,Site Assistant:Instructor/GuestInstructor,Site Collaborator:Instructor/ExternalInstructor,Grader:TeachingAssistant/Grader" />

The mapped value will be used for the LTI role in the launch parameters and in the roster service. I will attach a patch to SAK-24185 with the changes we made and you can see if it will work for your use case.

-Chris

On Jan 22, 2014, at 9:40 AM, Charles Severance <***@umich.edu<mailto:***@umich.edu>> wrote:

Lynn,

While SAK-24185 is a valid use case, for me it has always been a low priority because tool providers seldom understand roles beyond Instructor and Learner anyways and things are pretty specialized.

My general approach is to send the *actual* Sakai role in this field:

ext_sakai_role=CIG Coordinator

This way if a tool really wants to get tricky they can look at the exact role instead of a mapping which can get confusing or be mis-configured.

Others might write the code and I would not be opposed to it - but I don't plan on implementing SAK-2418 - because it feels too "Rube Goldberg" to me.

/Chuck

On Jan 22, 2014, at 10:09 AM, Stephen Marquard <***@uct.ac.za<mailto:***@uct.ac.za>> wrote:

Hi Lynn

I believe that is the use case expressed here:

https://jira.sakaiproject.org/browse/SAK-24185

Regards
Stephen

_______________________________________________
sakai-dev mailing list
sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-***@collab.sakaiproject.org<mailto:sakai-dev-***@collab.sakaiproject.org> with a subject of "unsubscribe"


_______________________________________________
sakai-dev mailing list
sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-***@collab.sakaiproject.org<mailto:sakai-dev-***@collab.sakaiproject.org> with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-***@collab.sakaiproject.org<mailto:sakai-dev-***@collab.sakaiproject.org> with a subject of "unsubscribe"
Ward, Lynn E.
2014-01-22 23:55:50 UTC
Permalink
Thanks, Chris. This is exactly the kind of approach I was imagining.

Sent from my iPad

On Jan 22, 2014, at 6:10 PM, "Schauer, Christopher R" <***@txstate.edu<mailto:***@txstate.edu>> wrote:

Hi Lynn,

We implemented configurable role mapping for an attendance tracking LTI tool we wrote last year. We needed a way for the instructor to allow other roles (e.g. TA, Grader) to take attendance. What we did was add a rolemap property for the LTI tool that contains a comma-separated list of values of the form '<sakai role>:<LTI role>'. The property can be added in sakai.properties or as part of the tool registration in IMSBLTIPortlet.xml. An example from our attendance tool registration:

<configuration name="imsti.rolemap" value="ta:TeachingAssistant,maintain:Learner/Instructor,access:Member,Guest:Learner/GuestLearner,Site Assistant:Instructor/GuestInstructor,Site Collaborator:Instructor/ExternalInstructor,Grader:TeachingAssistant/Grader" />

The mapped value will be used for the LTI role in the launch parameters and in the roster service. I will attach a patch to SAK-24185 with the changes we made and you can see if it will work for your use case.

-Chris

On Jan 22, 2014, at 9:40 AM, Charles Severance <***@umich.edu<mailto:***@umich.edu>> wrote:

Lynn,

While SAK-24185 is a valid use case, for me it has always been a low priority because tool providers seldom understand roles beyond Instructor and Learner anyways and things are pretty specialized.

My general approach is to send the *actual* Sakai role in this field:

ext_sakai_role=CIG Coordinator

This way if a tool really wants to get tricky they can look at the exact role instead of a mapping which can get confusing or be mis-configured.

Others might write the code and I would not be opposed to it - but I don't plan on implementing SAK-2418 - because it feels too "Rube Goldberg" to me.

/Chuck

On Jan 22, 2014, at 10:09 AM, Stephen Marquard <***@uct.ac.za<mailto:***@uct.ac.za>> wrote:

Hi Lynn

I believe that is the use case expressed here:

https://jira.sakaiproject.org/browse/SAK-24185

Regards
Stephen

_______________________________________________
sakai-dev mailing list
sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-***@collab.sakaiproject.org<mailto:sakai-dev-***@collab.sakaiproject.org> with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-***@collab.sakaiproject.org<mailto:sakai-***@collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-***@collab.sakaiproject.org<mailto:sakai-dev-***@collab.sakaiproject.org> with a subject of "unsubscribe"
Loading...