Sohaib Iftikhar created ZEPPELIN-2539:
-----------------------------------------
Summary: /api/login called recursively for role based auth on login
Key: ZEPPELIN-2539
URL: https://issues.apache.org/jira/browse/ZEPPELIN-2539
Project: Zeppelin
Issue Type: Bug
Components: zeppelin-server
Affects Versions: 0.7.1
Reporter: Sohaib Iftikhar
Consider a scenario where a zeppelin-server secured using shiro and needs to
permit access to the web interfact to a select group of user using ldap groups.
The following shiro.ini should work in such a scenario.
```
[main]
ldapRealm = org.apache.zeppelin.realm.LdapRealm
ldapRealm.userDnTemplate = uid={0},ou=people,dc=my-company,dc=net
ldapRealm.searchBase = dc=my-company,dc=net
ldapRealm.userSearchBase = ou=people,dc=my-company,dc=net
ldapRealm.groupSearchBase = ou=groups,dc=my-company,dc=net
ldapRealm.contextFactory.url = ldaps://auth.my-company:636
ldapRealm.contextFactory.authenticationMechanism = simple
ldapRealm.userObjectClass = posixAccount
ldapRealm.groupObjectClass = posixGroup
ldapRealm.authorizationEnabled = true
ldapRealm.memberAttribute = memberUid
ldapRealm.memberAttributeValueTemplate=uid={0},ou=people,dc=my-company,dc=unbelievable-machine,dc=net
ldapRealm.rolesByGroup = USERS:admin
ldapRealm.userSearchAttributeName = uid
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
shiro.loginUrl = /api/login
securityManager.sessionManager = $sessionManager
securityManager.sessionManager.globalSessionTimeout = 86400000
securityManager.realms = $ldapRealm
[roles]
admin = *
[urls]
/api/version = anon
/** = authc, roles[admin]
```
On trying to log in the /api/login gets a 302 redirect to itself and fails.
This works fine when the roles condition is removed. A workaround for such a
scenario is:
```
/api/login = authc
/api/login/logout = authc
/api/security/ticket = authc, roles[admin] #To also secure websockets
/** = authc, roles[admin]
```
In this case the user can login but cannot use any api calls if he is part of
the group however on first login (before refreshing or call to
/security/ticket) the websockets still work and hence this is not foolproof.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
