On 09/12/2016 05:48 AM, Radoslaw Zarzynski wrote:
On Thu, Sep 8, 2016 at 8:23 PM, Casey Bodley <cbodley@xxxxxxxxxx> wrote:
Right, this was the requirement that motivated the work on preselection, so we would only try to authenticate against engines that are properly configured and relevant to the given handler.
Which component should be responsible for verifying correctness
of configuration? I would say the best candidate is an AuthEngine
itself. Some time ago the static can_be_enabled() was proposed.
If we need that feature, maybe similar (but better named) method
is a way to go?
I think this responsibility needs to be shared between the auth method
and the module (s3, swift, or nfs) that's trying to configure it. The
objection to a static can_be_enabled() method as part of the AuthEngine
interface was that it doesn't allow different modules to provide a
custom configuration - it could only decide based on global state like
ceph.conf. That said, I do think it makes sense for the concrete
AuthEngine types to provide their own methods that take whatever
configuration parameters are relevant to that auth type.
As an example, here's how I see s3 constructing its auth strategy:
using AuthEnginePtr = std::unique_ptr<AuthEngine>;
using AuthStrategy = std::vector<AuthEnginePtr>;
static AuthStrategy get_s3_auth_strategy()
{
AuthStrategy strategy;
// try to configure LDAP
LDAPAuthEngine ldap;
if (ldap.initialize(ldap_uri, ldap_binddn, ldap_bindpw,
ldap_searchdn, ldap_dnattr)) {
AuthEnginePtr ptr{new LDAPAuthEngine(std::move(ldap))};
strategy.emplace_back(std::move(ptr));
}
...
return strategy;
}
(this assumes the 'stateless' version of AuthEngine, where its only
state is configuration, rather than the state needed to authenticate a
single request. so initialize() is a non-static member function)
With respect to changing the auth strategy (i.e. the list of engines configured for a given handler) at runtime, I'm not sure it's worth the complexity at this point, and we certainly don't want to add locking to do this safely. [note that we do have 'dynamic reconfiguration' which pauses the frontend while it reloads RGWRados, so we could use that mechanism to change auth strategy without needing new locks]
Great. It looks that at this phase we don't need to have the feature onboard.
It's enough to just don't prohibit implementing it in the future.
P.S.
Sorry for resending this letter, Casey. I had accidentally sent HTML
on my mobile client. The message was refused by vger.kernel.org.
Regards,
Radek
--
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
