[jira] [Commented] (KYLIN-4481) Project-level ACL lookups not working for non-admin SAML-federated users

["Zhong Yanghong (Jira)" <ji...@apache.org>]

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

Zhong Yanghong commented on KYLIN-4481:
---------------------------------------

still have a question about why use 
{code}
essence.setUsername(userEmail);
{code}
rather than
{code}
essence.setUsername(userName);
{code}

With *essence.setUsername(userEmail);*, there's inconsistent between ldap & saml for the username. For ldap, there's no _@validdomain.com_; while for saml, there's _@validdomain.com_. After this change, it will make all of the acls without _@validdomain.com_ invalid for saml.

> Project-level ACL lookups not working for non-admin SAML-federated users
> ------------------------------------------------------------------------
>
>                 Key: KYLIN-4481
>                 URL: https://issues.apache.org/jira/browse/KYLIN-4481
>             Project: Kylin
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: v2.6.5, v3.0.1
>            Reporter: Rafael Felix Correa
>            Assignee: Guangxu Cheng
>            Priority: Major
>             Fix For: v3.1.0, v3.0.2, v2.6.6
>
>
> Steps to reproduce:
>  * setup kylin with SAML as described in [http://kylin.apache.org/docs/howto/howto_ldap_and_sso.html]. kylin.properties:
> {code:java}
> kylin.security.profile=saml
> kylin.security.acl.admin-role=Kylin_Admins
> kylin.security.ldap.connection-server=ldap://openldap:389
> kylin.security.ldap.connection-username=cn=admin,dc=example,dc=org
> # set kylin.security.ldap.connection-password appropriately
> kylin.security.ldap.user-search-base=ou=people,dc=example,dc=org
> kylin.security.ldap.user-search-pattern=(uid={0})
> kylin.security.ldap.user-group-search-base=ou=groups,dc=example,dc=org
> kylin.security.saml.context-context-path=/kylin
> kylin.security.saml.context-scheme=https
> kylin.security.saml.context-server-name=kylin.validdomain.com
> kylin.security.saml.context-server-port=443
> kylin.security.saml.metadata-entity-base-url=https://kylin.validdomain.com/kylin{code}
>  * on the LDAP server, make sure you have the following objects in place: 
> {code:java}
> # example.user, people, example.org
> dn: uid=example.user,ou=people,dc=example,dc=org
> objectClass: top
> objectClass: account
> objectClass: posixAccount
> objectClass: shadowAccount
> gidNumber: 10000
> uidNumber: 5000
> cn: Does not matter
> homeDirectory: /home/doesntmatter
> uid: example.user{code}
>  * 
> {code:java}
> # Kylin_Users, groups, example.org
> dn: cn=Kylin_Users,ou=groups,dc=example,dc=org
> objectClass: top
> objectClass: groupOfNames
> cn: Kylin_Users
> member: uid=example.user,ou=people,dc=example,dc=org{code}
>  * as an ADMIN, create a sample project in kylin and grant QUERY, MANAGEMENT or OPERATION access to example.user.
>  * now, try logging into kylin.validdomain.com's Web UI as [example.user@validdomain.com.|mailto:example.user@validdomain.com.]
> Expected result:
>  * example.user is logged in, able to select the project from the dropdown box at the top left corner and navigate through its properties.
> Actual result:
>  * example.user is logged in, but no projects are listed in the dropdown box. As if he/she had no permissions in any project.
>  
> With LDAP-pure installations (no SAML), this configuration works as expected.
>  
> Worth noting: [https://github.com/apache/kylin/blob/kylin-3.0.1/server-base/src/main/java/org/apache/kylin/rest/security/SAMLUserDetailsService.java#L40-L54] splits the user in the '@' char for performing LDAP lookups. However, by editing kylin_metadata manually and appending the @validdomain.com to the corresponding object under /acls, the lookup works as it should and the non-admin user gets to access the sample project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)