[Building Sakai] LTI mapping for Sakai roles

Charles Severance csev at umich.edu
Tue Jul 15 18:13:56 PDT 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140715/14fbdea3/attachment.html 


More information about the sakai-dev mailing list