[jira] [Comment Edited] (MESOS-2946) Authorizer Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613069#comment-14613069
]
Till Toenshoff edited comment on MESOS-2946 at 7/7/15 8:27 PM:
---
h4.Status Quo
As the current design stands, {{Authorizer}} is indeed an interface, but its
default implementation is declared in the same header. Moreover, if one decides
to create an alternative implementation for authorization, Mesos needs to be
recompiled and all the places where the authorizer gets instantiated need to be
updated.
h4.Design
Under the modularize version, the MVP for the {{Authorizer}} interface will
look like:
{code}
class Authorizer
{
public:
static TryAuthorizer* create(const std::string name);
virtual ~Authorizer() {}
virtual TryNothing initialize(const OptionACLs acls) = 0;
virtual process::Futurebool authorize(
const ACL::RegisterFramework request) = 0;
virtual process::Futurebool authorize(
const ACL::RunTask request) = 0;
virtual process::Futurebool authorize(
const ACL::ShutdownFramework request) = 0;
protected:
Authorizer() {}
};
{code}
Where {{Authorizer::create(const std::string)}} is the factory function which
will construct the default {{LocalAuthorizer}} if local is selected and will
use the existing facilities within {{ModuleManager}} to load the appropriate
module in any other case.
In order to allow the {{LocalAuthorizer}} to play nicely with the general
modules design, it needs a default constructor. This constraint leads to the
existence of {{Authorizer::initialize(const OptionACLs)}} which is needed to
pass initialization parameters to the {{LocalAuthorizer}}. Note that all other
authorizers will use the {{ModuleManager}} mechanisms to pass initialization
parameters. This follows the pattern used in the {{Authenticator}} module. The
method {{Authorizer::initialize(const OptionACLs)}} can be removed when we
go to a modules only implementation.
All other methods remain unchanged from the original {{Authorizer}} interface.
was (Author: arojas):
h4.Status Quo
As the current design stands, {{Authorizer}} is indeed an interface, but its
default implementation is declared in the same header. Moreover, if one decides
to create an alternative implementation for authorization, Mesos needs to be
recompiled and all the places where the authorizer gets instantiated need to be
updated.
h4.Design
Under the modularize version, the MVP for the {{Authorizer}} interface will
look like:
{code}
class Authorizer
{
public:
static TryAuthorizer* create(const std::string name);
virtual ~Authorizer() {}
virtual TryNothing initialize(const OptionACLs acls) = 0;
virtual process::Futurebool authorize(
const ACL::RegisterFramework request) = 0;
virtual process::Futurebool authorize(
const ACL::RunTask request) = 0;
virtual process::Futurebool authorize(
const ACL::ShutdownFramework request) = 0;
protected:
Authorizer() {}
};
{code}
Where {{Authorizer::create(const std::string)}} is the factory function which
will construct the default {{LocalAuthorizer}} if local is selected and will
use the existing facilities within {{ModuleManager}} to load the appropriate
module in any other case.
In order to allow the {{LocalAuthorizer}} to play nicely with the general
modules design, it needs a default constructor. This constraint leads to the
existence of {{Authorizer::initialize(const OptionACLs)}} which is needed to
pass initialization parameters to the {{LocalAuthorizer}}. Note that all other
authorizers will use the {{ModuleManager}} mechanisms to pass initialization
parameters. This follows the pattern used in the {{Authorizator}} module. The
method {{Authorizer::initialize(const OptionACLs)}} can be removed when we
go to a modules only implementation.
All other methods remain unchanged from the original {{Authorizer}} interface.
Authorizer Module: Interface design
---
Key: MESOS-2946
URL: https://issues.apache.org/jira/browse/MESOS-2946
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Labels: mesosphere, module, security
h4.Motivation
Design an interface covering authorizer modules while staying minimally
invasive in regards to changes to the existing {{LocalAuthorizer}}
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2946) Authorizer Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613075#comment-14613075
]
Till Toenshoff edited comment on MESOS-2946 at 7/6/15 8:21 AM:
---
[r/36048/|https://reviews.apache.org/r/36048/]: Updated authorizer to allow for
modularize implementations.
was (Author: arojas):
[r/36049/|https://reviews.apache.org/r/36049/]: First patch implementing the
new interface.
Authorizer Module: Interface design
---
Key: MESOS-2946
URL: https://issues.apache.org/jira/browse/MESOS-2946
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Labels: mesosphere, module, security
h4.Motivation
Design an interface covering authorizer modules while staying minimally
invasive in regards to changes to the existing {{LocalAuthorizer}}
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2946) Authorizer Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613069#comment-14613069
]
Alexander Rojas edited comment on MESOS-2946 at 7/3/15 9:50 AM:
h4.Status Quo
As the current design stands, {{Authorizer}} is indeed an interface, but its
default implementation is declared in the same header. Moreover, if one decides
to create an alternative implementation for authorization, Mesos needs to be
recompiled and all the places where the authorizer gets instantiated need to be
updated.
h4.Design
Under the modularize version, the MVP for the {{Authorizer}} interface will
look like:
{code}
class Authorizer
{
public:
static TryAuthorizer* create(const std::string name);
virtual ~Authorizer() {}
virtual TryNothing initialize(const OptionACLs acls) = 0;
virtual process::Futurebool authorize(
const ACL::RegisterFramework request) = 0;
virtual process::Futurebool authorize(
const ACL::RunTask request) = 0;
virtual process::Futurebool authorize(
const ACL::ShutdownFramework request) = 0;
protected:
Authorizer() {}
};
{code}
Where {{Authorizer::create(const std::string)}} is the factory function which
will construct the default {{LocalAuthorizer}} if local is selected and will
use the existing facilities within {{ModuleManager}} to load the appropriate
module in any other case.
In order to allow the {{LocalAuthorizer}} to play nicely with the general
modules design, it needs a default constructor. This constraint leads to the
existence of {{Authorizer::initialize(const OptionACLs)}} which is needed to
pass initialization parameters to the {{LocalAuthorizer}}. Note that all other
authorizers will use the {{ModuleManager}} mechanisms to pass initialization
parameters. This follows the pattern used in the {{Authorizator}} module. The
method {{Authorizer::initialize(const OptionACLs)}} can be removed when we
go to a modules only implementation.
All other methods remain unchanged from the original {{Authorizer}} interface.
was (Author: arojas):
h4.Status Quo
As the current design stands, {{Authorizer}} is indeed an interface, but its
default implementation is declared in the same header. Moreover, if one decides
to create an alternative implementation for authorization, Mesos needs to be
recompiled and all the places where the authorizer gets instantiated need to be
updated.
h4.Design
Under the modularize version, the MVP for the {{Authorizer}} interface will
look like:
{code}
class Authorizer
{
public:
static TryAuthorizer* create(const std::string name);
virtual ~Authorizer() {}
virtual TryNothing initialize(const OptionACLs acls) = 0;
virtual process::Futurebool authorize(
const ACL::RegisterFramework request) = 0;
virtual process::Futurebool authorize(
const ACL::RunTask request) = 0;
virtual process::Futurebool authorize(
const ACL::ShutdownFramework request) = 0;
protected:
Authorizer() {}
};
{code}
Where {{Authorizer::create(const std::string)}} is the factory function which
will construct the default {{LocalAuthorizer}} if local is selected and will
use the existing facilities within {{ModuleManager}} to load the appropriate
module in any other case.
In order to allow the {{LocalAuthorizer}} to play nicely with the general
modules design, it needs a default constructor. This constraint leads to the
existence of {{Authorizer::initialize(const OptionACLs)}} which is needed to
pass initialization parameters to the {{LocalAuthorizer}}. Note that all other
authorizers will use the {{ModuleManager}} mechanisms to pass initialization
parameters. This method can be removed when we go to a modules only
implementation.
Authorizer Module: Interface design
---
Key: MESOS-2946
URL: https://issues.apache.org/jira/browse/MESOS-2946
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Labels: mesosphere, module, security
h4.Motivation
Design an interface covering authorizer modules while staying minimally
invasive in regards to changes to the existing {{LocalAuthorizer}}
implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
