iControl - RemoteRole User Permissions

The remote AuthZ are not performed by the SOAP server controller process or its interface handlers, but by the web server hosting the iControl applicaiton. If you do a tcpdump of your iControl calls you will see an 'Authorization' header in each HTTP request. If you change the authorization header credentials you will see login work differently. So there is no 'logout' method as each reaquest comes with its own username:password combination.

 

 

Version 11 added the System::Session interface, but that was to allow the backend iControl application to persists your requests in a transaction and to track your current folder information, not take over the AuthZ/AuthN functions from the web server.

 

 

The AuthN role mapping is the question. The Authorization header does not convey any 'role' information, nor are Big-IP roles maintained by standard linux group mechanisms. The roles are internal to TMOS objects.

 

 

I suspect that disconnecting your connection from the web server and them making a new connection would force a reauthentication and the associated reauthorization as you suggested, but obviously that comes at the cost of load on the system with frequent communications to your RADIUS server. I would confirm your assumption first in your code with a test, then I would ask what 'policy' I have to enforce. I ran a simple test for AuthN changes using a locally defined user and changing their role between connections. The new connection method worked for me, thus no caching of the AuthN for local roles between connections. I did not test it with remote role changes (as the only thing I have setup with remote-role would lock out one of my applications I need to manage..yikes.) sorry.

 

 

If your assumptions about new connections and reauthroization are true, what is the basic behavior of the HTTP client built into your service stack? How often does it 'reconnect' anyway? Does it provide 'enough' refresh of the connection that you meet your policy without changing anything? (Let's hope so ). If not, what are your options? Can you simply create a object pool whcih will enforce your 'policy' by invalidating objects and creating new ones? That's the road I've gone with other systems which cached security information too long for the policy I had to enforce. Very few systems require the reauthorization of each SOAP call. If that is your requirement, there are software appliances that specialize in WS-Security which can not only perform enhances session revalidation, but even proxy connections forcing a rewrite from the client supplied credentials, mapped to an RBAC system for each method, to ones defined as a 'service account' which the service can cache and use efficiently. They are not cheap!