iControl - RemoteRole User Permissions

The Management::UserManagement.get_my_permissions does indeed work on the current logged in role/partition. This is true even if the user is logged in with a remote authentication source and the role is mapped via remote roles.

 

 

I wrote a short test app on a Big-IP defined with remote roles via Active Directory and it correctly identified the credentials I used to make my iControl calls with a partition and role. The username used to make the iControl calls is not defined on the BigIP whatsoever.

 

 

I can't for the life of me understand why it returns a list of UserPermission as I am only one user and am not Schizophrenic... much.. :-)

So, I have this working, sort of.....

 

 

So utilizing iControl for .Net

 

 

I'm initializing and iControl Interface, but I'm getting some strange behavior I believe it's because I'm not properly tearing down the connection but I'm not sure.

 

 

 

So basically we're moving to RemoteRoles using RADIUS to ease administrative burdens, but we have an iControl app that we need to ensure works after the transition. So during testing of the iControl I'm switching the radius attributes returned for my login to simulate several user roles.

 

 

 

Setting a breakpoint at the User permissions I've noticed that once I connect and get a permission set, even if I close the application i keep getting the same permissions. If I chage the RADIUS attributed to get another role, when i re-launch the application and initialize the interface my User Permissions reflect the old role until some (unknown to me) timeout occurs, but the LTM GUI would reflect the new role immediately (ruling out and delay between RADIUS attribute changes vs. returned attributes). Once this timeout has elapsed (maybe 15 minutes?) and I re-initialize the iControl Interface the proper permissions are present.

 

 

 

How should I be tearing down / logging out of iControl when I'm finished with the interface? Currently I'm just setting it to null as I don't see a close / logout method.

 

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!

It's a .Net client application utilizing iControll.dll so a lot of the stack specifics are hidden from me (thankfully). The application is used as an administration tool that is installed on a machine and allows us to perform advanced maintenance across our infrastructure from one interface.

 

 

Exiting the application does not seem to tear down the session on the LTM. While not a show stopper, it was just unexpected to see that while debugging, it lead me to believe that I had something wrong with my RADIUS policy. In the real world, will i have users switching AD Groups and getting different Radius attributes returned, probably not, but it prompted the question "Am I properly ending/tearing down my iControl interface?" Not seeing any methods that ended the session, I figured I'd ask.