[Building Sakai] Connect to Sakai through oAuth

Matthew Jones matthew at longsight.com
Thu Jun 7 10:44:10 PDT 2012 

This would be useful if RequestFilter was easier to configure. I know I've
hardcoded a pre filter into there before. I'd agree the extra cycles are
trivial unless your filter is making db requests or something. :)
On Jun 7, 2012 1:24 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
> _______________________________________________
> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120607/3f6c83e9/attachment.html

More information about the sakai-dev mailing list