On 10 Mar 2012, at 13:01, Minh Tien Hoang wrote: > 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.
Thanks Tien - I didn't know about this protocol before, and it looks like a very good fit, it may possibly be easier to implement for connectors and clients than two-legged oAuth. Do you know if existing oAuth libraries have implemented it yet (or are planning to do so)? I saw an issue on the Amber tracker for it: https://issues.apache.org/jira/browse/AMBER-41 S > > 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/ >> >> >> >
