Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Mon, 15 May 2017 13:54:04 +0000 (UTC)
From: "Robert Levas (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.13071747.1494673028000.210810.1494856444278@Atlassian.JIRA>
In-Reply-To: <JIRA.13071747.1494673028000@Atlassian.JIRA>
References: <JIRA.13071747.1494673028000@Atlassian.JIRA> <JIRA.13071747.1494673028159@jira-lw-us.apache.org>
Subject: [jira] [Commented] (AMBARI-21016) RBAC:Ambari should be sensitve to
 the change of login user's permissions.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 15 May 2017 13:54:09 -0000


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

Robert Levas commented on AMBARI-21016:
---------------------------------------

[~jonathan.hurley].. We can't force a logout since we don't if the user being updated is using Ambari at the time of the change.  However invalidating the session, is essentially forcing a logout. So of the frontend can detect a change in permissions for the user, then it could force a logout.   This, however, will not help if the user is issuing REST API calls using a cookie to maintain a session and therefore keep the user logged in. 

Maybe a session manager can be established to monitor the active sessions.  Then, if a user's permissions have changed, the session manager can be trigger to destroy the relevant user's session.  Or may be trigger the security context to be reset with the new data. 

However this still seems to be overkill for the frequency in which this will happen. 


> RBAC:Ambari should be sensitve to the change of login user's permissions.
> -------------------------------------------------------------------------
>
>                 Key: AMBARI-21016
>                 URL: https://issues.apache.org/jira/browse/AMBARI-21016
>             Project: Ambari
>          Issue Type: Improvement
>          Components: ambari-web
>    Affects Versions: trunk
>            Reporter: Yao Lei
>            Assignee: Yao Lei
>            Priority: Minor
>             Fix For: trunk
>
>         Attachments: AMBARI-21016.patch
>
>
> Steps to reproduce:
> 1.Login ambari with ambari administrator role and create a user named Test on host A.
> 2.Assign service administrator role(or any other one of five roles) to this user Test.
> 3.On host B, login ambari with user Test .Now it plays as a service administrato role.
> 4.On host A, unassign the role of user Test , or change the role to another one, or even delete this user.
> 5.On host B, we will find the user Test can continue to operate ambari with previous permissions as a service administrator which actually have already changed by step 4.
> Except for on two different hosts, we also can reproduce this problem between two different browsers on local host.
> One solution:
> Periodly schedule a task to update current user's authorization. If any error happens in this process, we should log off current user.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)