[Building Sakai] Connect to Sakai through oAuth

[Colin Hebert]

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