Hi Sheel -
Despite the syntax of the command, which is somewhat confusing, you are mixing elements that are independent of each other.
In the "security login create" command you need to specify two elements at a minimum. First is the access method (http, ssh, etc.) and second is the authentication method when a user tries access via that method. These two elements are tied together in a pair and associated to the user, and obviously there can be multiple pairs of access/authentication created.
You can optionally specify a "role" which is tied only to the user, not the combination of user and access/authentication style. The role lists what the user can do once they get access by any of the methods allowed. And yes, both the documentation and the command syntax aren't explicitly clear that the role is tied only to the user [ well - technically the user and the SVM ]. For any given SVM a user can only have one role. Once a user is granted access via authentication by any mechanism, then they get the rights identified in the single role associated to the user in that SVM.
One possible way to accomplish what you want might be to allow access with different roles via both the target SVM and the cluster itself. You could grant needed access with default role "vsadmin" at the SVM level and then access to the Cluster at a "readonly" level via other means.
Based on your sample commands though I see you want to do this at the cluster level, given your choice of applications. At that level only you can't limit "capability" based on mechanism used to access the cluster. If you think about it this makes sense. If you given someone full access, you given them full access. Even if you could limit to readonly access via SSH, I just do the same thing I want via a ZAPI call and totally ignore your restriction on SSH such that the restriction doesn't accomplish anything.
You would need to move to multiple user names to accomplish this security difference.
Hope this helps!
Bob Greenwald
