[jira] [Updated] (AIRFLOW-2995) Controlling access via AD security group

["Art Fotinich (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AIRFLOW-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Art Fotinich updated AIRFLOW-2995:
----------------------------------
    Description: 
Hi Folks,

I had the following task, which seemed to be quite logical: restrict user access to Airflow UI by using an AD security group with a select list of a few users (for a company that has 100's of people in its AD). It looks to me like regular airflow ldap configuration parameters do not provide this option.

The few examples available online showed usage of security groups for group_filter and superuser_filter, which do not fully restrict the Web UI access but only limit some features thereof. The most obvious parameter, user_filter, would have expected value as something simple like: *objectClass=user* and would error out on a properly configures ldap search query that included the security group...

After reviewing the *ldap_auth.py* it looks to me like the user authentication is controlled by these strings: "(&(\{0})(\{1}=\{2}))".format(user_filter, user_name_att, username). As a result, the security group may be included into the authentication process by formatting the user_filter parameter as follows: 

*objectClass=user)(memberOf=cn=airflow-users,ou=Security Groups,dc=company_division,dc=company_name,dc=domain*

_Note the missing parentheses around the string_. This string would allow restricting Airflow access to the members of the security group, which was the goal. This works for us but looks like a hack to me.

It looks like Airflow would benefit from restructuring the ldap queries in ldap_auth.py to include a couple of new parameters (named like *object_class_filter* and *security_group_filter*) instead of just one, user_filter. This would make ldap authentication process clearer and more self explanatory. 

Please let me know if it makes sense. Our team would be willing to contribute the required change unless it is already in works.

Thanks 

 

  was:
Hi Folks,

I had the following task, which seemed to be quite logical: restrict user access to Airflow UI by using an AD security group with a select list of a few users (for a company that has 100's of people in its AD). It looks to me like regular airflow ldap configuration parameters do not provide this option.

The few examples available online showed usage of security groups for group_filter and superuser_filter, which do not full restrict the Web UI access but only limit some features thereof. The most obvious parameter, user_filter, would have expected value as something simple like: *objectClass=user* and would error out on a properly configures ldap search query that included the security group.

After reviewing the *ldap_auth.py* it looks to me like the user authentication is controlled by these strings: "(&(\{0})(\{1}=\{2}))".format(user_filter, user_name_att, username). As a result, the security group may be included into the authentication process by formatting the user_filter parameter as follows: 

*objectClass=user)(memberOf=cn=airflow-users,ou=Security Groups,dc=company_division,dc=company_name,dc=domain*

_Note the missing parentheses around the string_. This string would allow restricting Airflow access to the members of the security group, which was the goal of this hack. This works for us but looks like a hack to me.

It looks like *ldap_auth.py* would ** benefit from restructuring the ldap queries to include a couple of parameters (named like object_class_filter and security_group_filter) instead of just one, user_filter. This would make ldap authentication process much more clear and self explanatory. 

Please let me know if it makes sense. Our team would be willing to contribute the required change unless it is already in works.

Thanks 

 


> Controlling access via AD security group
> ----------------------------------------
>
>                 Key: AIRFLOW-2995
>                 URL: https://issues.apache.org/jira/browse/AIRFLOW-2995
>             Project: Apache Airflow
>          Issue Type: Improvement
>          Components: authentication, security
>    Affects Versions: 1.9.0
>            Reporter: Art Fotinich
>            Priority: Minor
>
> Hi Folks,
> I had the following task, which seemed to be quite logical: restrict user access to Airflow UI by using an AD security group with a select list of a few users (for a company that has 100's of people in its AD). It looks to me like regular airflow ldap configuration parameters do not provide this option.
> The few examples available online showed usage of security groups for group_filter and superuser_filter, which do not fully restrict the Web UI access but only limit some features thereof. The most obvious parameter, user_filter, would have expected value as something simple like: *objectClass=user* and would error out on a properly configures ldap search query that included the security group...
> After reviewing the *ldap_auth.py* it looks to me like the user authentication is controlled by these strings: "(&(\{0})(\{1}=\{2}))".format(user_filter, user_name_att, username). As a result, the security group may be included into the authentication process by formatting the user_filter parameter as follows: 
> *objectClass=user)(memberOf=cn=airflow-users,ou=Security Groups,dc=company_division,dc=company_name,dc=domain*
> _Note the missing parentheses around the string_. This string would allow restricting Airflow access to the members of the security group, which was the goal. This works for us but looks like a hack to me.
> It looks like Airflow would benefit from restructuring the ldap queries in ldap_auth.py to include a couple of new parameters (named like *object_class_filter* and *security_group_filter*) instead of just one, user_filter. This would make ldap authentication process clearer and more self explanatory. 
> Please let me know if it makes sense. Our team would be willing to contribute the required change unless it is already in works.
> Thanks 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)