Context on UAA

260 views
Skip to first unread message

oriol.co...@gmail.com

unread,
Oct 15, 2012, 6:31:08 AM10/15/12
to vcap...@cloudfoundry.org
Hello,

I recently installed a CloudFoundry instance on my local machine and I am trying to use the UAA client (uaac) from the installation. However when I try to run commands other than "info" or similar it throws me an error saying that the context is not set. I haven't been able to find any documentation about this "context" thing, please could you explain what is it and how to manage them?

Thank you,
Oriol.

Dale Olds

unread,
Oct 15, 2012, 2:13:09 PM10/15/12
to vcap...@cloudfoundry.org
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

oriol.co...@gmail.com

unread,
Oct 15, 2012, 2:26:49 PM10/15/12
to vcap...@cloudfoundry.org, oriol.co...@gmail.com
Hi Dale,

Thank you very much for taking the time of writing such a long answer. Now I have things much clearer. I guess that the usual way to interact with the UAA is through its REST API, but for testing purposes I find it quicker to use the uaac.

Thanks again!
Oriol
Reply all
Reply to author
Forward
0 new messages