[Building Sakai] Connect to Sakai through oAuth

Fri Jun 8 06:44:41 PDT 2012

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.

-AZ

On Fri, Jun 8, 2012 at 9:30 AM, Colin Hebert <colin.hebert at oucs.ox.ac.uk> wrote:
> But this would mean that you have to upgrade your kernel to have oAuth
> whereas the current solution only necessitate a modification in the
> web.xml of tools that will support oAuth (you don't even have to
> compile anything). I mean if someone wants to use oAuth right away
> it's possible to set it up in a few minutes with small modifications
> in three different files.
>
> And as I said, so far, I only know two tools that could really benefit
> from oAuth; EB and access. If indeed there are use cases where having
> every tool (or just more tools) accessible through oAuth is relevant
> then sure, modifying the request filter will be the solution.
>
> I'm not saying that it's complicated to do that (but probably not that
> trivial), I'm just not sure that it's relevant to add even more code,
> as trivial as it would be, in request filter, which does already a lot
> of different things, if in the end there are only two tools beneficing
> of that additional code.
>
> And this code wouldn't be that trivial either because the workflow isn't:
> -PreFilter
> -RequestFilter
> -Servlet call
> -PostFilter
>
> but
> -PreFilter
> -RequestFilter
> -PostFilter
> -Servlet call
>
> This means that the hooked filters need to be executed in a certain
> order, and if another part of the code adds another hooked filter, the
> PreFilter still need to be executed first, and the PostFilter needs to
> be the last code executed before the servlet call (which implies
> priorities).
>
> So in the end, it would require to rewrite something close to servlet
> filter system inside one filter, allowing the "hooked filters" to be
> registered dynamically but with a priority system.
>
> It's not so hard to do, but I really don't think that adding that as
> is into RequestFilter would be a good thing.
>
> Colin
>
> On Thu, Jun 7, 2012 at 6:23 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>> Well, the alternative is to add "hooks" into the request filter so
>> that some code can be run before the rest of the sakai code and some
>> can be run after (optionally in both cases). Sorta like:
>>
>> public void doFilter(ServletRequest request,
>>      ServletResponse response, FilterChain chain)
>>      throws IOException, ServletException {
>>
>> // do pre-servlet work here
>>
>> chain.doFilter(request, response);
>>
>> // do post servlet work here
>>
>> }
>>
>>
>> So for example, we could set it up so that a provider could be added
>> to execute before or after the rest of the stuff and if there were no
>> providers configured then everything runs like it does right now
>> today. If there are providers then it runs them (perhaps only in
>> certain cases). It's a fairly trivial effort to add that in there, and
>> compared to the effort required to get 100s of projects to modify
>> their web.xml, it is inconsequential and far more controllable.
>>
>> Anyway, just a thought.
>> I would think that will make it a lot more likely that people would
>> consider deploying this.
>> -AZ
>>
>>
>>
>> On Thu, Jun 7, 2012 at 1:07 PM, Colin Hebert <colin.hebert at oucs.ox.ac.uk> wrote:
>>> I think that on most instances oAuth will be used only on EB (possibly
>>> on access too), so there is no need to check for oAuth requests all
>>> the time, it would slow most requests (even if it's just a bit) for
>>> nothing.
>>>
>>> Plus, I need two filters, one applied before every other filter to set
>>> the advisor and principal if the user is already logged in, and one
>>> applied after every other filter (especially RequestFilter) to send
>>> the user on the login page if he isn't logged in yet but in an oAuth
>>> connection.
>>> Trying to do that in RequestFilter would mean adding more code in a
>>> class which does already a lot of things, anyway Filters by themselves
>>> are already "hooks" so it seemed to be the easiest solution (and it
>>> avoids dependency to specific/new versions of the kernel).
>>>
>>> Unfortunately, this does mean that if someone wants oAuth everywhere
>>> the only solution I can think of would be modifying every web.xml to
>>> add the pre and post filters.
>>>
>>> Colin
>>>
>>> On Thu, Jun 7, 2012 at 4:48 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>> Just a quick thought, but rather than applying a pre and post filter
>>>> to each tool, why not put some hooks directly into the sakai request
>>>> filter? Then you can get access to the request before and after
>>>> everything in sakai (portals, tools, EB, etc.)
>>>> -AZ
>>>>
>>>>
>>>> On Thu, Jun 7, 2012 at 11:07 AM, Colin Hebert
>>>> <colin.hebert at oucs.ox.ac.uk> wrote:
>>>>> Hello,
>>>>>
>>>>> Here is a project to enable oAuth
>>>>> (http://wiki.oauth.net/w/page/12238516/FrontPage) connection toward
>>>>> Sakai : https://github.com/ColinHebert/Sakai-OAuth
>>>>>
>>>>> This should allow other applications to connect to Sakai and use some
>>>>> services (like entitybroker) on the behalf of users who granted access
>>>>> rights to the said application.
>>>>>
>>>>> It should be easy to set up, you have to allow each application
>>>>> (consumer) manually in the sakai.properties file, give it rights and a
>>>>> secret which will be used during the connection:
>>>>>
>>>>> oauth.consumers=client1,client2
>>>>>
>>>>> #Client1
>>>>> oauth.client1.name=Client1's name as it will be shown to any user
>>>>> trying to connect through this application
>>>>> oauth.client1.description=A relevant description explaining which
>>>>> right will be given to the application
>>>>> oauth.client1.url=http://web.site.of.the.application.com
>>>>> #Given rights to the consumer
>>>>> oauth.client1.rights=site.visit,content.read,poll.vote,signup.view,signup.attend,eval.take.evaluation,annc.read,calendar.read
>>>>> oauth.client1.secret=p at ss0Rdf@rcl13ntOne
>>>>>
>>>>> #Client2
>>>>> oauth.client2.name=Second client's name
>>>>> oauth.mobileox-dev.description=Another description
>>>>> oauth.client2.url=http://web.site.com/
>>>>> #This is an other way to give rights to a consumer, it's a bit easier
>>>>> to read, but way more verbose
>>>>> oauth.client2.rights.count=8
>>>>> oauth.client2.rights.1=site.visit
>>>>> oauth.client2.rights.2=content.read
>>>>> oauth.client2.rights.3=poll.vote
>>>>> oauth.client2.rights.4=signup.view
>>>>> oauth.client2.rights.5=signup.attend
>>>>> oauth.client2.rights.6=eval.take.evaluation
>>>>> oauth.client2.rights.7=annc.read
>>>>> oauth.client2.rights.8=calendar.read
>>>>> oauth.client2.secret=Pa$5orDF0rClIen7tW0
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>> Once this is configured, the oAuth filters must be applied on tools
>>>>> providing the services we need. The entitybroker's tool will have to
>>>>> declare a pre and post filter in the web.xml file:
>>>>>
>>>>>  <!-- OAuth Filters -->
>>>>>  <filter>
>>>>>    <filter-name>oauth.pre</filter-name>
>>>>>    <filter-class>uk.ac.ox.oucs.oauth.filter.OAuthPreFilter</filter-class>
>>>>>  </filter>
>>>>>  <filter>
>>>>>    <filter-name>oauth.post</filter-name>
>>>>>    <filter-class>uk.ac.ox.oucs.oauth.filter.OAuthPostFilter</filter-class>
>>>>>  </filter>
>>>>>
>>>>>  <filter-mapping>
>>>>>    <filter-name>oauth.pre</filter-name>
>>>>>    <servlet-name>sakai.entitybroker.direct</servlet-name>
>>>>>    <dispatcher>REQUEST</dispatcher>
>>>>>  </filter-mapping>
>>>>>
>>>>>  <filter-mapping>
>>>>>    <filter-name>sakai.request</filter-name>
>>>>>    <servlet-name>sakai.entitybroker.direct</servlet-name>
>>>>>    <dispatcher>REQUEST</dispatcher>
>>>>>    <dispatcher>FORWARD</dispatcher>
>>>>>    <dispatcher>INCLUDE</dispatcher>
>>>>>  </filter-mapping>
>>>>>
>>>>>  <filter-mapping>
>>>>>    <filter-name>oauth.post</filter-name>
>>>>>    <servlet-name>sakai.entitybroker.direct</servlet-name>
>>>>>    <dispatcher>REQUEST</dispatcher>
>>>>>  </filter-mapping>
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>> This should allow two different oAuth consumers (identified as client1
>>>>> and client2) to connect to the sakai instance and with the user
>>>>> permission give them the right to access polls, calendars,
>>>>> announcements, etc.
>>>>>
>>>>> Right now the configuration has to be done in the sakai.properties
>>>>> file, which can be a bit annoying (you have to restart the server each
>>>>> time you do a modification, therefore I'm working on an web interface
>>>>> allowing to administrate which consumers are allowed and with which
>>>>> rights and store everything in the database.
>>>>>
>>>>> I haven't written a user documentation yet, (so many things need to be
>>>>> done!) but the developer documentation should be complete enough for
>>>>> any developer to dive into the code and see how it works.
>>>>>
>>>>>
>>>>> If you have some time to review the code, give some insights or even
>>>>> contribute, feel free to do so. It's on github so you should be easily
>>>>> able to fork and do whatever you want from there.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Colin
>>>>> _______________________________________________
>>>>> 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"
>>>>
>>>>
>>>>
>>>> --
>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile

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