Hi Oriol,
Short answer: A context represents an authorized user or application.
You create a context by getting a token.
$ uaac target
uaa.cloudfoundry.com
$ uaac token get <username>
$ uaac contexts
$ uaac me
"uaac info" worked for you because it's an unauthenticated request and
does not need a token.
Long answer:
uaac is a command line interface that we use to debug and test the uaa.
It's not been documented much, though "uaac help" does give an overview
of all possible commands. In various revisions we've struggled with how
to best represent this notion of context. Here's the situation:
The UAA issues tokens that can be used to authorize actions on a user's
behalf at the cloud controller. In OAuth2 terms the UAA is an
authorization server, the cloud controller is the resource server, and
the user is the resource owner. In OAuth2 all such interactions also
involve a "client" -- which means an application that gets the token for
the user and presents it to the cloud controller (or other resource
server). In cloudfoundry today we support clients such as the vmc
command line tool, and web apps like the micro and support sites.
uaac allows us to simulate any of these interactions, e.g. a user
getting a token as they would with vmc, or a user getting a token as a
client web application. A client web application can also get a token
where the application itself is the principal and no user is involved.
We didn't have a better name for this collection of information that
describes the parties represented in getting a token, so we called it
"context"
When you get a token via one of the "uaac token" commands, it creates a
context and records the token and other metadata. It then uses that
token when making requests to the UAA. You can simultaneously have many
contexts (shown with "uaac contexts") and switch between them with "uaac
context" to make requests to the uaa as one or more client apps or users.
Please let me know if you have more questions.
--Dale