[Building Sakai] Connect to Sakai through oAuth

[Adrian Fish]

If Colin emails the list when he's done with his admin console work, 
somebody'll take a look.

Cheers,
Adrian.

On 15/06/2012 00:36, Aaron Zeckoski wrote:
>> - 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
>
>

-- 
==================================
Adrian Fish
Software Engineer
B66 Management School
Lancaster University
Lancaster
LA1 4YW

http://www.sakaiproject.org
http://confluence.sakaiproject.org/display/YAFT/Yaft
http://confluence.sakaiproject.org/display/CLOG/Home
http://confluence.sakaiproject.org/display/BBB/Home