[Building Sakai] LTI mapping for Sakai roles

Jim Mezzanotte jmezzanotte at anisakai.com
Wed Jul 16 08:34:45 PDT 2014


Thanks again--this is all good to know.

Best,
Jim

On Tue, Jul 15, 2014 at 9:13 PM, Charles Severance <csev at umich.edu> wrote:
>
> On Jul 15, 2014, at 4:06 PM, Jim Mezzanotte <jmezzanotte at anisakai.com>
> wrote:
>
> Thanks Matt and Dr. Chuck! And sorry, I should have been clear--I'm
> talking about Sakai as consumer.
>
> I was also wondering about the inconsistency noted in
> https://jira.sakaiproject.org/browse/SAK-26259. Looks like there's a
> patch so ServiceServlet.addRole() method also checks for "site.upd"
> permission and not site maintainer role. I'm not sure what the current
> "inconsistent results" are?
>
>
> Jim - This does need fixing and the patch in SAK-26259 looks good - I will
> double check it and commit.  The designated "maintain" role does not have
> site.upd is rare.
>
> So unless I've got this wrong: the role passed in "ext_sakai_role" is
> the actual role of a particular user accessing the external service
> from within Sakai?
>
>
> Yes.  Whatever string you see in Sakai ends up in this ext_sakai_role.
>
> But although the external provider has this
> information, role mapping is only handled by the site.upd/maintainer
> role methods?
>
>
> The logic to compute the *standard* LTI "roles=" value is based on site.upd
> logic - the ext_sakai_role is there as a safety net and is not portable
> between Sakai and non-Sakai launches.
>
> There is one tweak to the "roles=" value here:
>
> https://jira.sakaiproject.org/browse/SAK-24128
>
> If someone is a System admin doing the launch, they get
>
> roles=Instructor,Administrator
>
>
> /Chuck
>


More information about the sakai-dev mailing list