Forum Discussion

Gary_Chen_31612's avatar
Gary_Chen_31612
Historic F5 Account
May 23, 2003

ACL on iControl interfaces.

Hi,

 

 

I am an application developer, trying to create remote requests to update BIG-IP. Recently, I realize that iControl requires a full read and write access priviledged account access to BIG-IP v4.2. My IT management values the benefits of iControl in automating update of BIG-IP, but they would like to have additional ACL tagged on the interface method I could use. How can iControl interface methods be regulated via ACL? Any suggestion on design is greatly appreciated.

 

 

Best regards,

 

 

Gary Chen
dev
devops
iControl
v4

3 Replies

Sort By
  • Joe_Pruitt's avatar
    Joe_Pruitt
    May 28, 2003
    iControl requires read/write user privileges as a majority of the methods require both types of actions. I believe what you are asking for method and parameter level authorization. For example, user "A" can modify pool "pool1" but not pool "pool2". Currently, iControl does not support this directly. There are approximately 1500 methods exposed in iControl and it has been determined that building a complex authorization scheme around parameter level validation is usually more easily developed in a custom build "shim" layer on top of iControl. For instance, one customer developed a web portal where the end users logged into were able to control the sections of the configuration that they owned.

     

     

    We are always looking at how we can enhance security and welcome any specific requests for features.
  • Anand_Deshmukh_'s avatar
    Anand_Deshmukh_
    Icon for Nimbostratus rankNimbostratus
    May 18, 2005
    If an icontrol querry is just reading configuration from 3dns server, why do the user id need write access enabled at that time?
  • Loc_Pham_101863's avatar
    Loc_Pham_101863
    Historic F5 Account
    May 18, 2005
    In 4.x, only users with iControl privileges are allowed iControl access. This access check happens when the client request comes through the CORBA Portal, and the access check is based on the user's privileges, not on what method is being called. So if the user has iControl privileges, the user will be allowed iControl access, regardless of whether he/she is querying or modifying.

     

     

    In 9.x, our authorization access check has been reworked to use a combination of the user's role and what method is being invoked.

     

     

    Regards,

     

    Loc