directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleksandr Bodriagov (Polystar)" <oleksandr.bodria...@polystar.com>
Subject Re: Apache Fortress REST API state and session object
Date Sun, 03 May 2015 14:53:27 GMT
Thank you for the answer, Shawn! I think I get a little bit more now, but
I still have some questions.

I didn¹t know that there are administrator level functions in API. I
couldn¹t find this information in documentation.
So, if I got it right, there are functions in the REST API that only
administrators can invoke (receive a valid answer). My particular use case
can be solved using these functions. There is an administrator level
function ³userPerms² that gives the same output as rbacPerms. A
fortress-rest-super-user (user Alice) using a request to ³userPerms² can
check permissions for the user Bob. To do this, a fortress-rest-super-user
should get his own session object first. Then he creates a FortRequest
with his session, user entity for Bob, context, and sends it to
³userPerms². Is it how it works?
Is userAuthzed an administrator level function that gives the same
information as rbacAuthZ?

/Oleksandr





We could as well create normal normal end session to check it at first.

On 3/5/2015 15:57 , "Shawn McKinney" <smckinney@apache.org> wrote:

>
>> On May 3, 2015, at 8:14 AM, Oleksandr Bodriagov (Polystar)
>><oleksandr.bodriagov@polystar.com> wrote:
>> 
>> REST API requests (for example to
>>"http://<server>:8080/fortress-rest-<version>/rbacAuthZ" and
>>"http://<server>:8080/fortress-rest-<version>/rbacPerms") require a
>>session object/xml. This is on top of HTTP authentication that should be
>>performed using credentials of an account assigned [fortress-rest-user,
>>fortress-rest-super-user] roles. The problem is that a session object
>>actually introduces a state to the REST API because one has to remember
>>this session object in order to do subsequent requests. Even the
>>fortress-rest-super-user has to add this session object despite being
>>administrator. 
>
>There are three sets of credentials that may participate in a
>fortress-rest request:
>
>1. system level - passed in the http header.  This is to secure the
>request/response at the service provider level.  i.e. can the service
>provider call fortress-rest, what services are allowed?
>
>2. administrator level - passed inside fortRequest document, session
>element.  This is used for delegated administration (ARBAC) validations
>on admin and review ops.  For use case, think GUI.  Can the administrator
>who is logged onto the system, invoke the fortress API.
>
>3. user level - also passed inside fortRequest document, session element.
> (Note only user OR administrator session may be passed.  Never both
>simultaneously).  This is for access manager APIs like checkAccess
>(rbacAuthZ) or sessionPermissions (rbacPerms).
>
>So the fortress-rest-super-user passes their session on requests in order
>to validate whether they are authorized to call the service in the first
>place.  Normal end users session is used to compute the actual
>authorization decision.
>
>> 
>> On May 3, 2015, at 8:14 AM, Oleksandr Bodriagov (Polystar)
>><oleksandr.bodriagov@polystar.com> wrote:
>> 
>> Administrator should be able to view permissions of other users, but at
>>the same time administrator is not supposed to know users' passwords,
>>and without this knowledge he/she cannot create a session object to view
>>permissions.
>> 
>
>Agree administrator should not be able to know user¹s passwords.  Where
>in this call chain are they exposed to them?  Also agree they may be
>allowed to view the permissions of others.  Administrators use a review
>function to view the user¹s passwords (see), which does not require the
>user¹s password.  
>
>I feel there may be a little confusion here.  The administrator session
>is never passed on the user access functions (i.e. rbacAuthZ, rbacPerms).
> This means the administrator will never view or intercept security
>access checks on behalf of users.  The administrator session is passed on
>the admin and review apis only.
>
>> 
>> On May 3, 2015, at 8:14 AM, Oleksandr Bodriagov (Polystar)
>><oleksandr.bodriagov@polystar.com> wrote:
>> 
>> In my opinion, a fortress-rest administrator (user A) should be able to
>>execute a simple authenticated GET request to get all permissions for a
>>user Bob:
>> curl GET -H "Authorization: Basic blablabla"
>>https://<server>:8443/fortress-rest-<version>/rbacpermissions/user/Bob
>> 
>> A request to check Bob's access to some particular object executed by
>>fortress-rest administrator should be a simple POST:
>> curl  POST -H "Authorization: Basic blablabla" --data
>>"user=Bob&object=someobject&operation=someoperation"
>>https://<server>:8080/fortress-rest-<version>/checkaccess
>> 
>> I have found a ticket https://issues.apache.org/jira/browse/FC-77 that
>>is a little bit related to what I wrote here.
>> Are there any plans to remove this session object?
>
>As the FC-77 ticket states, fortress-rest doesn¹t follow the accepted
>principles of a restful interface.  There is work that needs to be done
>here.  Part of that work is to do something about the session object.  It
>is fat, and contains unnecessary data for authorization checking (i.e.
>demographic info).  Having said that rbacPerms needs to be based on the
>user¹s session and not the administrators.  There are many problems if
>you do it otherwise, not the least of which - how do we know which roles
>are active in the user¹s session?
>
>It can be argued that in restful use cases the user¹s rbac session should
>remain cached server-side.  That would mean that the session would not
>need to be cached by the client.  But they would have to hold onto
>something.  e.g. SAML authentication assertion, kerberos ticket, oauth
>token, etc.
>
>The question is what sort of token should be used, and how should the
>(user rbac) session state be managed between the client and the server?
>
>Shawn
>smckinney@apache.org
>


Mime
View raw message