directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleksandr Bodriagov (Polystar)" <>
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?


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

On 3/5/2015 15:57 , "Shawn McKinney" <> wrote:

>> On May 3, 2015, at 8:14 AM, Oleksandr Bodriagov (Polystar)
>><> 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
>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)
>><> 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
>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)
>><> 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"
>> 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
>> I have found a ticket 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?

View raw message