[Building Sakai] Connect to Sakai through oAuth

[Colin Hebert]

The administration console is ready. It's a bit raw (I'm far from
being a designer) but it's only for admins so it shouldn't be a big
issue ( http://imgur.com/omhsn.png ) and it can be easily improved
(wicket).

There are some features I would like to add (
https://github.com/ColinHebert/Sakai-OAuth/issues?state=open ) but
they're not priorities and it works fine without them.


Colin

On Fri, Jun 15, 2012 at 3:22 PM, Adrian Fish <a.fish at lancaster.ac.uk> wrote:
> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"