...

#org.apache.sqoop.authorization.handler=org.apache.sqoop.security.DefaultAuthorizationHandler
#org.apache.sqoop.authorization.controller=org.apache.sqoop.security.DefaultAccessController
#org.apache.sqoop.authorization.validator=org.apache.sqoop.security.DefaultAuthorizationValidator

Image RemovedImage Added

• Three metadata.
  • Role
  • principal
    • This class defines user or group.
    • Type: user, group, role.
    • principal could be granted a role. i.e. if we want to grant a admin role to user hadoop, then grantRole (principal (name=hadoop, type=user), role (name=admin)).
  • Resource
    • This class defines four resources in Sqoop 2.
    • Type: connector, link, job, submission.
  • Privilege
    
    • Action: create, view, update, delete, use, enable, disable.
    • with_grant_option: boolean, defines whether the role could grant this privilege to other role.

Image Modified

• Five classes will be added into Sqoop-core as org.apache.sqoop.security package.
  • AuthorizationManager
    • Similar with other Sqoop Manager, ie. ConnectorManager, RepositoryManager, etc., the AuthorizationManager handles two singleton instances, AuthorizationManager and AuthorizationHandler.
    • The initialize function is run when starting the Sqoop server
    • The initialize function will initial AuthorizationHandler, according to the handler name (DefaultAuthorizationhandler or SentryAuthorizationHandler) from configuration file (sqoop.properties).
  • AuthorizationHandlerFactory
    • It is a factory design mode.
    • It is to use ClassUtils.loadClass to refact the real AuthorizationHandler in getAuthorizationHandler function.
  • AuthorizationHandler
    • It is an abstract class.
    • There is a default implementation (DefaultAuthorizationHandler) in Sqoop-security component.
    • It handles two singleton instances, AccessController and AuthorizationValidator.
    • All function will be delegated to these two instances to handle. AccessController to handle grantRole, revokeRole, grantPrivilege and revokePrivilege. AuthorizationValidator to handle checkPrivilege.
  • AccessController
    • It is an abstract class.
    • There is a default implementation (DefaultAccessController) in Sqoop-security component.
    • This class is responsible to manage roles, privileges.
  • AuthorzationValidator
    • It is an abstract class.
    • There is a default implementation (DefaultAuthorizationValidator) in Sqoop-security component.
    • This class is responsible to check privileges.
• Three classes will be added into Sqoop-security as org.apache.sqoop.security package.
  • DefaultAuthorizationHandler
    • This class extends abstract AuthorizationHandler.
    • It handles two singleton instances, DefaultAccessController and DefaultAuthorizationValidator.
  • DefaultAccessController
    • This class extends abstract AccessController.
  • Default AuthorzationValidator
    • This class extends abstract AuthorizationValidator.
    • As default/simple implementation, it always returns true and will not check the privilege actually.

Image Modified

• All functions in RequestHandler, which handles all requests, ie. create link, will be added privilege validation check.

...

show role
show role -pid 1role_name admin
show role -principal_name sqoop -principal_type user
show role -privilege_name my_privilege
add role –role_name admin
update role -rid 1old_role_name admin -new_role_name admindeveloper
remove role -role_name admin
 
show principal
show principal -ridprincipal_name 1sqoop
grantshow role –nameprincipal -principal_type user
addshow role –id 1 –nameprincipal -principal_name sqoop -principal_type user
removeshow principal -role –id 1
show role_user_group
grant principal –role_id 1 –user_name sqoop
grant principal –role_id 1 –group_name sqoop
revoke principal –role_id 1 –user_name sqoop
revoke principal –role_id 1 –group_name sqoop
show privilege
grant privilege –resource_type link –resource_id 1 –role_id 1 –action_type read -with-grant-option yes
revoke privilege –resource_type link –resource_id 1 –role_id 1 –action_type read_name admin
add principal –principal_name sqoop -principal_type user
update principal -old_principal_name sqoop -old_principal_type user -new_principal_name hadoop -new_principal_type group
remove principal -principal_name sqoop
remove principal -principal_type user
remove principal -principal_name sqoop -principal_type user


grant role –role_name admin -principal_name sqoop -principal_type user
revoke role –role_name admin -principal_name sqoop -principal_type user
 
show resource
show resource -resource_type link
show resource -resource_name 1 -resource_type link
add resource -resource_name 1 -resource_type link -action create -with_grant_option true
update resource -old_resource_name 1 -old_resource_type link -new_resource_name 2 -new_resource_type link
remove resource -resource_type link
remove resource -resource_name 1 -resource_type link
 
