Hi Grant,

Excellent link for Amazon's HMAC mechanism - thanks for sharing!

Les

On Tue, Apr 5, 2011 at 7:39 AM, Grant Genereux <[email protected]> wrote:
> Hi Les,
>
> Here are a couple of other resources that you might want to check out:
>
> 1) Amazon's HMAC type access for their webservices:
>
>
>  http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?HMACAuth.html
>
>        I've implemented this same scheme in several apps now, and it seems
> to be holding up well.
>        If you are using a pure JavaScrtipt client you will want to check-out
> the following library http://jssha.sourceforge.net to sign your requests.
>
> 2) I have an EAP of the Restlet In Action book, by Jérôme Louvel, and
> Thierry Boileau.  There is a good chapter there about securing a REST based
> app.
>
>    I've not implemented this in a live app yet , but it looks like they have
> put a lot thought into this.
>
> Hope this helps
>
> Grant
>
>
> On 4/4/2011 8:17 PM, Les Hazlewood wrote:
>>
>> Hi all,
>>
>> I've been working on Shiro's internals today to simplify support for
>> REST applications.  My motivation is partially selfish, since I'm
>> using Shiro to protect REST endpoints at work, and I'll need to ensure
>> this all goes smoothly.
>>
>> Before I get too far involved, I was wondering if anyone had any
>> problems they've come across in the past and would like to share or
>> any ideas in general that they think would make REST security easier.
>>
>> I have 2 things on my list that I think are relatively obvious:
>>
>> 1.  Support authentication caching (key: AuthenticationToken, value:
>> AuthenticationInfo).  Since REST calls usually use HTTP BASIC
>> authentication and assume no server state, it would be ideal if we
>> didn't have a roundtrip to the datastore(s) for each REST call.
>>
>> 2.  Support custom authentication 'binding'.  Currently when Shiro
>> authenticates a subject it puts the resulting PrincipalCollection and
>> authentication state in the Session to ensure it is available for the
>> remainder of the Subject's interaction with the application during
>> that session.  Of course, with REST being stateless, it would be ideal
>> to turn this off for any authentication that occurred during a REST
>> call.
>>
>> Anything else?
>>
>> Any ideas?
>>
>> Thanks,

Reply via email to