[jira] [Comment Edited] (MESOS-911) Add pluggable authorization interface

["Vinod Kone (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924302#comment-13924302 ] 

Vinod Kone edited comment on MESOS-911 at 3/7/14 9:45 PM:
----------------------------------------------------------

Another iteration because I wasn't satisfied with the previous version.

The things I didn't like
1) We were calling ACLs as "ACL".
2) By definition an ACL is something that is set on a resource. And the "List" in the "Access Control List" refers to the list of subject and permission pairs.

I actually looked at some more online ACL definitions and usage and really liked AWS's version. http://docs.aws.amazon.com/AmazonS3/latest/dev/ACLOverview.html

Inspired by AWS, this is what I ended up with.

{code}
/**
 * ACLs used for authorization.
 */
message ACLs {

  message WWW_ACL {
    message Grant {
      enum Permission {
        GET = 0;
        PUT = 1;
      }
      enum Grantee {
        IP = 0;
        HOST = 1;
        ANYONE = 2;
        NONE = 3;
      }
      required Permission permission = 1;
      required Grantee grantee = 2;
    }

    required string url = 1;
    repeated Grant grants = 2;
  }

  message ROLE_ACL {
    message Grant {
      enum Permission {
        ALLOCATE = 0;
      }
      enum Grantee {
        PRINCIPAL = 0;
        ANYONE = 1;
        NONE = 2;
      }
      required Permission permission = 1;
      required Grantee grantee = 2;
    }

    required string role = 1;
    repeated Grant grants = 2;
  }

  message USER_ACL {
    message Grant {
      enum Permission {
        LAUNCH = 0;
      }
      enum Grantee {
        PRINCIPAL = 0;
        ANYONE = 1;
        NONE = 2;
      }
      required Permission permission = 1;
      required Grantee grantee = 2;
    }

    required string user = 1;
    repeated Grant grants = 2;
  }

  repeated WWW_ACL www_acls = 1;
  repeated ROLE_ACL role_acls = 2;
  repeated USER_ACL user_acls = 3;
}
{code}

I think it is flexible and easy to understand and line with what others in the OSS do (e.g., ZooKeeper and AWS).

One refactor we could do is to move ACLs up into their own ACL message. This is probably pretty with some added cost of validation.

{code}

message ACL {
  message WWW {};
  message ROLE {};
  message USER {};

 optional WWW www;
 optional ROLE role;
 optional USER user;
}

message ACLs {
 repeated ACL acls;
}

{code}


Let me know what you think?


was (Author: vinodkone):
Another iteration because I wasn't satisfied with the previous version.

The things I didn't like
1) We were calling ACLs as "ACL".
2) By definition an ACL is something that is set on a resource. And the "List" in the "Access Control List" refers to the list of subject and permission pairs.

I actually looked at some more online ACL definitions and usage and really liked AWS's version. http://docs.aws.amazon.com/AmazonS3/latest/dev/ACLOverview.html

Inspired by AWS, this is what I ended up with.

{code}
/**
 * ACLs used for authorization.
 */
message ACLs {

  message WWW_ACL {
    message Grant {
      enum Permission {
        GET = 0;
        PUT = 1;
      }
      enum Grantee {
        IP = 0;
        HOST = 1;
        ANYONE = 2;
        NONE = 3;
      }
      required Permission permission = 1;
      required Grantee grantee = 2;
    }

    required string url = 1;
    repeated Grant grants = 2;
  }

  message ROLE_ACL {
    message Grant {
      enum Permission {
        ALLOCATE = 0;
      }
      enum Grantee {
        PRINCIPAL = 0;
        ANYONE = 1;
        NONE = 2;
      }
      required Permission permission = 1;
      required Grantee grantee = 2;
    }

    required string role = 1;
    repeated Grant grants = 2;
  }

  message USER_ACL {
    message Grant {
      enum Permission {
        LAUNCH = 0;
      }
      enum Grantee {
        PRINCIPAL = 0;
        ANYONE = 1;
        NONE = 2;
      }
      required Permission permission = 1;
      required Grantee grantee = 2;
    }

    required string user = 1;
    repeated Grant grants = 2;
  }

  repeated WWW_ACL www_acls = 1;
  repeated ROLE_ACL role_acls = 2;
  repeated USER_ACL user_acls = 3;
}
{code}

I think it is flexible and easy to understand and line with what others in the OSS do (e.g., ZooKeeper and AWS).

One refactor we could do is to move ACLs up into their own ACL message. This is probably pretty with some added cost of validation.

{code}

message ACL {
  message WWW {};
  message ROLE {};
  message USER {};

 optional WWW www;
 optional ROLE role;
 message USER user;
}

message ACLs {
 repeated ACL acls;
}

{code}


Let me know what you think?

> Add pluggable authorization interface
> -------------------------------------
>
>                 Key: MESOS-911
>                 URL: https://issues.apache.org/jira/browse/MESOS-911
>             Project: Mesos
>          Issue Type: Story
>          Components: general
>            Reporter: Adam B
>            Assignee: Vinod Kone
>              Labels: security
>
> We are investigating authorizing principals to allow them access to only a specific set of operations like launching tasks or using resources. In fact, you could imagine a world where an authenticated principal will be authorized to on behalf of a subset of users and roles for launching tasks and accepting resources respectively. This authorization information could be stored in a directory service like LDAP.



--
This message was sent by Atlassian JIRA
(v6.2#6252)