Hello, Just another proposal for considering, I think oauth is complicated in the phase of obtaining tokens and managing the token expiration. So for securing REST API, we could base on this specification http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (ignoring oAuth2 binding spec). The idea is for each invocation of REST API, we put the authentication info in http header for authenticating the request. It is demonstrated in section "1.1 example" of the specification. Tien.
On 09 Mar 2012, at 15:21, Scott Wilson wrote: > Hi everyone, > > As we are now in the stages of removing the admin web interface and instead > relying on the REST API for all aspects of Wookie, I think its time we > thought about how we want security to work in Wookie more generally. > > Currently we have two distinct forms of authentication: > > - API keys are used to authenticate requests from applications working with > widget instances, assumed to be using a server-server back channel > - HTTP Basic authentication is used to access admin APIs using the servlet > container's security roles > > The problem is that each authn approach is configured statically against a > particular set of API requests with implied authz roles. > > I also have a proposal[1] to use both a key and secret to sign API requests > using Two-legged oAuth, which could be used for all the APIs when combined > with permissions associated with key/secret combinations. I've also attached > the code I've been playing with for that to the issue to take a look at. > > Of course this then puts an overhead on connectors to be able to sign > messages, manage consumer secrets etc. On the plus side, it doesn't matter > about sending requests over plain HTTP outside the firewall when using signed > requests, as you never disclose the shared secret. > > This could be configured to still use the plain unsigned requests in cases > where Wookie is behind the firewall and you want to use simple requests, or > we can allow unsigned requests for some APIs but not others - e.g. keep the > current distinction between admin and non-admin interfaces - maybe using > Shiro[2]. Its more work, but doable, and more flexible than editing web.xml. > So the code I attached to the Jira ticket could be modified to check whether > the request is signed or unsigned, and add that as a property to an > authenticated principal for use when checking authz. > > In any case, any changes to authn/authz would mean updating the connectors > (something we have to do for 0.10 anyway as we're updating other parts of the > API.) > > What do you think? > > S > > PS we also have the possibly-related issue of getting access rights to Rave > admins when co-deploying Wookie. > > [1] https://issues.apache.org/jira/browse/WOOKIE-279 > [2] http://shiro.apache.org/ > > >
