openstack team mailing list archive

[Victor Rodionov <Victor.Rodionov@xxxxxxxxxxx>]

Hello

My implementation need only "remote user" header from authorization system with user name (comma separated list of username (roles)) or put key REMOTE_USER to WSGI env. So it will work ok with tempauth, because it add REMOTE_USER to env. For keystone no much changes will be needed.

Unfortunately, as I said before, I don't have any idea how it can be implemented as middleware.

BTW, I also have changes for swift3 middleware for support S3 API to change ACL, so users can use S3 clients (I test this with Cyberduck) for manipulation with container and object ACL.

Also, I want ask do you think it's good idea to store object ACL in object metadata?

20.06.2012, в 19:17, John Dickinson написал(а):

> Yes, this could be good for swift.
> 
> ACLs in swift do need to be stored in swift (for scale reasons), but their implementation is dependent on the particular auth system that you are using. The auth middleware is responsible for determining if a request is granted access to a particular swift entity. How does your implementation work with the current ACL support provided by tempauth and swauth? Are your ACLs compatible with the RBAC work being done in keystone?
> 
> I would suggest that general, full-featured ACL support should be done in conjunction with the work done in keystone and the swift-keystone middleware. If your implementation is simply more full-featured S3 compatibility, I'd suggest patching the 3rd party swift3 middleware.
> 
> --John
> 
> 
> On Jun 20, 2012, at 9:38 AM, Victor Rodionov wrote:
> 
>> Hello
>> 
>> I have working implementation of S3 like ACL API for Swift, for this changes I need to store ACL on object and container server, then I need to change container and object servers code.
>> 
>> So my question, if this changes will be interesting for Swift community or no?
>> 
>> Thanks,
>> Victor
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>