[Building Sakai] Connect to Sakai through oAuth

[Matthew Buckett]

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