[Building Sakai] Connect to Sakai through oAuth

[Aaron Zeckoski]

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