You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Kai Zheng (JIRA)" <ji...@apache.org> on 2013/07/03 17:06:20 UTC

[jira] [Commented] (HADOOP-9659) Hadoop authentication enhancement use cases, goals, requirements and constraints

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

Kai Zheng commented on HADOOP-9659:
-----------------------------------

=== From TokenAuth ===

Use cases
1. Users can authenticate using their own domain specific identity and receive an opaque token; this token and its derived tokens are then passed through transparently to all Hadoop services as needed, for RPC or web interface interactions
2. Service implementers have a common library for validating, authorizing and auditing the provided identity and its attributes
3. Administrators can introduce new authentication mechanisms, by way of pluggable connectors against identity backend providers
4. Users can authenticate in one cluster and access another cluster in a federation without reauthentication
5. Current Hadoop deployments can continue to use existing authentication methods in a backwards compatible way

Requirements                                                                                        1. Pluggable authentication modules; concrete authentication mechanism and modules are selectable via configuration and user interactions, client attributes and capabilities
2. A provider interface and API for integrating Hadoop authentication with existing identity providers deployed in the wider organization
3. Domain based authentication model: different authentication mechanisms, or those with different configurations, according to different context, can be used for different user domains
4. Build on current Hadoop SASL authentication framework with a new authentication method, and support RPC
5. Backwards compatibility with today’s authentication methods and deployment
6. A common token format with variable identity attributes to support fine-grained access control
7. Also support Web browser SSO for Hadoop web interfaces and REST access for Hadoop services in REST API
8. Support proxy authentication: one Hadoop service can proxy authenticated client user to access other Hadoop service in a constrained way
9. Client authentication integration: support to integrate client authentication mechanisms like desktop Active Directory, Smart card and etc.
10. Token authority (issuer) supports REST interface, optional RPC interface and web browser flow.

Constraints
1. Hadoop should only need to understand the common token and the new authentication method instead of concrete authentication mechanism
2. Add new authentication framework and API as an alternative to the existing API, for backwards compatibility and to avoid impact to ecosystem projects
3. The new framework and API will be used to re-implement existing authentication methods so an internal migration can happen without external impact
4. The token based authentication and framework should be able to avoid the common threats regarding bearer tokens

                
> Hadoop authentication enhancement use cases, goals, requirements and constraints
> --------------------------------------------------------------------------------
>
>                 Key: HADOOP-9659
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9659
>             Project: Hadoop Common
>          Issue Type: Task
>          Components: security
>            Reporter: Kevin Minder
>            Priority: Critical
>
> We need to collect use cases, goals, requirements and constraints in a central location to inform all of the various efforts underway to improve Hadoop security initially focusing on authentication.
> For each use case we need to consider the following variations:
> A) Hadoop CLI client, B) cURL REST client, C) Browser WebUI client, D) Gateway and direct access for A,B,C
> UC1. Integrate with Kerberos (backwards compatibility).
> UC2. Integrate with desktop ActiveDirectory login (backwards compatibility).
> UC3. Integrate with LDAP only without Kerberos infrastructure.
> UC4. Integrate with Ping Federate. 
> UC5. Integrate with Windows Azure Active Directory.
> UC6. Integrate with OpenStack Keystone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira