Re: rgw: feedback on auth engine selection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
> From: "Casey Bodley" <cbodley@xxxxxxxxxx>
> To: "The Sacred Order of the Squid Cybernetic" <ceph-devel@xxxxxxxxxxxxxxx>
> Sent: Thursday, September 8, 2016 2:35:34 AM
> Subject: Re: rgw: feedback on auth engine selection
> 
> 
> On 09/07/2016 01:19 PM, Radoslaw Zarzynski wrote:
> > Anyway, before we start discussing the whole
> > auth stuff further, I guess it would be helpful to
> > write in one place all requirements/plans that
> > might affect this area. For instance, the idea of
> > RGWHandler rework can have such impact.
> >
> > Let me start the requirements with an item found
> > after a session with Swift's FormPost middleware:
> >
> > * the auth infrastructure must allow for easy-adoption
> >    of new AuthEngines as even FormPost would need
> >    one :-).
> 
> Some specific requirements that I recall from our past discussions include:
> 
> - don't heap allocate auth state per request
> - don't construct or call into AuthEngines that shouldn't be enabled for
> the given handler
> 
> I'll add some of the other refactoring goals we've discussed, but I
> don't think they place any strict requirements on the auth subsystem:
> 
> - RGWHandler: being able to reuse handler instances, instead of
> allocating a new one for each request
> - req_state: contains too many unrelated fields, some of which are
> transformed in confusing ways over the lifetime of the request. needs to
> be broken up into smaller, better encapsulated sub-objects
> - concurrency: move away from a synchronous process_request() to build
> on asio frontend work

One more requirement to add to the list:

- In case of AWS, two different methods (RGWPostObj_ObjStore_S3::get_policy() and RGW_Auth_S3::authorize), will be making use of the Auth Engines to authenticate a request and the auth key extraction method will be different for both of them. The auth infrastructure needs to take care of this.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux