> 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 (userPerms), 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]
