I think I’m starting to understand it now.
When boundary is deployed, the only scope with a determinate name is the global scope with the name
global (which the clients know because it’s hardcoded). To get scopes under global (and learn the names of org scopes so you can list their authentication methods), you have to perform the search from the global scope and thus have the permission
id=*;type=scope;actions=list,no-op for the global scope on the principal
I had a misconception that the boundary client could list out all this information without needing a global level scope access.
You’re right, I think this is my real problem. The Web and Client UI will show the global scope and all org scopes. I was under the impression that it only showed scopes that you could authenticate into.
For example, if the u_anon user had these grants:
id=*;type=scope;actions=list,no-op for global scope
id=*;type=auth-method;actions=authenticate,list for an org scope
Then you should be able to find and list the org scope you want to authenticate into (without needing to know any specific ids beforehand) using the commands:
boundary scopes list
boundary auth-methods list -scope-id <ID-FROM-PREVIOUS-COMMAND>
boundary authenticate oidc -auth-method-id <ID-FROM-PREVIOUS-COMMAND>
However, due to the default behavior of the way the desktop and web clients work, if you go to the web-admin page or desktop client, it will give you a blank screen. This is because the client is hardcoded to list auth-methods on the
global scope – which you can’t do – and so you get a blank screen.
I think I can live with it for now