[Building Sakai] Connect to Sakai through oAuth

[Aaron Zeckoski]

> - The OAuth code (filter, tools, service, api) is added to the core
> build and deployed as part of the standard
> - /access and /direct both have the OAuth filters added.
> - The filters are updated so they are enabled/disabled by a sakai property.

The TCC discussed doing exactly this earlier today so it seems we are
in agreement.
-AZ



On Thu, Jun 14, 2012 at 12:41 PM, Matthew Buckett
<matthew.buckett at oucs.ox.ac.uk> wrote:
> On 8 June 2012 14:44, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>> That doesn't seem difficult to me but I'm not trying to find extra
>> work to do for myself. I'm just trying to make this easier for the
>> community to use your stuff. If you are OK with them always patching
>> files in tomcat or patching files and rebuilding and redeploying tools
>> in order to use Oauth then I guess that's fine but in my experience
>> that means a lot of people will simply not use this.
>
> OAuth is most useful when you have a application (desktop or other
> website) which wants to access Sakai as a user, but you don't want to
> give that other application the users credentials. The OAuth filter
> also has the advantage of allowing a limited set of permissions to be
> granted to the authorised application.
>
> At it's core the OAuth request filter sets the principal associated
> with the current request so that the Sakai request filter works as
> normal. As Colin said the only places that this filter makes sense are
> /direct and /access (two core tools) so the only tools that need
> patching are core ones. You might want to add OAuth support to
> /portal, but I've yet to see a example of why this would be a good
> idea.
>
> I don't think any tools need to be aware that a request was
> authenticated through OAuth.
>
> Keeping the OAuth code out of RequestFilter means that the OAuth code
> can be kept out of the kernel. The OAuth services don't need to be
> part of the kernel and they aren't very useful for other
> tools/services. They obviously would need to be deployed into tomcat,
> but this could be done as part of one of the other assemblies.
>
> Adding more code to RequestFilter just complicates an already large
> and messy class.
>
> So I'd suggest that:
>
> - The OAuth code (filter, tools, service, api) is added to the core
> build and deployed as part of the standard
> - /access and /direct both have the OAuth filters added.
> - The filters are updated so they are enabled/disabled by a sakai property.
>
> --
>   Matthew Buckett
>   VLE Developer, LTG, Oxford University Computing Services



-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile