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" <[email protected]> wrote: > >> On May 3, 2015, at 8:14 AM, Oleksandr Bodriagov (Polystar) >><[email protected]> 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) >><[email protected]> 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) >><[email protected]> 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 >[email protected] >