show privilege
show privilege -privilege_name my_privilege
show privilege -resource_name 1 -resource_type link
show privilege -role_name admin
add privilege -resource_name 1 -resource_type link
update privilege -old_resource_name 1 -old_resource_type link -old_action create -old_with_grant_option true -new_resource_name 1 -new_resource_type link -new_action create -new_with_grant_option true
remove privilege -privilege_name my_privilege
remove privilege -resource_name 1 -resource_type link
remove privilege -resource_name 1 -resource_type link -action create -with_grant_option true
 
grant privilege –role_name admin -privilege_name my_privilege
revoke privilege –role_name admin -privilege_name my_privilege

• Restful call API is handled by org.apache.sqoop.handler.AuthorizationRequestHandler.java in sqoop-server
  • GET /v1/role/{rid}
  • GET /v1/role/principal/type/{type}/name/{name}
    
    • Return details about one particular role with id:rid
    • Return all roles the particular principal has with principal (type, name)
    • Return all of them if rid equals to "all"
  • PUT /v1/role
    • Create new role without id:rid
    • Update existing role with id:rid
    • PUT data of JsonObject role (name)
  • DELETE /v1/role/{rid}
    
    
  • GET /v1/principal/{pid}
  • GET /v1/principal/role/{rid}
    • Return details about one particular principal with id:pid
    • Return all principals the particular role has with role (rid)
    • Return all of them if pid equals to "all"
  • GET /v1/role/{rid}
  • GET /v1/role/principal/type/{type}/name/{name}
    
    • Return details about one particular role with id:rid
    • Return all roles the particular principal has with principal (type, name)
    • Return all of them if rid equals to "all"
  • PUT /v1/grant_role
    • Grant a role to a user/group/role
    • PUT data of JsonObject role(id) list and principal (type, name) list
  • PUT /v1/revoke_role
    • Revoke/Remove a existing role grant
    • PUT data of JsonObject role(id) list and principal (type, name) list
      
      
  • GET /v1/resource/{rid}
    • Return details about one particular role with id:rid
    • Return all of them if rid equals to "all"
  • PUT /v1/resource
    • Create new resource without id:rid
    • Update existing resource with id:rid
    • PUT data of JsonObject resource (type, name)
  • DELETE /v1/resource/{rid}
    
    
  • GET /v1/privilege/{pid}
    • Return details about one particular privilege with id:pid
    • Return all of them if pid equals to "all"
  • PUT /v1/privilege
    • Create new privilege without id:pid
    • Update existing role with id:pid
    • PUT data of JsonObject privilege(resource, action, with_grant_option)
  • DELETE /v1/privilege/{pid}
    
    
  • PUT /v1/grant_privilege
    • Grant a privilege to a role
    • PUT data of JsonObject role(id) list and privilege (resource, action, with_grant_option) list
  • PUT /v1/revoke_privilege
    • Revoke/Remove a existing privilege grant
    • PUT data of JsonObject role(id) list and privilege (resource, action, with_grant_option) list

Sentry implementation

Image Modified

• Sentry could be used as an alternative access controller
• Config in sqoop.properties

...

• Use Sentry to check access privilege
• Set access privilege using hue (optional)

Database design

Image Modified

• Role table
  • Id
  • Name
  • Comment
    • Role name could be admin, developer, user, etc.
• Role_User_Group table
  • Id
  • Role_id
  • User_name
  • Group_name
  • Comment
    • The information of user and group comes from Linux or LDAP etc.
    • Only one of user name and group name is set. If user name is set and leave group name empty, it means that this user has this rule. If group name is set and leave user name empty, it means that all users in this group has this rule.
    • One user/group could have one or multiple roles.
• Privilege table
  • Id
  • Role_id
  • Resource_id
  • Resource_type
  • Action_type
  • Comment
    • Resource type could be the existing resource table, such as connector, link, job, submission, etc.
    • Resource type could be added in the future, say config etc.
    • If resource_id is 0, it means all resource of this type, ie. resource_id=0 and resource_type=link means all links.
    • Use resource id and resource type to identify the resource, ie. resource_id=1 and resource_type=link means the resource of “select * from link where id =1”.
    • Action type could be read, create, update, delete, use etc.
• Accordingly, MRole, MRoleUserGroup and MPrivilege classes are added into package org.apache.sqoop.model.

...