On 13 Mar 2012, at 07:42, Scott Wilson wrote: > > 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.
Yes, exactly and we might include an id for issued API key and a hash algorithm (hmac-sha-1 or hmac-sha-256 ) when delivery the API key to requester. > 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 For implementing the connector as well as the server side (I assume that we place a filter at each REST API), we need only Base64 and hmac-sha-1 (or 256) algorithms for constructing and verifying the hash. They are all available in standard library of Java, PHP, Python, C# so I think we could go forward without any problem. Tien. > 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/ >>> >>> >>> >> >
